To support our setting up in Switzerland we need to provide documentation - thankfully not as much as if we were to try the same thing in the UK, but the Swiss regulators do need to be able to see what we’re all about. We’re taking this as a good opportunity for some spring-cleaning, creating a fresh set of white papers, and sprucing up our websites while we’re at it, as @JimCollinson explains.
General progress
@Yogesh is making solid progress with his dashboard, which uses the ELK stack to ingest a specially curated metrics log and display results graphically, so the devs can spot any issues at a glance. He has been using ElasticSearch and Kibana on the same machine up to now, but that has proved to be very resource heavy (the droplet nodes produce a lot of data), gobbling up multiple GBs of memory, so he’s now looking to separate these concerns via having the setup as a multi-node cluster. That aside, it’s coming on nicely - as this pretty picture demonstrates. It shows a Metricbeat instance serving ELK with the generic system metrics. This will then be updated to visualise sn_node’s and SAFE Network’s metrics during testnets.
@danda and @davidrusu have been making good use of graphical monitoring too, in their case using flamegraphs to check out bottlenecks in DBC processing. Flamegraphs illustrate the contribution to the total time taken by all the individual processes in the application stack. They found that checking individual signatures when merging DBCs takes a long time, although this can be mitigated by batching them, meanwhile, DBC splits are dominated by rangeproofs. This realisation has led indirectly to a simplification of the DBC and mint design.
@oetyng is working on the network messaging flows and controls, where the whole system becomes more dynamic as nodes monitor their own capacity to handle messages and communicate this with each other, whereby the rate of sending is adjusted to the individual nodes.
This allows the network as a whole to manage its resource usage - such as messages sent, bandwidth, CPU and memory usage - and avoid various forms of overload on individual nodes as well as sections.
At the same time, we are for the first time getting a true priority ordering of messages being sent between nodes, meaning that the more important messages are always exchanged in the network before the less important ones. The nodes will ensure the network infrastructure is maintained, before spending energy on the user-facing services built on top of that infrastructure.
Monitoring of communication between nodes (failures, misbehaviour, etc) is being improved as a part of this, which will slot in to the dysfunction detection module being worked on.
Meanwhile, @heather_burns has been chatting to journalists and preparing to dive into the second draft of the UK Online Safety bill, which impacts small tech startups like MaidSafe as much as it impacts foreign social media sites. Our Heather also went viral on Twitter after commenting on the UK Minister for Digital’s request to Microsoft that they get rid of algorithms. 
"Dorries arrived at a meeting with software giant Microsoft and immediately asked when they were going to get rid of algorithms, according to an official given an account of the meeting." https://t.co/9JQvidG5rC
— Heather Burns (@WebDevLaw) March 16, 2022
Revised Project Whitepaper(s)
The original Safecoin Whitepaper was published some eight years ago next month. It’s interesting to look back on this document—go on, give it a read—of course for its ambition, but also to reflect on just how much has changed in the time since.
It covers a lot of ground, everything from the technical, to project governance, to token distribution. It should be obvious that it no longer stands up, nor keeps up, with the technical description and capabilities of the Network and its economic underpinnings, and nor does it capture the full nuance required when it comes to governance and the future of the Network.
We are now at a place where we need to revise it and set out our stall in the detail that you should rightly expect. We not only need to do this to fulfil regulatory obligations when launching the Network and its economy—putting it on a firm footing—but also to allow you, the community, to give formal input and vital feedback via the RFC process.
Rather than cramming it all into a single paper, as we did last time, we are putting together a series of discrete topics. This will allow for more precise discussion and hopefully smoother ratification, without unnecessarily crossing-the-streams as it were. You should be able to have your voice in this more clearly heard and understood, in other words.
So, over the coming weeks we’ll be drafting four individual papers:
- Network Design: Describing data Network and the Distributed Ledger Technology (DLT) that underpins it.
- Token Design: How the token system based on Digital Bearer Certificates (DBCs) will operate.
- Token Distribution: The building blocks of the economy, such as how the token supply will be distributed over time.
- Project Governance: How decisions will be made about the future of the Network, and the stewardship of the protocol.
And then I expect we’ll have a handy-dandy summary paper to tie it all together and summarise things in a digestible way for any overworked desk-jockey that gets landed with it at the regulator’s office.
So, look for that coming down the pipe in the next few weeks!
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!
That’s my only contribution to this side discussion 
I’ll be sailing along now…
principle to code. Really should be motivating SNapp devs to be 
