Here are some of the main things to highlight this week:
- There was a fantastic series of three articles on PARSEC by FlatOutCrypto on Medium (you can check them out here - Part 1, Part 2, Part 3).
- The SAFE Client Libs team is releasing version 0.1.0 of the SAFE Crypto library on crates.io. The first release includes the mock version of the crypto primitives.
- The Routing team has been focused on finishing the implementation of PARSEC for the first milestone: a static network with integration tests and an example. All the features have now been implemented and we are starting to see some tests pass successfully.
The Marketing Team has spent the week working on a number of fronts across various projects. Work has continued on the website which is now nearing completion and also preparations for the Decentralized Web Summit which takes place in San Francisco in only a month’s time are now starting to come together. In amongst all of the usual weekly tasks, @dgeddes is also building out a plan for the evolution of the DevHub as we seek to make this as useful as possible for all.
There was a fantastic series of three articles on PARSEC by FlatOutCrypto on Medium (you can check them out here - Part 1, Part 2, Part 3). It’s really reassuring to see such a substantial and well-thought-out piece of work from someone who isn’t connected with the project so we’d encourage you all to spend the time reading through it and give it your support if you agree.
User Experience & Website Design
The glamour of page layouts and design reviews behind us, we’re now down to the brass tacks of implementation. No razzmatazz, no fanfare, no let-up.
Little to report this week other than hard graft. Markup wrangling, style sheet dunking, pixel slinging graft.
I know, I know, you want to see, to read, to behold! Well, we’re nearly there with the website folks, just let us have a few more moments with the code before she flies the nest won’t you?
It may not be that much fun for you guys to do more waiting—even though you’ve plenty of experience to fall back on—but at least give us this… It’s where the real satisfaction is to be found after all. I mean, who doesn’t enjoy cracking a San Pellegrino and laying down a sweet SASS mixin a Friday night?
SAFE Browser, Authenticator & API
Peruse tasks continue smoothly towards our goal of having a new package available to share soon. @hunterlester was fixing some bugs detected during the last few days for the shared MD authorisation requests and for the feature to reconnect to the network upon a disconnection event.
He has also just finished with the implementation for being able to customise the Peruse notifications, which is required to display all the information received within the authorisation requests in the popup. This is going now into our peer reviewing and testing processes. After these features are tested and reviewed, we’ll be moving forward with fixing some major bugs and other minor enhancements we want to have ready for the next release. We were also able to have the Travis/AppVeyor setup ready for the
peruse branch of the
safe_browser repo to be able to automatically generate the packages and have our CI tests running for this branch too.
The garbage collection issue in safe_app_csharp was fixed in the safe_client_libs and safe_bindgen repositories by @nbaksalyar. The relevant PRs (#651, #13) have been reviewed and merged. Also, we will update the safe_app_csharp bindings and the MaidSafe.SafeApp package soon.
We have updated safe_app_csharp to use Cake (cross-platform) build scripts in this pull request to perform many tasks which include downloading native libs, running InspectCode, building a .Net Core project and running tests. This script also has CI (AppVeyor) related code to upload InspectCode and test results to AppVeyor.
We also updated the safe_mobile repo via this pull request and now the SafeAuthenticator mobile app is using the latest bindings and the SafeMessages app is using our latest MaidSafe.SafeApp NuGet package (v0.1.0).
As the Java library slowly takes form, we are ensuring its compatibility on other devices, specifically on mobile through a bunch of instrumentation tests. Though a couple of blockers are slowing us down, we are working our way towards the inevitable release of safe_app_java v0.1.0.
SAFE Client Libs
During this week, we’ve been focused on SAFE Crypto and we’re releasing version 0.1.0 of the library. The first release includes the mock version of the crypto primitives. The real crypto primitives require more CPU time – while they’re not always necessary for tests, so the mock functions should improve the performance of tests in Crust and Routing.
The SAFE Crypto 0.1.0 release also marks the beginning of the move from the hard
rust_sodium dependency to the wrapper library. Eventually, we’ll be able to substitute the underlying crypto functions without involving the application code in Crust, SAFE Client Libs, or Routing. This is what we’ll be doing next: gradually refactoring the existing code to use SAFE Crypto instead of
rust_sodium, starting with Crust (for which we already have a work-in-progress pull request) and Routing (which is scoped in this JIRA task).
Continuing from the previous week, we’re getting closer to making the API in SAFE App public. We decided that the approach we attempted previously is not something we want to release as it had several shortcomings. However, it helped us to find a better way of proceeding with this and we believe we’ve found a solution that we’re happy with: instead of making SAFE Core indirectly aware of the Authenticator and SAFE App APIs, we’re going to reverse the dependency and make SAFE Core as abstract as possible, moving the concrete implementations into the respective higher-level crates. What’s more important, this approach won’t affect the public API directly and it won’t affect our FFI API in any way too. Instead, it will allow developers to use the familiar Client API in Rust. If you’re interested in more intricate details, please follow this JIRA task.
This week, the Routing team has been focused on finishing the implementation of PARSEC for the first milestone: a static network with integration tests and an example. All the features have now been implemented and we are starting to see some tests pass successfully. This is the kind of moment that gives butterflies in the bellybutton as we’re moving from a blind coding phase to a phase where we are actually able to see PARSEC doing its job correctly on some of the simple tests. There are still a few tests that exhibit bugs. We are tracking these down and fixing them as we speak.
Preparing for the next milestone, we also added a section to the whitepaper and to the RFC explaining how to handle dynamic network membership. This turned out to be easier than planned, which meant that we only had to add one paragraph to our whitepaper rather than write a whole new whitepaper.
On the communication side, we also reviewed and gave some feedback to FlatOutCrypto who wrote an excellent in-depth explanation of PARSEC in the three-part blog post linked above.
Finally, we are making some touch-ups to the PARSEC whitepaper in preparation for submitting it to the Crypto-Economics Security Conference 2018 (CESC 2018).
This week, Crust faced massive changes throughout its codebase affected by new encryption primitives we will be using from safe_crypto. Its integration is now completed and going through our QA process.
We also took this chance to make p2p more flexible. When the p2p crate does hole punching it queries so-called rendezvous servers for its public address. These address queries are also encrypted so that no one could hinder hole punching - same as any communication in Crust. Until now address querying was hard-coded in p2p itself. But together with encryption changes, we made it more flexible: you will be able to plug custom TCP and UDP address querying algorithms. This way you can even use STUN together with p2p.
Thanks to netsim we discovered another uTP issue. When the network has some packet loss and uTP acknowledgement packets are lost, they are not resent. Bug cause is clear and PR is coming soon. One takeaway from this is that we need to do more testing with simulated failures