Here are some of the main things to highlight this week:
- A new blog post on what it means to be a permissionless network.
- UX design for the PWeb browser continues.
- Published an update to the XOR-URL and NRS RFCs.
- Released an interim bug fix for iOS mobile browser testers.
- Started the deprecation of legacy APIs.
- Migration of the SAFE Authenticator to the new data types and APIs.
- Work on Secure Message Delivery continues apace.
- Please check out the updates to the SAFE CLI User Guide!
Another week, another shedload of updates to share with you this Thursday!
In Marketing, we published a Medium post on what it means to be a permissionless network. We’ve explored the growth of network gatekeepers and why we believe the SAFE Network, with its open-for-all approach, is the only way forward. You know the drill team: please clap and share to spread the word (and the forum version is here too).
Another tweetstorm this week, with stories ranging from the life of a private surveillance firm (thanks to the community for sharing this one!), to research uncovering a tool with the ability to alter messages within Whatsapp. Go have a wee look here. We do always check the stories on the What’s up Today thread so thanks to everyone who keeps this thread so vibrant - it’s a great help!
And finally, last week we sent out another Newsletter . If you’re not already subscribed, then what are you waiting for?! Sign up today!!!
We are now deep into the UX design for the Perpetual Web Browser, as we grapple with the nitty-gritty of the inner workings of the interface. It’s far less glamorous a job than you might imagine, but exciting nonetheless: powering through all the design intricacies of user flows when creating, editing, publishing, and updating sites on the Network.
No screencast for ya’ll this time, but another is in the pipeline… promise!
So, good solid progress, even in the face of annual leave disruptions. In fact, we’ll be moving on in the next phase of work to tackle the UX of permissionless account creation, management of identities and the start of Vault UIs.
During last few weeks, we’ve been working on our own XOR-URL encoding format as part of the CLI PoC implementation, and we’ve reached a point at which we consider we have everything we need (in such a format) to support all the envisioned use cases. Apart from the aspects previously discussed around the original proposal, the new SAFE data types also brought some new challenges to the design. This is why we created a PR to update the original XOR-URL RFC which we shared yesterday. Please join us in the review and discussions around it in its own discussion thread here.
Implementation-wise, we incorporated some nice features during the last few days to the CLI and its API which allow users to use both XOR and NRS URLs interchangeably in any command (or API) which expects a safe:// URL. In other words, once a
FilesContainer is created and a public name is linked to it using the NRS (Name Resolution System), the
$ safe cat command can be used to retrieve its content with the
FilesContainer XOR-URL or with the mapped NRS-URL. Or transferring coins from a
Wallet can be done using a destination
Key XOR-URL or NRS-URL created for it. As you can probably see, this is already showing we can now transfer Safecoins to human readable URLs, are you able to do that with other crypto?
We’ve also implemented a first version of what will become the foundations of the pWeb (Perpetual Web). Every change made to content that is uploaded to the SAFE Network as Published Data, is perpetual. This means a new version is generated with any amendments to it, (whilst older versions remain available forever). With the CLI (and its API), it’s now possible to retrieve not only the latest/current version of a published content (like a website), but also any other previous version. This is currently being supported by allowing any safe:// URL to specify a version. This has also resulted in an update to the PNS/NRS RFC, so please feel free to do more discussing over on the Dev Forum.
Another really cool feature recently added is the ability to update the CLI binary with just a command:
$ safe update. This cannot be used yet as we haven’t released the CLI as a binary package, but when we do, users will be able to update it by simply running this command which checks for any new available version of CLI and self-upgrades.
The SAFE CLI User Guide was updated with details about all these new cool features, so please review it if you’d like to try them out or understand them a bit better - and as always please let us know if you find a way to improve it.
SAFE Network app
Good progress has been made the last week, with more of the basic application functionality integrated (alongside more tests and updated dependencies). We’re now focusing on ensuring we do the UX team justice and that the app looks as lovely as the designs, as well as tying in the initial work for managing the apps into the UI so we get some proper visual feedback and the like.
SAFE Mobile Browser
After the release of v0.1.1, we worked on fixing the bug in iOS that prevented the browser from connecting to the SAFE Network via mobile/cellular data and today released what we believe is an interim fix so it can be tested in the wild. If you are registered with AppCenter as an iOS tester for us, then please download this new version and let us know whether this works on your mobile/cellular network.
If you want to register as an iOS tester for us and get access to our authenticator and browser apps to your device, then see the forum post here for details on how to do so.
Meanwhile, the work for v0.2 has been in full swing and we have already completed some tasks including fixing an image download issue on iOS, updating the progress bar to show page load progress, enabling landscape mode for iPhone devices and some code refactor work.
New data types in SAFE Client Libs
The time has arrived to get rid of the legacy APIs! The experimental branch of SAFE Client Libs has been seeing a lot of updates this week with the conversion of its internals from the older API to the new ones. After the redirection of the legacy API, we were able to integrate with quic-p2p and use it to connect to a local vault and run our tests against it instead of using the mock vault. This allowed us to start deprecating the older APIs completely using only the new ones in the internals, FFIs & tests.
We have completely deprecated our old Immutable Data with @lionel.faber raising https://github.com/maidsafe/safe_client_libs/pull/947. This required a few adaptations to the
Storage trait in the Self Encryption repository. This now includes an additional function to generate the address with respect to the desired Immutable Data variant (Published or Unpublished) in the picture.
There were also bug fixes and unit testing going on in parallel. @marcin worked on a pretty important bug fix which allowed revoked apps to read unpublished data. Now, we will inspect every request from an app that is a GET for unpublished data. In this case, we make sure the app is authorized (that is the requester’s account contains its public key). We have updated our revocation tests to account for the new behavior (including that we no longer re-encrypt data, as mentioned below). @lionel.faber has been busy writing tests in the
safe_app module which verify the workings of the AppendOnly Data APIs in various scenarios including permissions checking between owners and apps.
Another major revamp in SCL was the SAFE Authenticator’s migration to the new data types and APIs. The Authenticator now makes use of the new data types and APIs in its internal mechanisms, discarding the older ones. Various key structs like the
Share_Mdata etc., have all been updated to the new Unsequenced Mutable Data.
The revocation and recovery operations have been adapted to the new implementations. Re-encryption has been ripped as the permissions checking semantics have changed with the new data types. We now are close in completing our current milestone (linked in the project plan above), with only the
safe_app module’s adaptations left out, which is underway. With this ending, the whole of SAFE Client Libs will be then using the new data types and approaches with all the older ones removed.
With all that, we should be ready to completely remove Routing from SAFE Client Libs in favour of QuicP2P, which is another ongoing project which is nearing completion. We have moved SAFE App to use quic-p2p too now, and in parallel we’re working on the minor (but necessary) things like using configuration files for providing the quic-p2p config. We are aiming to stabilise the current development branch in SAFE Client Libs soon and make it available to use for the front-end team.
Secure Message Delivery
We continue to progress the development toward getting the initial parts of Secure Message Delivery functional.
We ensured that some state is the same for all elders in a section, which we call ‘shared state’. We merged PRs which cover our view of our own section history; our neighbours we connect to as well as the remaining sections in the network. A soon-to-be-merged PR, fixes in the same way our view of neighbours’ view of us that we use to decide what information we need to send.
The initial work of sender verification is in a work in progress PR to be reviewed and discussed. This will be added to the work of using that to trust acknowledgement (already pushed in another paused PR). At this point this will complete the end-to-end view of the solution. As you can tell we have many PRs in flight as we pull all the parts of secure message delivery together in the absence of fully integrated BLS. This work is closing in on a solution right now and the BLS track (next) will complete the design, leaving us to move to node age, which is a large component indeed.