Here are some of the main things to highlight this week:
- David, Viv, Gabriel, Nick and Francis have been representing MaidSafe and speaking about the SAFE Network at the Decentralized Web Summit in San Francisco.
- We’ve refreshed the MaidSafe website on a temporary basis.
- There has been some press activity with our latest Medium post and an article in computing.co.uk.
- Having applied for mozfest 2018 we’re looking forward to hearing back from the organizers - see the registration status here.
- Josh has written a summary of the WebIDs and RDF data and we’ve got detailed posts on the new APIs and how RDF data is being stored on the network.
- The team has been looking to improve our project management for safe_app_java and set up milestones for safe_app_csharp and safe_mobile.
- DevHub will soon see more developer guides for desktop and mobile apps.
- There’s been more work on the PARSEC FFI with tests having been written, the API defined and implementation started.
- The Crust Team are redesigning SAFE Crypto to make it more flexible and reliable for all other libraries to access.
Marketing
Maidsafe.net
As some of you may have already noticed we have revised maidsafe.net. This is a temporary site to bring the site more in-line with the new safenetwork.tech site and reduce the duplication of information across platforms. The current design style will act as a stop gap but we feel it more accurately represents the vision of the company and our continual push towards SAFE Network branding. As previously mentioned this division between MaidSafe as a company and the SAFE Network as the platform is an important distinction as although we are currently the primary developers bringing the Network to fruition we hope that in the future we will not be. This is a community project and we want to create that distinction. The SAFE Network is for the people by the people!
Decentralized Web Summit
This week much of the focus has been in sunny San Francisco as David, Viv, Nick, Gabriel and Francis have been spreading the SAFE word at the Decentralized Web Summit. Following a successful networking event on Tuesday (see pictures below with Tim Berners Lee) the team presented in the San Francisco Mint and to audiences around the world via the livestream on the SAFE Network and our recently work with SOLID. You can watch it all back now. Once the team returns to sunny (unlikely) Scotland we will share their findings, news and plans but until then here are a few pictures from the Summit so far.
!
Press
In response to our presence at the Decentralized Web Summit there has been some great press activity. First off read our latest Medium post as we focus on the Global Visions theme of the Decentralized Web Summit. David has also been featured in computing.co.uk’s recent series from the Summit.
Mozfest
As some of you will be glad to hear, we applied for mozfest 2018 that will take place Oct 26-28 in London. Anyone can follow the registration process on github where we expect to hear from the organizers at some point in September.
What would be the title of our presentation, you ask?
Taking back the web! Set up your first SAFE website in under a minute
SAFE API & Apps
As promised, we’ve a couple of posts detailing on the new APIs and how RDF data is being stored on the network. And for those who don’t want to go to deep, @joshuef has written up an overview on medium too.
As well as this (while some of the team are at the Summit), we’ve been adding in some smaller tweaks to the POC apps and the Peruse WebId release, repairing CI tests after the recent merge-splurge, and setting up PRs for updated versions of the client libs. Which we’ll be rolling in to updated versions of safe_app_nodejs and Peruse once that’s all tested and verified.
As the team is busy fixing the JNI errors we’ve been facing, we have been polishing up our project management process for safe_app_java. This is to provide better visibility to the community with regard to roadmaps and development progress.
This week we setup new milestones for safe_app_csharp and safe_mobile. Now community can track work progress for both projects using boards and milestones in official GitHub repositories. API documentation for safe_app_csharp is in review in this pull request. We have started to work on developer’s guide for .Net developers which help them while developing desktop and mobile apps for SAFE Network using .NET Core, .Net Framework and Xamarin. These guides will be published soon on SAFE Network DevHub website.
SAFE Client Libs
This week we’ve continued work on the PARSEC FFI, having written the tests and defined the API. Writing the tests first has helped us to design an API that we think will be simple and easy to use. We have begun the code review process for this portion; in the meantime, we’ve already started implementing the API, a task which is proceeding quickly. Note that some details of the API might change based on code review or other factors.
We’ve been also involved in helping the front-end team with finding a cause of a critical known bug that is observed by some community members. The bug occasionally shows up in the Peruse browser that uses the latest version of SAFE Client Libs. We’ve been debugging deeply inside the Client Libs code and came to the conclusion that this error originates on the front-end side because of the garbage collection that happens prematurely. The front-end team will now be investigating it to figure out the root cause and apply a fix.
Routing
Following up from last week, the routing team has continued brainstorming all aspects of dynamic membership in PARSEC. We have now crystallized our understanding of the different ways malicious peers can be detected and punished. With this understanding, we also know exactly how to safely handle adding and removing peers, a.k.a: dynamic membership. This work is of crucial importance as it relates to the security fundamentals of PARSEC which itself is the bedrock of the routing layer of the network.
In these discussions, we have also covered the separation of responsibilities between routing and PARSEC. Even though routing integration will only be the subject of the next milestone, it is important that we define the boundaries now so we know what exactly must be handled by PARSEC at the present time. This will also allow us to turn the PARSEC crate into a fully self-contained consensus mechanism that anyone can reuse for their own permission-less network use-cases.
We also made good progress on the property testing front, with Rust’s Proptest library. The tests gained the capability for automatic simplification of the randomly generated schedules. To explain this in more detail, we have to describe the simulation model a bit first.
The virtual network for testing PARSEC is simulated in the following way:
-
First, a list of peers and a list of transactions the peers will vote for are generated.
-
Next, a schedule is generated. The schedule consists of steps, and during every such step:
- A node can perform a local step, which consists of receiving incoming messages and optional sending of some messages
- A node can fail and stop responding forever
- A node can vote for a transaction
All of the above things happen with some probability.
-
Every sent message has a recipient and a delay. Delays are also generated randomly, with some given distribution. They are the numbers of global steps that have to pass before the recipient will be able to receive the message during its local step.
-
There are some more options: votes can get duplicated, failures can be planned deterministically instead of randomly, etc.
So, the schedule is basically a list of events, each of which is one of the three possibilities listed above (local step, failure, vote).
When we run a test with Proptest, we define some range of parameters we want to test. The parameters include the number of peers, transactions, the probabilities of nodes taking a local step / failing / voting, and all the other options. What Proptest does, it starts somewhere within this range, then “complicates” the case if there is no failure, or “simplifies” it if there is a failure. This way it attempts to find the simplest set of parameters that exhibits a failure.
We defined a set of rules that say what cases are simpler, and what cases are more complex. For example, the less peers in the network, the simpler the case. The higher the probability of a node taking a local step, the simpler the case (it’s closer to a synchronous setting), etc.
Given a schedule generated for some given set of parameters, we can sometimes simplify it directly. For example, if we reduce the number of peers, we can take out all the events that concern a subset of peers. Say, we throw peer A out, and then: if peer A was scheduled to take a local step, this event gets removed; if it was supposed to fail, the event gets removed, etc. This way we can increase the probability that a modified schedule will still exhibit the same failure, or no failure at all.
Unfortunately, we currently can do this only with the number of peers and the number of transactions. If, for example, the probability of a peer taking a local step changes, we have no easy way of modifying the schedule - we have to start from scratch and generate it again with the new parameters. We are still looking into ways of improving this situation, but it doesn’t seem to be straightforward.
We have been contacted by Antonio Sabado from workonblockchain.com who would be interested in having some of us present the SAFE Network and PARSEC in a deep dive presentation in King’s College, London some time in September or October. We are still working out the details, but it seems that @bart and @pierrechevalier83 will be able to attend that event together and spread the word around our core technologies to that deeply technical audience 
. Expect to hear more from us on this in the near future 
Crust
A lot of our libraries heavily rely on SAFE Crypto which recently we discovered is not flexible enough. So we decided to redo it, hence Crust and Routing will be affected. But better sooner than later 
The new SAFE Crypto design is work in progress and when everybody approves the changes, we’ll have to redo the Crust integration into Routing. No worries though, it seems like it’s gonna be lots of robotic changes rather than a complex task.
We also did some improvements on our automated tests. First, there was one netsim based test failing in Crust. Which is now fixed and all Crust tests are passing. Then we have peer inactivity tests that check what happens when remote peer becomes irresponsive. The usual peer timeout is about 2 minutes, but we don’t want to wait that long during testing - we have multiple test cases So we made peer inactivity timeout configurable which can be set per test basis.
. J/k, tho there still looks to be a bit of a plate of different areas to solve.
