Summary
Here are some of the main things to highlight this week:
- We published a blog post about The New Digital Economy, the last topic in our series on the Front End milestones.
- Vaults phase one is complete.
- SAFE Mobile Browser for iOS and Android are both now available.
- Adding NRS commands to the SAFE CLI has been completed and is being tested by QA right now.
- Legacy data types are now deprecated
Marketing
How time flies - weāre in a new month already! If youāre eager to get a round-up of what we did in July, head over to Medium for a highlight summary (and the forum version here). Weāve reformatted the layout slightly to align better with the weekly updates and the project boards, so let us know if you like it.
We also concluded the series on the Front End milestones, with the final in the series, the New Digital Economy, going live this week on Medium and the forum so, as always, please show it some love . This article was also timed perfectly with the release of the Netflix documentary āThe Great Hackā (whoās watched it?). And while weāve wrapped up this series, weāll continue to explore these Front End themes as they become living, breathing parts of the Network.
As weāre now in August, this is also a timely reminder of what events weāve got going on. Weāll be at the Web3 Summit in Berlin with @dugcampbell speaking on a panel, and @joshuef and @cgray in tow. Weād love to catch up with any of the community while weāre there so drop us a line if youāre around. Straight after, there is a meet up in Brighton, with @jimcollinson heading down to speak all things UX. If youāve loved all the Front End focus this month, then you should try making your way to this meet up. And last up, the man himself @dirvine will be speaking at the Turing Festival, which is in Edinburgh, with a talk entitled: Secure the Data, Not the Hardware. All the details including locations, dates and registration/tickets are all over on our events page. Hope to see you there!
To finish on some team news, weāre sad to say that Krishna, after a 4.5 year stint in the Chennai office, is off to pastures new. As with most big decisions, this was not taken lightly, in fact, Krishna had been thinking about leaving for a few months. However, with the Chennai office still in its infancy, he took on the task of making sure it was established properly in order to run smoothly. And it is; the office runs like clockwork, and thatās due to a lot of hard work by Krishna.
The good news is what Krishna will be doing now. Alongside his wife, they run a community-based restaurant: they give profits they make back to their staff and community. It was the principles of MaidSafe that inspired them to build their restaurant in such a way so that it was all about giving back. Not only that, but we hear the food is fantastic!
Krishna has been well appreciated by the team in Chennai and everyone else at MaidSafe who has worked with him. We wish him all the best for his future and weāll no doubt see him in and around the forum!
Recruitment
We continue to recruit for Software Engineers to join the team. Previously, our sole focus was to recruit Rust developers, however, we have changed the requirements of the role.
We are now looking to hire a Senior Software Engineer who can work across both front and back end, who has experience with one or more of these languages: Rust, C#, .Net, Java, JavaScript (and the willingness to learn other languages with us). If you head over to our careers page on the MaidSafe website you can find additional information on the role.
SAFE CLI
The POC public name milestone has been completed and is being tested by QA right now. This enables adding public names: safe nrs create safe://duper.cool -l <target xorurl>
, adding subnames to existing names: safe nrs add safe://super.duper.cool -l <another target xorurl>
AND removing subnames if you should want to do that safe nrs remove safe://super.duper.cool
. All of which should form the basis of the next generation of websites on SAFE. For those who want to toy around with this against a mock-vault
, you can follow the instructions in the user guide.
From here, weāll soon be looking at how best to integrate these new APIs with the SAFE Browser in some - experimental - form.
Other than that, thereās been several PRs adding more tests, and improving the UX of the CLI with more clarity around wallet keys and payment for operations with a new --pay-with
flag for certain operations (which would otherwise fall back to the accountās default wallet).
SAFE Network App
Weāve been steadily improving the initial prototype here, with PRs for menu options, window and user preference management all having been merged in the last weeks. From the get-go, weāve been using TypeScript in this project, and have been pretty fastidious in setting up E2E test functionality too, all of which should hopefully keep the application stable as we continue to iterate on this project.
SAFE Mobile Browser
After last weekās mobile browser POC release for Android, we started to work on a new iOS app release setup. Thanks to the community members - @Nigel, @upstate, @feinberg, @seasonedirate - for their efforts and positive feedback, this allowed us to test the release setup.
Using this new release setup, we can easily distribute the existing and upcoming mobile app to registered iOS device users without having to build it from source.
We are happy to announce that SAFE Mobile Browser v0.1.1 for Android and iOS is now available . Check the forum posts (Android releases, iOS release) to install the app and start browsing websites on the Alpha 2 network.
It is worth noting that this release includes one known issue where iOS users are unable to connect to Alpha 2 if they are using their mobile data instead of connecting to WiFi. But donāt worry, an issue has been raised and the team are working on resolving that as soon as possible.
This release includes some bug fixes, weāve added some nice features like enabling a zoom in / out feature on Android devices, and now you can open any safe://
URL directly from any other app on iOS devices (like email, contacts, notes) .
All the features targeted for v0.1 have been released and we have already started work on new features for the upcoming release(s).
New data types in SAFE Client Libs
Itās been yet another action-packed week for the SAFE Client Libs team. Over the last week we merged some important changes into the experimental branch that included using the new account packet flow for create account and login, and replacing PUTs with Safecoin to pay for mutations. A client now uses a deterministic identity generated from the userās credentials which is used only to put
, get
and update
the account packet. This identity was previously held within Routing so we could use it to sign requests sent to vaults. In order to make the Client Libs easy to integrate with quic-p2p, we removed the field from Routing and replaced it with just the public ID (since thatās the only field which would be held by the quic-p2p connection). This made the introduction of quic-p2p into the Client Libs quite simple.
Another significant change implemented this week was the deprecation of the older data types! Yes, thatās right. The legacy data types have been deprecated and the client API now only sends / receives data to the mock vault via the new data types. This is another important step towards integration with the vaults phase one. We were able to do this quickly by keeping the existing Client API as it is and converting data at the API layer before sending it to the vaults. This completely avoided all breaking changes in the test suite and FFI layer.
Now the library is only missing the final piece of the puzzle, quic-p2p, which, by the way, is being integrated very quickly.
Because Routing dependency is not a part of SAFE Client Libs anymore, we came up with a new design to represent connections to Vaults without Client Libs having to know anything about intricate details of the network structure (like which group of Elders we should connect to). Despite having only one Vault in the Phase 1 milestone, we decided to think ahead and prepare for the introduction of sections. So instead of sending requests through Routing, we connect to a group of Vaults and send requests to everyone in this group. In the coming few days we will be ready to do integration testing of SAFE Client Libs with the new Vaults.
And while a part of the team integrates quic-p2p in SAFE Core, the updating of the test suite to use only the new Client API has already started. Weāve started changing the internals of some modules and tests to use the new API directly instead of going via the older API and conversions, as previously mentioned.
Today we identified a required refactor of the Self-Encryption crate which now assumes the address of the data is its hash which is not the case for unpublished immutable data, causing an address mismatch and thus Error 404 More details in this GitHub issue. We are excited about all that the upcoming weeks hold in store for us and hope you are too!
Vaults
As youāll see from the project plan, Vaults phase one is complete! We managed to get the final few tasks coded, tested and merged this week, and even found time to get some niggles and todos picked off. This has included some cleanup work in safe-nd.
Weāre hoping within the next week to have the ability to test phase one vault by running the SAFE Client Libs test suite against it. At this time we will release the vault and update SAFE Client Libs. In addition, the CLI tool will also be available for everyone to get used to working with Safecoin and payments.
Now weāre moving on to the next exciting installment of vaults: planning for phase two (of four).
Secure Message Delivery
We are now progressing three tracks of development all converging to get Secure Message Delivery functional.
On the main track, we are putting together a PR that will provide the signatures and chain of proofs linking to the last version of the sending section we were trusting. This will give us a great end to end view of the solution but may need parts of the other tracks to complete before we can fully test it and merge it.
We also progressed the parallel track with this PR and more is coming. This will allow us to know which version of our section other sections trust, and use that to send the shortest possible chain of proofs when sending a message. This is critical: In the normal case there is no proof to send since other sections will very quickly come to trust our last version, but without it we would send many proofs.
The final track aims to ensure all elders in a section have exactly the same view of the network, so they can always take the same decisions. Some preliminary work is now complete and we are making progress on the main body of this work.