Maidsafe Dev Update - Marketing / User Experience & Website Design , SAFE API & Apps & More

Here are some of the main things to highlight this week:

We’re delighted to finally release our new website at safenetwork.tech . The culmination of many, many discussions, as we’ve explained in this forum post , this is very much a soft release to the community before we publicise it more widely. Please share any feedback you’ve got here in this forum topic  and, if you find any typos/bugs that need to be fixed, we’d be grateful if you could share details in that topic.We’re ready to release a new version of SAFE Client Libs with the new Rust API very soon (expect more news tomorrow!). The biggest change  is the removal of the Client struct from SAFE Core and the introduction of a new Client trait, which is implemented in SAFE Authenticator as AuthClient and in SAFE App as AppClient. This allowed us to only include core functionality in the trait and to decouple Auth- and App-specific functionality into the respective implementing Clients. Most importantly, this allows app developers preferring Rust to depend on the MIT/BSD-licensed libraries only.As a follow up to the milestone 1 announcement, @bart was interviewed by @fergish on SAFE Crossroads Episode 44 . Apart from PARSEC itself and why its release matters, they touched upon topics like why MaidSafe uses Rust, why consensus is Routing’s concern and what the job of a programmer looks like.This week, the Routing team has started preparing specifications for milestone 2 of PARSEC. This is about implementing dynamic membership: nodes may join and leave the network while consensus is ongoing. We are also focusing on documentation, testing, performance and malice detection. Each of these aspects is crucial to make PARSEC production ready for integration in the SAFE Network at milestone 3.Marketing / User Experience & Website Design

We’re combining the team update this week because as you may have already seen, we’re delighted to finally release our new website at safenetwork.tech . The culmination of many, many discussions, as we’ve explained in this forum post , this is very much a soft release to the community before we publicise it more widely. Please share any feedback you’ve got here in this forum topic  and, if you find any typos/bugs that need to be fixed, we’d be grateful if you could share details in that topic.

One final thing: the first SAFE Network: Chicago  meetup takes place this Saturday, with @nbaksalyar calling in to speak to the group. If you’re about, please help to support the event and enter into the conversations online on the various social platforms.

SAFE API & Apps

The safe_app_java library faced an issue with the boxEncryption test last week. While investigating this we uncovered a bug that had been the root cause of the freezing issues with the tests. The latest fix has solved this issue and provides potentially better backward compatibility on mobile platforms.

We are working on the safe_app_csharp API documentation. This documentation will help community .NET developers to browse and understand the APIs, their arguments, return type and supported interfaces.

The majority of Peruse’s PRs have been merged into the master branch, which is shaping up nicely. This branch is undergoing internal testing for the new feature set and integration with MaidSafe’s CI setup.

We’ve also fixed a slew of bugs discovered when working on our WebID demo apps and through internal testing. We’re now working to squash some smaller compatibility issues that arose and add some UI improvements before presenting this to our dear readers!

SAFE Client Libs

We’re ready to release a new version of SAFE Client Libs with the new Rust API very soon (expect more news tomorrow!). The biggest change  is the removal of the Client struct from SAFE Core and the introduction of a new Client trait, which is implemented in SAFE Authenticator as AuthClient and in SAFE App as AppClient. This allowed us to only include core functionality in the trait and to decouple Auth- and App-specific functionality into the respective implementing Clients. Most importantly, this allows app developers prefering Rust to depend on the MIT/BSD-licensed libraries only. We additionally reworked three of our examples to test the new API: gen_invites.rs, client_stress_test.rs, and self_authentication.rs. We moved these examples from SAFE Core to SAFE App; this allowed us to test the new API as exported by SAFE App, without depending on Routing or SAFE Core (except for optional convenience functions). We are quite happy with the API changes as seen in the reworked examples. We also fixed some unreported bugs in the client_stress_test.rs example, specifically the --get-only and --seed command line options not working properly.

There are also some good news on the SAFE Crypto front. In addition to working on a new version (0.3.0),
we’re also continuing to work on integrating SAFE Crypto with our
existing code, replacing the hard Rust Sodium dependency. The first
important step in achieving that goal is the integration with
Self-Encryption, the library serving as the foundation for many
important mechanisms in the SAFE Network such as data deduplication. Now
we have completed
this part of work and it should be merged upstream soon. Moreover,
we’ve made a small proof-of-concept and confirmed that the
Self-Encryption algorithm plays fine with the impending switch of the
symmetric encryption algorithm to AES-SIV (implemented by Miscreant ). In the end, this change should make the encryption on the network even more secure.


Routing

As a follow up to the milestone 1 announcement, @bart was interviewed by @fergish on SAFE Crossroads Episode 44 . Apart from PARSEC itself and why its release matters, they touched upon topics like why MaidSafe uses Rust, why consensus is Routing’s concern and what the job of a programmer looks like.

This week, the Routing team has started preparing specifications for milestone 2 of PARSEC. This is about implementing dynamic membership: nodes may join and leave the network while consensus is ongoing. We are also focusing on documentation, testing, performance and malice detection. Each of these aspects is crucial to make PARSEC production ready for integration in the SAFE Network at milestone 3.

In the specifications process, we are still at a brainstorming stage as we are covering each of the aspects above in depth to try and surface all design considerations early in the process. We made the conscious decision of investing the time needed to produce detailed specifications as we believe this will pay off in the coding phase. This is a lesson we took from our work on the last milestone as we are continuously trying to improve the way we work as a team.

In the next little while, you should expect to see some Jira tasks getting created as some of the areas listed above become well specified enough that we can cut them into small enough items of work.

Finally, we can’t wait for the latest addition to the Routing team to be joining on Monday. More details on this in the next dev update

Crust

Crust was ported to Tokio + futures a while ago, but Routing doesn’t use Tokio yet. Hence we have implemented a compatibility layer in Crust which exposes the event-based API that Routing is familiar with. Remember how last week we found a bug in this compatibility layer? When a remote peer timed out, the compatibility layer failed to emit a LostPeer event. This issue has now been fixed . We also wrote more integration tests: what happens when a remote peer is dropped (graceful shutdown) and when it times out.

When Crust attempts to connect to a remote peer, it tries multiple
connections in parallel: hole punched, direct connections, TCP, uTP,
etc. Eventually, Crust chooses the first successful connection and drops
other unused ones. There was a bug with such dropped uTP connections -
they were not closed gracefully. We finally fixed 
this issue this week. Now that we’ve stabilised Crust some more, we’re
ready to proceed with the integration of Crust into Routing