SAFE Network Dev Update - April 25, 2019

Development Updates
1

Summary

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

Marketing

We’ve got a number of upcoming meetups to draw your attention to. First, @nbaksalyar will be speaking at the inaugural SOLID London meetup on Wednesday, May 22nd about how we’ve been using RDF within the SAFE Network. The following night Thursday, May 23rd there will be another SAFE Network: Brighton meetup. In addition, there’s going to be the first ever SAFE Network: Glasgow meetup on Tuesday 7th May and there will be another edition of the SAFE Network: Chicago meetup next month.

If you haven’t seen it yet, it’s well worth taking a look at @dirvine’s video interview for FutureScot in advance of his talk at the annual Digital Scotland Conference. There’s been another tweetstorm highlighting some of the key stories of the week and we’ve been working with @hunterlester who has released a tutorial running through how to build a Node.js application for the SAFE Network.

In the meantime in the background, the work on DevHub has been continuing and we’d like to again highlight the new MAID listing on the Bitker Exchange for anyone who might have missed the news over the last week or so. It’s probably worth mentioning that whilst we can never recommend one exchange over another, as with all exchanges for this listing to be maintained, there needs to be a minimum daily volume. In this case, the exchange requires daily trades of MAID of at least 1.5BTC value. Therefore, if you are intending on trading MAID, please do at least investigate Bitker whilst making your decision about where best to trade. We’ll continue to pursue options for exchanges that are cost-effective and we’re keen to do our bit to help ensure the community has alternatives where possible.

SAFE API & Apps

This week we integrated the safe_app_csharp repo with coveralls.io for code coverage.
We added additional unit tests for scenarios such as session disconnect and reconnect, creating private mutable data with specific XOR name and encryption key, updating private mutable data permissions for specific user public sign key. These unit tests can be used as a reference while building applications.

Also, we’ve added an Azure DevOps CI build pipeline to build and run .NET Core tests on Linux x64 platform. Check out the README file for updated code coverage report and build status for all CI services for the master branch.

We’ve recently made the necessary changes to the safe_auth CLI needed to build it for both the Mock and Non-Mock (e.g. Alpha 2) network, and we updated the README to explain how to build and run the CLI for any of these networks. We were also able to fix a couple of tests which were disabled and are now passing. One of the main next steps for this project is to research how should an API exposed as a web service look, what type of standard/s we can use for such an API which enables good interoperability with other SAFE applications, not only desktop apps but also mobile, IoT, etc. There are several ideas on the table we’d like to research, e.g. JSON-RPC, Cap’N Proto, Protocol Buffers, FlatBuffers, gRPC, etc.

The browser’s being prepped and tested for a new release coming soon. And preparation for the subsequent release is also ongoing. With another Electron version recently released (v5), we’re hoping to get back in sync there. This has in turn involved some more tweaks to the underlying FFI libs in the browser and safe_app_nodejs.

SAFE Client Libs

With the required changes made in the newly published version of safe_bindgen and with some help from @tfa we have completed the migration of SAFE Client Libs to the latest stable Rust 2018. :tada:

The improvement in the API also continues. We have renamed the use-mock-routing feature to mock-network to make it simpler to understand. More improvements are being planned and will be implemented soon! @lionel.faber and @yogesh have also started looking into the Redland libs for RDF to study and understand the API.

Routing

This week we completed the last of the main PARSEC work. With our unified team once again, we are focussed on getting our Routing code ready for Fleming.

This week was focussed on progressing the 3 parallel lines of development mentioned in last week’s Dev Update:

First, we continued with our state machine clean up: PR 1613 is progressing well and undergoing final testing. We aim to complete this work with currently in progress PR 1615 and PR 1616. With some additional fixes to allow our test to run robustly with PR 1612, we are getting in good shape for more developers to collaborate and contribute to the Routing code base effectively.

We also progressed with our Message Relay update. We have part of the implementation well underway and are trying to iron out some issues. We are aiming to keep that work minimal, but we are also learning from the issues we found and are refining our design on how the system needs to work for Fleming.

Finally, we have progressed our Node Ageing routing_model to the point we can start extracting some detailed implementation specification for standalone parts of the design with a view to start implementing them. More work is ongoing to provide the complete picture of the system and also to validate that it behaves as expected with additional tests.

Thanks again to @oetyng for his naming review! :smile: We followed up with an initial PR to follow his excellent advice in our Routing code.

QUIC-P2P

There is a lot of news this week as we’ve been continuing to direct our attention to quic-p2p.

We’ve finished the implementation of bootstrap, a crucial feature for a P2P networking library. When bootstrapping, we try to connect to multiple peers at once but select only one successful connection, enabling a quicker start-up of a connection with the SAFE Network. It also uses the bootstrap cache, a list of known good peers, which makes the connection process even more seamless, and also, importantly, prevents the possibility of censorship.

In parallel, we keep adding more automated tests for different scenarios, including bootstrap and peers with malicious intents. These tests helped us to uncover more edge cases and some bugs in the bootstrap logic. We’re fixing this now.

Usability also remains one of our main targets, so we’ve made quic-p2p more configurable by using structopt. It’s a Rust library which allows building command line interfaces in an easy, reusable, and composable way. It’s gaining popularity in the community lately and we are happy to follow this trend, making our libraries more interoperable with others.

Lastly, we don’t forget about Quinn, the underlying network protocol library we use. We proposed an optimisation for the stream read function which, as we discovered, needlessly reallocated memory many times, possibly affecting performance. The Quinn team has been very responsive as always and quickly produced a patch which is now merged.

88 Likes
3

First ! it has been a while since I was first

That is a solid update !! Thank you to the team for keeping the pace and for the continued effort. That makes me eager to be part of Fleming :slight_smile:

