Summary
Here are some of the main things to highlight this week:
- Happy New Year and may you all have a prosperous 2020!
- @danda has joined the team
- @oetyng shared the Data Types Refinement pre-RFC. Please give it a read and say what you think!
- The
safe files addcommand now accepts a fileās content from stdin which enables piping other commands and uploading new files onto the network. - The CLI User Guide was updated with a new section for the
safe xorurlcommand. - Weāve begun early concept and design work on the farming distribution aspect of Safecoin.
Recruitment
Weāre delighted to welcome @danda to the team! Youāll most likely recognise his name, as heās been an active contributor to the safe-api repo for almost two months now! Heāll be initially working with @oetyng on the farming aspect of Safecoin - see his first contribution to a dev update in the new Safecoin Farming section below.
Vaults Phase 2
Itās been an exciting couple of weeks on the Vaults front. We are seeing the different parts such as Routing, PARSEC, Vaults and Clients come together as we edge towards the end of Phase 2a, i.e. Clients communicating with a single section. With the routing-vault integration fully complete and the new bootstrap process for clients implemented, vaults have the ability to spawn up and connect to each other forming a section. With the help of any one nodeās connection information, a client can connect to the node requesting the connection information of the other nodes in the section and then resend the request to multiple vaults and establish a connection to the network. With this, it can start sending requests for data and coin operations, which is precisely what weāve been doing via the tests in SAFE Client Libs. We are seeing good results with the client tests against a single section, however, there are a few failures as well due to random request timeouts. Debugging this has given us some good leads to follow up on, which are keeping us on our toes all day! Weāve tested the multiple vaults setup on Digital Ocean droplets as well and weāre seeing only the same few failures which means weāll be ready to deploy a working test net once weāve resolved these last few errors. So, fingers crossed!
At the same time, we are continuing to improve QuicP2P, our networking library. @adam moved the mock networking implementation from Routing to the quic-p2p codebase, making the Routing public API simpler and more self-contained. Now we can use the mock network (which emulates the data exchange at the low level) in vaults, clients, or other projects without having to depend on Routing. With that, and the other improvements introducing async code, we should be ready to release the new version of quic-p2p soon.
SAFE API
These past few days, we focused on finalising a couple of PRs that we started before the end of year break. A PR prepared by @danda last year was merged which allows the safe files add command to accept a fileās content from stdin which enables piping other commands and uploading new files onto the network.
Another feature which we started a few weeks back (suggested by the community in this forum), and now merged, was the incorporation of a new safe xorurl subcommand for the CLI which comes in handy when wishing to calculate the XOR-URLs for local files, without the need to upload them to the network. The CLI User Guide was updated with a new section for this new command. Note that for now this command requires the CLI to be authorised, we plan to enhance it in the future to remove this limitation.
safe-authd has been the main focus in the past few days, as its update command is not working and therefore it is not possible to update it in the same way as the CLI. We started fixing this by adding support for AWS S3 when deciding where to fetch the new releases from, as thatās where we are publishing safe-authd released binaries. We are also planning to start using S3 for the CLI binaries as itās faster for users to download them than from the GitHub releases page.
Once we have safe-authd fixed so it can be updated, weāll add a couple of new subcommands to the CLI to be able to install and update the Authenticator daemon by automatically pulling the corresponding binary from S3. This will improve and simplify the UX for the CLI and authd users.
Labelled Data, Indexing and Token Authorisation
@joshuef has been ramping up within SAFE Client Libs, learning the codebase and making a start on a basic implementation of Auth Tokens, and its integration into the codebase.
Thus far, we have a simple token/caveat setup along the lines of macaroons. This is now being integrated into SAFE Client Libs more solidly, using our existing AppKeys setup for signing the token, and validation, which should simplify things down the line.
The initial goal here is to replace our authentication mechanism with the tokens, which can then later be expanded to hold further info such as allowed labels, etc. (As we build out labels/indexing separately).
Data Types Refinement
@oetyng has written a new RFC for consolidating the various data types and the changes that they have undergone during development. Aside from that the RFC also introduces simpler naming for the data types. The discussions have already started on the forum, so head over now, give it a read and say what you think.
SAFE Client Libs
We ended 2019 on a great note with an amazing community contribution to the Client Libs codebase that helped us clear up our backlog. Weāve also added some small but useful features that would be very helpful in the application layers across the CLI, desktop and mobile platforms. Some of them are: supporting dry run when storing Immutable Data, more information when fetching the list of applications from the authenticator, and support for the GET_NEXT_VERSION constant for mutable data operations.
During his last couple weeks at MaidSafe, @marcin has mainly focused on tying up loose ends, reviewing PRs, and closing out his remaining assignments. This included some infrastructure work such as CI and GitHub Actions fixes. He also left some new documentation in the SCL wiki.
SAFE Browser (mobile)
In previous versions of the mobile browser, the information required to connect to the network was hardcoded in the app but now to enable users and devs to browse content from the local/shared vaults, the mobile browser gets the vault connection info from the authenticator app using an unregistered response.
As we are getting close to a release of the mobile browser with pWeb features, we have updated the app to support navigation between different versions of a web page on iOS. The Android platform already had this feature for the last couple of weeks.
We also fixed an issue related to the Rust logs which are stored on the userās device when running the app, so in the case of any issue these can be sent to the devs for troubleshooting and bug fixes.
SAFE Network App (mobile)
This week we worked on some more improvements in the SAFE Network App for mobile and itās looking even better now that weāve ported most of the images from the Figma design to the app. We also made some changes in the platform-specific code to improve the navigation UI/UX.
SAFE Authenticator (mobile)
The mobile authenticator app now shows the test coin permissions on the app information page for all authenticated apps. We made some improvements on the vault selection page to make it more smooth and in the process removed one 3rd party package which was causing some delay in the UI updating.
We have updated the minimum supported platform versions for Android and iOS. Now the minimum supported version for Android is 5.0+ and for iOS itās 11.0+. With these changes, we have finished development for all the targeted features/changes from the current project board and we are planning for a release in the coming weeks 
.
SAFE App C#
The safe_app_csharp library has been updated to the latest changes in thesafe-api master branch and the C# published immutable data put API now supports the dry-run flag. We are currently facing an issue with the bindings when trying to decode the authentication response message from the authenticator. Once this bug is fixed, we will be releasing a new Release Candidate package.
In parallel, we are looking into automating our GitHub release process from the Azure DevOps build pipeline on a version change commit. This is still under testing and once completed, we may deploy this for all the C# repos for a better release and deploy experience.
Safecoin Farming
Weāve begun early concept and design work on the farming distribution aspect of Safecoin, as described in RFC-0057.
This week we have been going over the RFC line by line, making notes, discussing, starting on design docs such as a data flow document and also writing some prototype pseudo-code for discussion purposes.
Our general goal is to implement the RFC as specified. Once that is completed and working we can test, model and tweak algorithms such as store cost and reward distribution as necessary.
Node Ageing
Following our initial work on promotion/demotion, we have focussed on cleaning up code and fixing the remaining test failures to support the remaining work for Node ageing.
We also addressed, with numerous PRs, some long-standing issues: removing some no longer useful code, upgrading some outdated crates, and continuing to clean up our routing API.
We are now looking at completing the items in promotion/demotion, with the parsec pruning issue already addressed, and some work in progress to establish trust between Adults and Elders.
Useful Links
Feel free to send us translations of this Dev Update and weāll list them here:
As an open source project, weāre always looking for feedback, comments and community contributions - so donāt be shy, join in and letās create the SAFE Network together
these test will have been some of the most anticipated in history. 2020 has long been seen as a date that represents an advanced future and to think it can be SAFEās birth year is all too fitting.
