SAFE Network Dev Update - July 19, 2018

Development Updates
1

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 :wink:

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 :slight_smile:

80 Likes
2

First for a first time

edit: I enjoyed new website already. It is big surprise.

13 Likes
6

Second,… ok

5 Likes
7

Thanks so much for all of your hard work! The party is just beginning.

9 Likes
8

super cool new site! Thank you!!!

12 Likes
9

This is the Solid bit :slight_smile:

24 Likes
10

Website looks great :+1:

8 Likes
11

I see things all ‘coming together’ hopefully around the same time in the not too too distant future. :crossed_fingers:

Great job with the new site @maidsafe

16 Likes
12

Love the new site. Pleases the eye while getting the important points across. Great job.

12 Likes
13

How much of SAFE’s back end is SAFE network specific and how much is generalized PARSEC? It seems that there is a lot of focus right now on PARSEC and releasing it to the world in conjunction with the progress of SAFE reaching it’s milestones. That’s great and all and I’m just as eager to see SAFE completed, but I’m just wondering how much is PARSEC and how much is SAFE? Like can someone take the SAFE backend (PARSEC) and use it in their own project and how much of SAFE’s inner workings are PARSEC or otherwise are cross compatible with other projects?

On another topic I like the new website with it’s bright colors and such but it could use a site map or a clearer nav bar. Links to various pages seem to be scattered about and designed to guide the reader but if one is specifically looking for something it’s not as easy to find a topic in particular. Also while the SAFE accademy was put on hold there’s no reason not to link to established resources in the meantime.

8 Likes
14

Can’t wait to see this!

8 Likes
15

Ordering consensus is required to validate currently valid voters (nodes in a section/shard). From there we have group consensus/data chains/node age / secure message relay and that is just routing. Under that, we have crust (secure messaging, fully encrypted network membership and discovery). On top of that, we have personas and safecoin on one side (vaults) and on the other client API’s (apps etc.) where we are focusing on RFD/LDP via SOLID for a semantic new Internet.

There is a lot, we open source it all and know this needs to be done. In short, it’s just what has to happen, we took the reigns, but care not who does it. So far it looks like us who must, but who knows in the long run (hint, I think I do :wink: )

22 Likes
16

Wooooowwwwt, that website is stunning!

15 Likes
17

The new website looks excellent. One suggestion I have is that under Safecoin or whereever safe coin name is mentioned - lets clarify that SAFECOIN isnt available yet. You can’t buy them. Else there may be a few who go to website, like the concept and see safecoin name (without even clicking it), go and buy safecoin (the wrong one!!). There is a safecoin out there that does not belong to safe network so we should guide potential buyers until the whole copyright issue is resolved with the current safecoin TM holder.

6 Likes
18

As David touched on above, and we cover some in the recent SAFE Crossroads episode, PARSEC is just the algorithm and code that handles consensus on ordering of transactions/events. General formation and function of the network, security, connection, etc., is handled elsewhere than PARSEC.

Other decentralized systems could use PARSEC within whatever system they have or evolve. Also as David said, since SAFE is open source, other projects can take other parts and do with it what they find useful, but PARSEC is a specific function. It’s the difference between a consensus algorithm (or recipe?) and a consensus mechanism (close group, disjoint section).

6 Likes
19

The new website is a feast—really beautiful job!

Congrats and thanks to those who contributed.

8 Likes
20

Hey guys, I love how well it is developing, but my concern is the same as @Anonymous2020
Is it wise to keep doubling down on promoting safecoins as safecoins? Considering the amount of squatters, scammers and opportunists who are already launching projects under the name of Safecoins, wouldn’t it be better to think a new name for the upcoming hard release and promotion efforts?

5 Likes
21

Unfortunately, the website doesn’t look good on my laptop (1920x1080 at 150%). The structure is a bit of a mess. The overlapping ‘squares’ with images and text, don’t fit well together in this resolution. With the giant menu hovering at the top , and quite large fonts, and squares all over, it is difficult to get an overview or see the structure, which makes it hard to see at a glance what is important. It looks better in higher resolution or less scaling. Tested in Firefox, Opera, Edge, Chrome.

3 Likes
22

The new website is great. The Timeline spells out the remaining steps (good to see that).

2 Likes
23

The website is sequentially perfect, incredibly sophisticated in its simplicity, I love it! Through it the SAFE net, is so easy for anyone to understand and be inspired! Amazing work!

8 Likes