Summary
Here are some of the main things to highlight this week:
- Instead of a SAFE DevCon, we’ll be organising a SAFE Hackathon in London (probably in mid-September).
- @dugcampbell and @bart will be speaking at the SAFE Network: Brighton meetup next Thursday, March 14.
- SAFE Authenticator Mobile v0.1.1 was released yesterday.
- The Routing team released a first post on Sybil resilience.
Marketing
Over the past few months, a number of you have been asking about the plans for SAFE DevCon. After a great deal of conversation around the topic - and various calls with event organisers in different locations (Berlin turned out to be favourite), we’ve now made a decision to take an alternative approach this year. As a result, we’ll be organising a SAFE Hackathon in London (probably in mid-September).
There are two key reasons behind the decision. First, supporting the growth of the community - specifically around developer engagement - is a key area for us. There’s no doubt that a conference with talks would help to bring the community together. However, we’d really love to see more DApps being developed out in the wild. Talks can be given in a range of places and times - from meetups to conferences to straight-to-YouTube - but in order to attract more SAFE Developers, we need to continually work to support more independent SAFE DApp developers building out their ideas. With that said, the second key factor here is timing for the event. Running a May event was the original plan. However, we need to be certain that Appendable Data has been released before the event - hence the target date of September. That’s not because we believe it will take that long, but we want to completely avoid any issues with people being away on Summer holidays, etc.
Why is the release of Appendable Data key? Simply because any DApps developed before that time will require updating afterwards. So the choice is between running an event where most DApps need ‘fixed’ afterwards - or putting something where the DApps created can survive (and, from a marketing perspective, help to show off the Network).
We appreciate this might be slightly disappointing to those of you who were looking forward to the next community get-together. Hopefully though the reasons will make sense - and, of course, there’s nothing to stop any of us holding regular SAFE meetups with talks etc during this time. Speaking of which, quick reminder that next Thursday, March 14, @dugcampbell and @bart will be speaking at the SAFE Network: Brighton meetup for those that are in the area!
One final thing: @dgeddes and @frabrunelle have been working on putting far more detail into the Discourse Discobot greeting that each new Forum signup receives. Now, each newcomer will have a more defined path towards achieving their trust level status in order to access the Alpha 2 Network. We’re also working on another way to streamline things on this front - watch this space!
SAFE API & Apps
The SAFE Authenticator Mobile UI/UX enhancement milestone has come to an end and we are glad to announce that v0.1.1 of the application was released yesterday. See this post for more information. You can download the latest APK from this GitHub release. Have a look at the changelog for the list of feature improvements.
This week we have been checking off the last few tasks in the safe_app_java milestone. With the project’s test suite considerably improved, we will set it down to simmer as we move our focus to other design aspects.
The browser has seen more code quality enhancements, with further refinements to linting in JS and TypeScript, ready for us to get this all squashed so we can implement stricter checks on the code as part of the automated CI process. We’ve also been wrestling Travis’ Windows implementation with the aim of reinstating automated windows builds for the next release.
There is and has been an ongoing effort to generate more technical documentation for some of our front-end projects, especially those that can help new developers know where to start from when contributing to these packages/libraries. We recently finished a first draft with enhancements on the safe-app-nodejs package which is currently under review. Suggestions and help from the community to review this PR would be very welcome and appreciated.
We’ve been following closely and learning from all the contributions made on the forum by @oetyng, with a lot of ideas and experiments he’s been working on, which may be applicable to many projects or to solve some challenges developers will face when storing big data on the Network. Therefore we wanted to not only highlight it but also show our humble appreciation to his valuable contributions to the forum. For your reference: Infinitely appending data, DataStore over appendable data.
SAFE Client Libs
This week we found success in implementing a proof-of-concept for RDF on the SAFE Network, developed in Rust. We were able to arrive at a coarse, yet working demo that currently lacks testing, error handling, etc. RDF triples were successfully serialised to key/value pairs and stored on disk. We were also able to retrieve them, deserialise them into triples, and handle them as an abstract RDF model (which allows to read, add, edit, and query the data). Next steps would be to enable storing RDF in the network by stashing it in a Mutable Data and experiment running SPARQL queries on it. Because the key/value representation of triples we use perfectly translates into Mutable Data, this task should be less complicated. An exciting time awaits! RDF is coming!
On the documentation front, we continued publishing new pages to the Client Libs wiki including “Mutable Data”, “Client trait and implementations”, and “GET and PUT reference”, and wrote several soon-to-be published brand-new docs.
In addition to this, the first draft of the RDF RFC has been completed and the team have had a chance to look it over internally. After addressing a few comments, the RFC should be ready to publish publicly very soon – we can’t wait for your opinions and suggestions!
Routing
Full steam ahead in the Routing team!
Happy that we had built a sufficient understanding of the Sybil implications of different designs, we decided to conclude the Sybil investigations for the moment. We released a first post on Sybil resilience to set the scene. This post already prompted a few interesting conversations. We are very grateful to the community for their invaluable insights 
. A follow-up post will highlight the key insights we gained during the last few weeks, so if this week’s post wets your appetite, stay tuned 
. We will also be very interested in hearing what you all have to say about these.
So with Sybil sorted for now, our Fleming discussions took a slight turn. If you remember, the initial aim of these discussions was to get a holistic look at a number of big questions to ensure that the way we put together Fleming won’t hinder future milestones. We have now had the time to discuss most of these in some depth and gained the clarity we were seeking. With this, we are focusing the discussion on the scope of Fleming itself and what practical decisions we will take for that milestone, often leaving a range of possibilities that testnets should help narrow down.
We continued working on the PARSEC whitepaper. We added a section on the common coin, making it fully asynchronous and wrote the associated proofs. Since we were touching up the whitepaper, we took the opportunity to conduct a thorough review and address some open issues with the initial wording. For instance, we addressed some of the points raised by the community and some other imprecisions we noticed. We are still doing a few touch ups and reviewing the entire paper thoroughly to make sure the changes are not introducing any inconsistencies. PARSEC v2.0 should be coming soon and we are very proud of it
On the PARSEC side, improvements keep happening. We fixed a hole in our concrete coin protocol by adding another type of sync event: Requesting. The issue was that it would be possible for a malicious node to pretend they had received many Request events. This could lead them to pretend they were more responsive than other nodes and decide the value of the coin flip. With the new Requesting event, inventing a Request is immediately detectable. There is a negative performance impact (roughly 30% degradation), but it is necessary in the current state of affairs.
Speaking of performance, we merged a change that makes PARSEC compute multiple stable blocks at the same time if there are multiple interesting payloads in a single meta-election. This change results in a 70% improvement in benchmarks that focus on reaching consensus on many events, but also opens the door for an even better improvement that we teased last week: the next step will be to bundle multiple observations into single gossip events so that the artificial limit on the number of transactions per second that we have at the moment may be lifted. Work on that front is still ongoing.
We merged a couple of improvements to the benchmarks themselves. One created some benchmarks with a larger number of events so we could profile the improvement from the changes we have in mind. Another change worked around a little bug in criterion that had our benchmarks report incorrect results for a couple of days.
Crust
We continue investigating into our dynamic connection manager where we were planning to have active (a definite session exists between the peers) and passive (cached connection info, but no active session) connections so as not to overwhelm systems with 1000s, or more, connections (as might be necessitated by Routing section sizes and connectivity story) but we are also keeping a keen eye on QUIC.
It seems QUIC has become a lot more mature with great stuff in its design spec that might solve many of our problems.
Some notable mentions could be (a) it builds on UDP which can give us the ability to keep socket-descriptor exhaustion under strict check by multiplexing many QUIC connections on single underlying UDP sockets (b) reliable and congestion controlled ( c) Address migrations and session suspensions and resumptions (d) in-built TLS handshake so that we don’t do our own secure-serialisation (e) multistreaming and stream prioritisation over the same single connection to a peer, etc.
The Rust crate we are looking into is quinn. It doesn’t have for example stream prioritisation implemented yet so there might be some features in the QUIC spec not yet in quinn, which we need, but they might be pretty easy to PR to quinn. This investigation along with dynamic connections is keeping us busy in Crust just now.
haven’t had time yet but that was a huge release that I haven’t fully enjoyed or utilised yet
