Summary
Here are some of the main things to highlight since the last dev update:
- We are excited to announce the creation of the BambooGarden Fund which will be used for initiatives to help Network rollout and adoption! Full details on a separate forum post here
- Lazy messaging flows are coming together in
sn_node, with promising results so far, plus simplified code. - We’re confident we’ve finally cracked section wallet splits, seeing this in action flawlessly today. This allows us to re-enable relocations, and so reward payouts, moving onto tackling any issues that arise there.
- Everyone loves a bit of @jimcollinson - check out his new screencast demonstrating how we’re designing things with the aim of making it straightforward to start earning Safe Network Tokens, even for those not confident on computers.
-
@dimitar was a guest on the Bulgarian crypto podcast “Cyber people” which was released this week. If you speak Bulgarian you can watch the full episode here, otherwise you have to check out his “easter egg” at 58 minutes in here
-
Keep a regular eye on the Like This Tweet thread on the forum for some excellent guidance on how to help promote the Safe Network, and surrounding components, with a simple button click!
Announcing the BambooGarden Fund 
We are delighted to announce the creation of a fund to be used for initiatives which will either directly help with the Safe Network rollout, or build a user base for the Safe Network once live.
We have created a separate forum post here with much more detail.
Step 1 towards being able to take applications for funding is to find fund committee members from the community, who can volunteer their time to help set the scope for the first area(s) that should be targeted, and of course to review and vote on applications for funding. If you would like volunteer to join the fund committee then you will find all the details in the fund forum post.
Safe Client, Nodes, Routing and qp2p
Safe Network Transfers Project Plan
Safe Client Project Plan
Safe Network Node Project Plan
Safe Routing Project Plan
Lazy Messaging
We’ve been taking a bigger look at nodes in the last week, with the new lazy messaging flows in mind, and how we can get those implemented. As a result we’ve actually made some large changes to the node code to simplify things somewhat, which allows us to more concretely retain some relation to the message that triggered a given node action, so we can fail with this context, as required.
It’s been a good and rapid refactor there, which seems to have got us to a good point. We’re now integrating the associated messaging changes into sn_routing to properly route and/or error if our messaging is out of sync with the Network. Once we have that, we should be in a good spot to start throwing errors via the lazy messaging pattern when they arise at nodes.
Section wallet split
Dealing with the split of the section wallet was a tough nut to crack when trying to have an old constellation (the parent section Elders) sign the transfer to the new sibling sections.
What we ended up doing was reusing the genesis flow, where the new section Elders simply propose the creation of a new wallet.
Today we got the splits working for several subsequent splits (no end seen there). This means we can now re-enable the relocations and so the proceeding reward payouts, which were disabled during development of the splits.
Reward payouts
We did have successful reward payouts before the code refactor, but currently there’s some fixing to do to get it up again. We’re already delving into that.
Elder size
The PR to increase elder size to 7 has been on hold because it necessitated some changes in the client libs. They have been implemented now and are being tested. Once we verify everything works correctly, we can immediately merge this PR.
Documentation
We started working on detailed technical documentation for sn_routing. Its aim is to be a single canonical source of information about the inner workings of routing and its various algorithms, so new developers who want to dive into it have easier time doing so. We also want to make it easier to formally prove those algorithms. The documentation is currently being polished and reviewed and will be published soon.
API and CLI
Similar to what we’ve recently done with our FilesContainer abstraction in sn_api, i.e. have all the content stored on Blobs and keeping only the Safe link in the FilesContainer, we are now starting to make the same type of changes to our NRS Container implementation. This won’t be affecting how users interact, create and/or access the NRS names and subnames, but just how the data is stored on the network. Each new version of the mappings created for an NRS name will now be serialised and stored on a public immutable Blob, keeping only a link from the NRS container to each of these Blobs. In this way, the NRS container will still keep track of history of changes while restricting the amount of content stored on the mutable piece of content to simply be Safe links.
As explained in the section below, we are also moving away from the Sequence data type to the new Register data type which is a simpler and more robust CRDT for supporting concurrent operations from different clients, thus the NRS containers will be stored on Registers, rather than Maps as it currently is. With this in place we will have all our data abstraction implementations based on CRDT.
CRDT
Bounded Counter work has been progressing steadily. We now have the theory in place for paying to allocate op’s ahead of time and ensuring that all op’s will always have the chance to be persisted durably across a supermajority of Elders. What remains is to validate this theory through some PoC code to make sure we’re not missing anything in the details.
MerkleReg: We’ve settled on a traversal API for the MerkleReg, this gives us the ability to walk back through the branching history of a register, as well as query for any newer data that’s been written to the register. rust-crdt #116
With this now in place, we started migrating away from the Sequence data type to the new Register data type. The changes for our sn_data_types crate are ready (PR #352), and we are now working towards adapting the sn_client counterpart, plus sn_messaging accordingly (PR #65).
Safe Network App & UX of Farming
For your weekly dose of UX, check out this quick screencast from @jimcollinson demonstrating how we’re designing things with the aim of making it straightforward to start earning Safe Network Tokens, even for those who are not super confident with computers.
It shows the conversational style onboarding we’re devising for key areas of the app for first time use, aiming to step people through some of the more nuanced flows without being overly verbose.
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!
gift. Did I actually guess correctly for once in this forum? I hope so. Things looking better.
well done all.