Here are some of the main things to highlight this week:
- The key output from the Marketing Team this week was the release of the PARSEC Code yesterday. If you haven’t done so yet, please support the announcement by sharing and giving the Medium article as many claps as you see fit.
- This week we finished working on the Client API changes in SAFE Client Libs. The new SAFE Client Libs version, including all the changes that this PR brings, will significantly simplify developing apps for the SAFE Network in Rust.
- We have also released a new minor version of SAFE Crypto, 0.2.0. This brings some new features and breaking changes to improve the API and the quality of the code.
- As some of you noticed ahead of the official announcement, we completed the final task for PARSEC Milestone 1 this week. After the final bug was squashed, we were able to run tens of thousands of tests with random inputs all successfully reaching consensus in the same order in a small network.
- For those of you who like experiencing things with your own bare hands, we wrote up a little tutorial to get started with the PARSEC code, going from cloning the repository to generating graphs and visualising them with your web browser. Feel free to try it out and report any observation you have.
The key output from the Marketing Team this week was the release of the PARSEC Code yesterday. If you haven’t done so yet, please support the announcement by sharing and giving the Medium article as many claps as you see fit.
As a few people have commented on so far, this is the first time that we’ve gone down the route of having a ‘talking head’ style video explanation in conjunction with the written text and running the usual social campaigns. To make sure this is as effective as possible, we’d love to hear your feedback - was it helpful, could it be better, would you like to see more of this sort of content in the future? All feedback, good or bad (@dugcampbell assures us his ego can handle it!) is gratefully received on this.
The rest of the team’s focus this week has remained on the other two key projects - preparation for the launch of the new website and heading along to the Decentralized Web Summit. Next week, we’ll be re-recording the Getting Started Video again to deal with the sound issues we faced first time around. Finally, one last reminder about the Chicago SAFE Meetup (if you’re looking for a free SAFE T-shirt at the event, get in touch with @Sotros25).
User Experience & Website Design
The UX Team is continuously working hard to get the SAFE Network website released next week, without compromising on its quality. With the active support of the QA team, the website quality continues to get improved. On the other hand, the marketing team keeps improving the content of the website and @JimCollinson works closely with them to get those changes implemented.
SAFE API & Apps
This week has seen a plethora of PR reviews being worked on for Peruse, sorting out edge cases and upping the code quality therein. Page loading indicators, unending processes and auth-app bugs are all looking to be squashed very pleasingly (and @hunterlester improved the auth-app build process vastly, which should help debugging and testing going forwards), so we’ve started merging in these various branches.
In the land of Solid/RDF we’ve had a good week of solidifying (ahem) our POC applications and they are now looking like they’re somewhat usable by non-devs! We’re doing some final tests and tweaks before we start the internal testing of these applications.
We are continuously working on the .NET SAFE APIs and trying to provide better libraries which can be used by other developers for app development. This week we integrated StyleCopAnalyzers in safe_app_csharp. This will help us and the community to follow .NET coding standards when contributing to safe_app_csharp. Also, we have started working on the documentation which will include a getting started guide for .NET developers, API documentation and some demo app articles.
The safe_app_java project has seen some promising improvements over the past week. We were able to resolve a major bug that has been freezing our tests at random places during execution. All tests now pass consistently, except the
boxEncryption test which freezes only when all tests are run together. We’re diving deeper into this, exploring, developing and bug-busting our way to a release.
SAFE Client Libs
This week we finished working on the Client API changes in SAFE Client Libs. The next SAFE Client Libs release, which will include all the changes that this PR brings, will significantly simplify developing apps for the SAFE Network in Rust. On top of feeling more “native” to the SAFE Client Libs, the language will provide more safety guarantees to the developers. We think that this would be especially important for the SAFE Network and we’re putting an emphasis on providing a first-tier support for the Rust API. Now, we’re continuing to update the examples as a test of the changes and we can report that we are happy with the new API. The next important step is providing more extensive tutorials and documentation, so expect more exciting news soon!
We have also released a new minor version of SAFE Crypto, 0.2.0. This brings some new features and breaking changes to improve the API and the quality of the code. We have added a new function to encapsulate the hashing algorithm, improved the naming of the structures and functions, and added the fast mock pseudo-random number generator intended to be used for testing purposes (moving it from the maidsafe_utilities crate). These changes should also simplify the further work on integrating SAFE Crypto into Routing and Client Libs.
As some of you noticed ahead of the official announcement, we completed the final task for PARSEC Milestone 1 this week. After the final bug was squashed, we were able to run tens of thousands of tests with random inputs all successfully reaching consensus in the same order in a small network.
The code is available on GitHub at https://github.com/maidsafe/parsec. Please read the README file for an up-to-date description of what features are currently implemented and what features are still upcoming.
For those of you who like experiencing things with your own bare hands, we wrote up a little tutorial to get started with the PARSEC code, going from cloning the repository to generating graphs and visualising them with your web browser. Feel free to try it out and report any observation you have.
We were optimistic last week about an improvement to the whitepaper that we thought was imminent. On further investigation, we found that the approach led to calculations that are too costly for use as an effective mean of proving the point we were trying to prove. We will keep an eye out and still look for better ways of expressing our liveness proof in terms of a precisely defined synchrony assumption.
Finally, all hands are now on deck for specifying PARSEC Milestone 2. On the first milestone, we found that our initial timescales weren’t as reliable as we would have wished. To try and address this with the next milestone, we plan to spend as much time as needed writing the specifications in greater detail than we did for Milestone 1. Hopefully, this should give us a better feel for how far along we are during the next sprint.
Also, the coding velocity should increase in the coming weeks as @bart will be joining the coding effort. Previously, he had been mostly working on preparing Milestone 2 on the algorithm level and trying to improve our proofs. We are also expecting a new joiner by the end of the month, which should help us deliver future milestones with that extra wee bit of oomph
Last week, we finished the integration of safe_crypto into Crust but at the same time some tests were failing on Windows. This week we found the issue and we have to say it had nothing to do with the crypto changes It turns out the crypto changes also slightly changed how we use tokio-utp: now during the initial Crust handshake we flush the uTP stream. The problem was that in some cases the uTP stream flush would never finish and hang indefinitely thus preventing from proceeding with the Crust connection handshake process. The fix landed in the tokio-utp crate and now all Crust tests pass
Crust integration into Routing was paused until some crypto changes would be made. In the meantime, we wrote more Crust tests and discovered a bug in the compatibility layer: when a remote peer stops sending connection heartbeats, after some time we expect a
LostPeer event, which currently is not emitted. This is work in progress and it’s just a matter of days until it will be fixed