We’ve recently made the necessary changes to the safe_auth CLI needed to build it for both the Mock and Non-Mock (e.g. Alpha 2) network

Very pleased to see news week after week on this front. I’ll try to find a moment to give a test on the CLI

17 Likes
4

No rush with first comment

5

United we stand! Great work once again team, we’re picking up steam!

12 Likes
6

I would like to see a meetup in Indy. Chicago is pretty far for many of the larger Midwest metro areas, I think Indy would be an attractive destination with 5 major metro areas (Chicago, Indy, Columbus, Cincinnati, Louisville), and two midsize metro areas (Dayton, Toledo) in a few hours driving distance.

7 Likes
7

image
image409×528 86.8 KB

24 Likes
8

Great to hear all the progress that has been made.
Many thanks to everyone involved.
I cant wait till im reading about test safecoin, hopefully not to many more moons away.

8 Likes
9

Whoop whoop with the PARSEC news! Well done team Maidsafe! A huge building block to add to the SAFE system.

Keep building. It’s getting close :slight_smile:

11 Likes
10

any thoughts on doing a meetup in Canada? I am sure the decentral.ca guys would help give you a podium to speak from. I remember going to a meetup there to hear this vitalik guy pitch this little project he called Ethereum before 99.999999% of current holders had ever heard of it.

3 Likes
11

Thanks to all of the team for all of their hard work!

5 Likes
12

I think that is a fantastic idea. Would you be willing to do the work to set it up?

1 Like
13

Super update - very happy to hear that PARSEC is ready for alpha3 and that routing team is merged and crunching down the last bits for alpha3 … won’t be long now!

Great job team Maidsafe!

18 Likes
14

hey, sorry there I am a bit new to the SAFE network, I am reading & learning every day about it but there is so many things to learn! Could you maybe, and shortly explain what would allow safe_auth_cli please? I used to build SSO apps using GSS libs and mod_auth_kerb, does this work “like” that ?

Thanks

14 Likes
15

@BatchCode, welcome to the community! :slight_smile:

safe_auth_cli is a command-line implementation of the SAFE Authenticator. You can fine more info on that in the SAFE Client Libs wiki.

17 Likes
16

Great update Maidsafe devs

:exploding_head:

Keep the devtuts coming :clap::clap::clap::clap::clap:

:stuck_out_tongue:

7 Likes
17

Great update Team, as always!!

4 Likes
18

Hey! thanks for welcoming me and for your answer ! :slight_smile:

I will check this out tonight ! :smiley:
All of this is just looking like a ton of knowledge and power and security !
I hope the project will work as expected as it would be the future if so!!

Thanks a lot to the Dev team and the community for all the time you share between us!

7 Likes
19

I would love to, but one, I’m not that familiar with Indy, and two I have personal reasons for not being able to get involved with organizing and promoting Maidsafe events. Let’s just say it would be frowned upon in my line of work.

2 Likes
20

I have tested the safe_auth CLI on the community network and it also works on this network. Example session here:

# Compile from source (in safe-authenticator-cli directory):
$ cargo build
    Finished dev [unoptimized + debuginfo] target(s) in 0.49s

# Go to the generated directory:
$ cd target/debug

# Download crust config file for community network and rename it for safe_auth application:
$ curl -L https://raw.githubusercontent.com/Thierry61/tfa_safenetwork/master/clients/SAFE%20Browser.crust.config -o safe_auth.crust.config
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   385  100   385    0     0   1915      0 --:--:-- --:--:-- --:--:--  1915

# Export environmement variables for account credentials:
$ export SAFE_AUTH_SECRET SAFE_AUTH_PASSWORD

# Enter account credentials:
$ read -s -p "Secret: " SAFE_AUTH_SECRET; echo
Secret:
$ read -s -p "Password: " SAFE_AUTH_PASSWORD; echo
Password:

# Launch CLI application to get PUT balance and list authorized apps:
$ ./safe_auth -aby
Logged in the SAFE Network successfully!
Account's current balance (PUTs done/available): 57/943
+-----------------------------------------+---------------------+------------------+-----------------------------------------------------------------------------------+
| Authorised Applications                 |                     |                  |                                                                                   |
+-----------------------------------------+---------------------+------------------+-----------------------------------------------------------------------------------+
| Id                                      | Name                | Vendor           | Permissions                                                                       |
+-----------------------------------------+---------------------+------------------+-----------------------------------------------------------------------------------+
| net.maidsafe.safe-browser               | SAFE Browser        | Maidsafe.net Ltd | _public: {Read, Insert, Update, Delete}                                           |
|                                         |                     |                  | apps/net.maidsafe.safe-browser: {Read, Insert, Update, Delete, ManagePermissions} |
+-----------------------------------------+---------------------+------------------+-----------------------------------------------------------------------------------+
| net.maidsafe.examples.webhostingmanager | Web Hosting Manager | MaidSafe         | _publicNames: {Read, Insert, Update, Delete}                                      |
|                                         |                     |                  | _public: {Read, Insert, Update, Delete}                                           |
+-----------------------------------------+---------------------+------------------+-----------------------------------------------------------------------------------+

The procedure should work on any network (Alpha 2 or local network). Just copy the SAFE Browser.crust.config file of an operational SAFE Browser for your network and rename it to safe_auth.crust.config.

21 Likes
21

Did anyone use config file to pass secret and password to the safe_auth CLI?

As shown above, environment variables work, but I don’t succeed with the config file with the same values. Just to be sure of the values I created the config file with the following command:

echo "{ \"secret\":\"$SAFE_AUTH_SECRET\", \"password\":\"$SAFE_AUTH_PASSWORD\" }"

I get safe_auth error: Failed to log in: CoreError(No such account - CoreError::RoutingClientError → NoSuchAccount)

1 Like