Another relatively compact update this week as we work on readying the next community testnet, which needs a bit more tweaking in-house. We actually have two testnets planned. The first will be a relatively simple affair, with data stored in memory and no NAT traversal. Knowing the community’s propensity to bombard testnets with cock pics (sic) and record collections, we expect it to be a fairly short-lived affair, but it should allow us to see what’s happening with messaging between nodes. Soon afterwards, though, we should be able to flick a switch to allow store to disk, and after that NAT traversal. So, baby steps, but it’s the fastest baby you ever saw.
Also we’re pleased to welcome Angus (@aed900) to the team 
. Angus is a network engineer who’s going to be helping us on the routing and connectivity side of things. He’s leaping in at the deep end, working with @bzee to see how libp2p handles NAT traversal and what tweaks might be needed for Safe.
General progress
@Bochaco is currently Sr Serialisation, making sure all data can be transferred and stored efficiently in memory or on disk, that messaging is efficient and able to cope with the anticipated asynchronicity, and ultimately that we can support multiple programming languages by ensuring data formats are platform-agnostic (e.g. protobuf).
Much of the generic stuff we think can be pushed to libp2p, leaving us to handle the specific requirements for apps running on Safe.
@roland, @qi_ma and @anselme are looking at how libp2p handles data requests. Basically, there are two scenarios for a GET. One is a simple Kademlia request that gets routed to the closest nodes based on the data’s XOR address. libp2p also has a service provider functionality where the client requests a service from a specialised node (e.g. an audit or an archive node) which then carries out the request. Obviously this will be massively helpful later on.
@bzee is continuing to test NAT traversal. Currently he’s looking at the relay functionality, specifically how we can use this as part of the startup sequence, i.e. first detecting NAT then optionally connecting to a relay. He is also looking at how to identify which nodes offer which functionality (see above).
@joshuef is digging into libp2p’s refresh functionality. Kademlia by default forces nodes to check the liveness of their closest neighbours by periodically replicating data to them, but this may (or may not) be wasteful in our case. Limited testing has not revealed any problems (and indeed has been quite pleasing to see!), but as we scale up we may want to move this time-based functionality to one that’s event-driven, where checks are carried out when changes to the close group (joins and leaves) are detected.
And spanner in hand like a latter-day Mario, @oetyng has been heroically plumbing DBCs into the new architecture. Our new home now has a faucet for use by whoever starts a comnet. This person claims the genesis DBC and can then redistribute it as they wish. We plan to have a webpage where users can tap the faucet by themselves to make payments. Prior to that, payments can be made using the CLI by following these three steps:
- Receive a public address from the recipient.
- Call the faucet with the amount to get.
- Hand over the resulting DBC hex to the recipient.
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!
Seems things are cruising along at high altitude.
That’s never happening again
best of luck