As we speak, InstallNet is still humming along nicely, and we’ve already drawn some useful lessons from it, tested some assumptions, and made plans for improvements. The current iteration is really to test the safeup process that @ChrisO has been putting together to automate the installation of safe client, safenode and testnet on macOS, Windows, Linux and ultimately more platforms too.
The inspiration, as you may know, is Rustup which does the same for the Rust language ecosystem. I’m sure you’ll agree that while there are a few quirks to iron out, it already makes for a better UX.
Thanks as always to everyone who’s mucked in. We can’t do this without you.
InstallNet - findings and actions
-
Some of the glitches experienced by community testers have been due to new versions of
safeandsafenodebeing incompatible with old ones. Updates are happening thick and fast, and sometimes these contain breaking changes. Going forwards testnets will need to be tied to specific versions here (until we have upgrades working well). -
One of these breaking changes is that we now prepend a
RecordHeaderto each piece of data. This allows us to distinguish between a chunk, DBC and register, since Kademlia stores everything as a Record in the network. The older nodes cannot handle these headers. -
Installing
safeupas root/sudo (Linux) places the binaries in different locations, which we’ll need to keep track of. -
Logging/tracing needs cleaning up and standardising - we are in the process of considering our options here.
-
Safeandsafenodebinaries were buggy on iMac High Sierra 10.13.6, Arm v7. A fix is already in for that, but keep the reports coming in and we’ll do our best to support them -
The default chunk storage location needs to be split up into subdirectories, one per node on that machine.
-
It works on Android!
-
We need to refine the instructions for Windows users.
-
We haven’t yet cracked the issue where nodes take a long time to receive chunks. It may be that as Kademila buckets (close groups) fill up, new “close” nodes are only promoted when another peer becomes unresponsive, suggesting we have a clustering of nodes on startup, perhaps due to how we supply only a limited subset of nodes for initial contact. We’re digging in here.
General progress
@Joshuef and @qi_ma have been looking into the inactive nodes issue, which result in a lot of connectivity looping as nodes try to find (the same) peers and be accepted (which in turn can cause mem spikes). This involves a deep dive into the workings of Kad, thoughts about what a node needs to get noticed in a small network, and possible workarounds such retrying with fresh PeerIds.
Qi has also looking at some memory spikes and speed issues noted in the last testnet (you can see there’s been some progress made in the new benchmark charts)
@ChrisO has compiled a list of issues from the latest testnet and is working on refinements to safeup and the release process.
Meanwhile @anselme has completed his work on spends, has verified that doublespends are prevented as expected, and has started to get registers stored in our Kad RecordStore, working up a prototype barebones API to imitate what’s there for chunks and spends.
@Bzee continues to look into the intricacies libp2p connections to consider how much i/o we can control at node level and @bochaco is working on verification for storage payments inputs.
And some tentative but very positive news from @aed900. He’s been testing out libp2p’s support for hole-punching via QUIC, which is a work in progress from the libp2p team. He reports that so far everything appears to be working as expected - but more testing is needed before we break out the champagne.
Useful Links
Feel free to reply below with links to translations of this dev update and moderators will add them here:
Russian ; 
German ; 
Spanish ; 
French; 
Bulgarian
As an open source project, we’re always looking for feedback, comments and community contributions - so don’t be shy, join in and let’s create the Safe Network together!
ever since libp2p
