SAFE Network Dev Update - January 10, 2019


#1

Summary

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

Marketing

The Marketing Team are back and can’t wait to get stuck into 2019! Since the last Dev Update, we’ve been knee-deep in planning out the coming months, working on the release for Android developers, sharing our thoughts on what 2018 meant for the SAFE Network on Medium (all claps gratefully received!) and generally getting the work arranged amongst the growing team. In the coming week, @dugcampbell will be on Ernest Hancock’s ‘Declare Your Independence Show’ tomorrow and he’ll be doing an interview with the CryptoBeadles YouTube channel early next week also.

Recruitment

We are still on the lookout for a Network Engineer, more information can be found here - https://maidsafe.net/careers#networking_engineer

If you know of anyone with the experience required please send them our way (careers@maidsafe.net) :thumbsup:

QA

During the second half of the Christmas week, @pierrechevalier83 and @marcin took the opportunity to begin upgrading the Rust compiler version used in all of our Rust repos. Most of our crates are now on Rust stable (with the exception of SAFE Client Libs, which we are working on), meaning that we will no longer require an exact Rust version. “stable” will always keep our crates up to date on the latest version of the compiler, leading to less frequent compiler updates. The stable version also now supports clippy, Rust’s code linting tool, and rustfmt, Rust’s code formatter, so we were able to remove the nightly compiler from our build processes, as nightly was only needed previously for clippy and rustfmt. In addition, we moved most of our crates (apart from SCL, which is in progress) to use the 2018 edition of Rust.

We also considered the implications of moving to using MUSL builds throughout the Rust side for better support and reproducibility across Linux distributions. We had already merged a test PR for this for config_file_handler when we discovered that there is a lack of support for dynamic MUSL targets in rustc. From here:

There are still some rough edges with dynamic musl - it’s essentially a tier 3 platform and there are possible issues with backwards compatibility

As we currently mostly have static builds (SAFE Client Libs being a notable exception), we may still proceed with the plan to build with MUSL for static binaries throughout the backend, but not for dynamic libraries.

User Experience

The UX team continue to research user needs with a view to improving the UX of the SAFE Network.

Additionally, as part of its ongoing evolution, we have started planning the next version of the safenetwork.tech website to include UX and design enhancements. So thanks to everyone who took the time to give feedback on the latest version!

SAFE API & Apps

After the big browser update before Christmas, we’re now working away at smaller bugfixes with a view to producing more frequent browser releases going forwards. Over the festive period, we fixed some tabbing issues, added more testing, worked on some reconnectivity problems and tried to bend Travis’ Windows beta CI to our will (as well as some other smaller bugfixes, too).

Alongside the browser maintenance, there’s been some further exploration of RDF tooling, and usage of XOR-URLs. And while we’ve nothing concrete to show yet, we’ve fired into some initial draft functionality using the RDF setup described in the RDF / PublicName RFC.

Yesterday we had the first ever release of the safe-app-android and safe-app-android-dev packages. :tada: With these packages, developers can now develop native Android applications using Java/Kotlin. Along with these we also released a tutorial application which demonstrates their usage and a step-by-step guide to get development started, available on the DevHub. We also released an updated safe-authenticator-mobile POC which uses the latest APIs to authenticate users on the network.

SAFE Client Libs

This week we started making a concerted effort to document the libraries, both on a high-level for newcomers to the codebase as well as on a lower-level to track the details and moving parts. Most of the documentation is internal for now while we review it and think about how best to share it, whether it be in READMEs, module-level documentation, or otherwise. However, we did already move one of our internal pages, “Building from Source”, to the SAFE Client Libs README, and people can benefit from it right away.

Routing

The Fleming subteam have continued their investigations and discussions into the big questions remaining for the network.

Much of the focus this week has been on network restarts… how to retain the notion of trust in the event of a full restart of the network. There are various ideas being progressed, and there appear to be many factors which overlap with other requirements; for example vault upgrades, re-establishing trusted connections and state we‘d have to preserve currently outside the chain…

Work has also continued on PARSEC, with a few bugfix PRs having been written, reviewed and merged this week. We’ll be continuing to keep an eye on performance, with some thought going into further optimisations, but with the main focus shifting back to picking off more of the tasks related to handling malicious node behaviour.

Crust

This week we spent a considerable amount of time in changing the external reachability test semantics. Currently, we allow Vaults to connect to the network only if other people can reach them via an external IP address. Hence Crust executes the external reachability test before finishing a Vault connection.

We made this test more reliable and secure: First, it was easy to bypass this test, because the connecting peer was nicely asking to execute the test. From now on the connection listener will always check the external reachability. Although, this behavior can be disabled via a special function Service::set_ext_reachability_test(false) when needed.

In addition, the external reachability test is now executed during Service::connect() as well instead of only during connection bootstrapping. And finally, the test itself was changed from a simple TCP connectivity test to an encrypted Crust request/response scheme that ensures the external endpoint is actually Crust, not some random service running on the Internet.

We are also glad to see some extremely helpful community engagement who not only identified an issue with our example applications, but also stepped in and fixed it! Kudos to you guys :slight_smile: To encourage you to keep playing with Crust, we’ve added some documentation on how to use the example.


#2

First! This is the first time first this year! :stuck_out_tongue: I wish you the SAFE Network to go first, as it deserves! :smiley:


#3

Good work! I hope you are all rested after Christmas and are glad to be back! Looking forward to Fleming and its great to see the Android support!


#4

Third nerd

Thanks Maidsafe devs for this great update.

Love the mobile push

:stuck_out_tongue:


#5

This is great! Good that you want to improve UX of both the SafeNetwork and its website.
Mobile’s developing announcement is exciting!
We’re very close to Fleming!


#6

I don’t often comment here, but I do read and appreciate every weekly update.

The next few years might be very rough for the global economy. SAFE is one of the few lights of hope that I see.


#8

sorry to say but not so close. If you follow the Jira task list you will see still alot to be done there (approx 40 tasks still to be done). Its not something they mention though…


#9

Don’t underestimate @maidsafe team. They said it’s around the corner, so don’t be pessimistic :wink:


#10

thank god Thursdays are back! :blush:


#11

Excellent news. A good solid update to kick off 2019. Thank you all from David on down.


#12

lets just hope the corner is not few months long


#13

Well, it probably will be. SAFE is a very tricky project.

I have a lot of faith in the MaidSafe team, but we all have to be prepared for a long wait.


#14

Do something to make it happen instead of whining then. Can you join in with community vaults[Launch of a community safe network] ?
You will get plenty help and encouragement if you have got the bandwidth or can afford to get some AWS or Digital Ocean resources


#15

Ah nice, an interview with CryptoBeadles. Lots of views there. Also a lot of Hashgraph vids and fans, so be prepared! :slight_smile:
He has is own crypto project as well https://monarchtoken.io/


#16

It’s minimum few months lol


#17

so how can they call it right around the corner lol


#18

because several months in the background of 12 years are around the corner :wink:


#19

Need to ask them what is time frame “around the corner”, but we know that maidsafe like to take a time :slight_smile:


#20

thats not how you should make updates. Over this period of time 12 years- alot of people have lost interest and hope in this project, maybe some more will loose hope if this corner will be very long… just sayin


#21

They have just had a Christmas break, as they articulated they would. They were eating mince pies and drinking whiskey. You need to get your expectations in check.

FWIW, I had 2 weeks with my family and didn’t touch a line of code. It was great too!