Most of the action this week has been behind the scenes, particularly staging our release process so we can formalise updates more smoothly. For example, we may decide to have community testnets using the official release candidates prior to a final release. No promises but we may find that’s a good option. You can see the improvements made to the current RC here .
We’ve also been redesigning the Launchpad UI so that it gives more valuable information, to help people work out if their nodes are functioning properly or not, and whether they are earning nanos. As you know, the way the network ensures good performance is by shunning bad nodes. A node could be “bad” due to a temporary loss of bandwidth, such as someone in the house starting up a multiplayer online game, or for VPN users it could be that the shared tenancy has become overloaded at the provider end, or it could be too many nodes on one machine choking things up, a lack of memory, disk space, or an overloaded CPU. The new-look Launchpad will enable users to check node health and key metrics at a glance.
For those happy with parsing log files, the string to watch out for that indicates a shunning is consider us as BAD.
If nodes have been shunned, or are otherwise behaving badly, the best thing to do is to reset (Ctrl-R) and start again with fewer nodes. If that works, you can add a few more at a time.
For those who haven’t seen @jimcollinson’s latest video, this will be 1 min and 44 seconds of your precious time very well spent. You’ve all heard the maxim: “not your keys, not your coins.” It’s true, but what we really should be saying is: “not your keys, not your data.”
General progress
@rusty.spork has been his usual helpful self over on Discord, as well as soaking up the occasional bit of user angst. Still some issues with people not receiving nanos, possibly those using the Launchpad primarily. This could sometimes be due to nodes getting shunned by others. We are building visibility for that into the Launchpad UI now.
Some good news from @bzee who has been conferring with the libp2p guys. Apparently an outstanding issue with libp2p’s Autonat in combination with QUIC is not an issue anymore, so we’ll be getting that integrated in forthwith. The libp2p refactor adds an option to dial from a different port than which we’re listening on. This is important for both TCP with port reuse and QUIC (which uses the same port by default). Reusing ports facilitates hole punching.
However, accidental hole punching was causing nodes to come to the wrong conclusions about nodes being reachable. This transport redesign paves the way for a next version of AutoNAT.
More good news, @mazzi reports significant progress with the Launchpad redesign, with better application flow and improved UI and options for users. It’s all looking very nice.
@dirvine is leading a review into code bloat. As he says, for every thousand lines of code there will be three bugs. As things change it’s easy to leave legacy code in the codebase, and every so often we need to go in and have a good old clean up.
And together with @dirvine, @joshuef is leading the foray into GetRange land. Briefly put, this is a way of ensuring a Sybil actor is not able to place multiple nodes close to a chunk of data and thereby block access to it.
@chriso has been focused on getting a new release candidate for the network up and running. A RC is a minimum viable product that is ready for testing before a proper release.
@qi_ma raised a PR to resolve the corrupted wallet issue caused by forced termination of the upload process.
@roland found a bug in the safenode-manager where we are currently setting a port range even if we’re starting a single node, e.g. 13000-13000, which fails. You can now manually specify the metrics, node and RPC port when running a local network.
And @mick.vandijke has been doing some deep diving into self-encryption and chunking. He finally managed to understand what was going on when some files only upload one chunk instead of the minimum of three. The reason for this is when all chunks are identical (possible for very small chunks) only one gets uploaded. The data map will then need to know how many times that chunk needs to be repeated.
