Summary
Here are some of the main things to highlight this week:
- The Front End team published a SAFE Network UX Roadmap and delve into how we’re going to get there.
- We released SAFE Browser v0.14.0, which includes fixes to some pesky bug issues, improved internal logging as well as an update to Electron v4.
- The new data types implementation is now feature-complete, putting an end to the data-types PoC milestone.
Marketing
Over the recent weeks, you’ll have all clearly seen the change in tempo and we’re not planning to slow down. Oh no!
Never one to shy away from a challenge, the Front End team have been sharing how they plan to design the network. So we’re not just focusing on all the Back End stuff (which is of course super critical) but we want to make sure every developer and every web user in the world can actually use the Network.
There’s also been a range of content this week, from the SAFE Gossip Newsletter (which should be in your inbox now) to our latest musings on the past fortnight's privacy and surveillance stories over on Twitter. And let's not forget we’ve now got a new events page on the forum, so at any given time you can see what the team are up to and find a meetup near you. We’ll need your help in keeping this updated though, so make sure you let us know when you're hosting your next meetup!
And finally, a shout out to community member @ ogrebgr who has developed a proof-of-concept prototype for a chat app on the SAFE Network. Pop over to the Dev Forum to find out more and to test drive it yourself.
User Experience
Quite a week for us in the UX Design team, as we finally get to pull the covers back on our approach to designing and explain how we’re going to change the world by putting this wonderful system in your hands.
What it enables—and how it'll transform your relationship with the web, your data, and even your thoughts—is rich and nuanced, so we're breaking it down a little.
Come and read about how we are layering up the features of the Network in a UX Roadmap and delve into how we're going to get there.
We’re going to continue discussing these milestones over the coming weeks so your thoughts and ideas, as always, are most welcome. Remember to clap and share to help us spread the word—we need your help in making sure the world hears us loud and clear.
And we haven't forgotten about those folks who don't use Medium, as you can find both part one and part two, right here on the forum.
SAFE CLI
This week we've been diving deep into the files functionality for the CLI, aligning with the updated client libs APIs and creating our own wrapper functionality for some of those. We have a first version of safe cat working with files uploaded via safe files put (against our internal mock functionality). safe files put is working recursively (i.e. you can upload whole folders + subfolders via one command).
We're setting up the functionality for creating FilesMap's (see the PNS/NRS RFC) structure with a pseudo RDF data representation for now. A FilesMap is the internal data representation for what is known to the user as FilesContainer's (it's been called NFS container so far), i.e. the type of container which is meant to link files with a virtual hierarchy. The first step is to have FilesContainer's implemented as Published AppendOnlyData, linking files which are uploaded as Published ImmutableData.
For the curious ones, something more visual should help in understanding it more easily :wink:
$ safe files put ./to-upload/ --recursive --pretty
FilesContainer created at: "safe://bbkulcb5hsl2zbsia4af5i7myv2ujbet7di4gx5bstduikwgobru67esqu"
+ ./to-upload/index.html safe://bbkulcax6ulw7ovqhpsindkybsum4tusmvuc7ovtr2bu5gj6m4ugtu7euh
+ ./to-upload/myfolder/notes.txt safe://bbkulcan3may5gmqxqonwaoz2cjlkuc4cflrhwitmzy7ur4paof4u57yxz
+ ./to-upload/img.jpeg safe://bbkulcbtiq3vg4xehqbrjd2gz4kljguqtds5ko5khexya3v3k7scymcphj
Note that the + sign means the files were all added to the FilesContainer, which will make more sense later on when we see how to use the files sync command to update and/or delete files.
Hopefully, we will be able to start implementing the safe files sync command in the next couple of days, once FilesContainer's implementation is in place.
Mock interface
Picking up from last week, we continue to refine the API for the new data types, test Safecoin and resolving issues with integrating Client Libs with the SAFE CLI. With the data-types now feature-complete in the mock vault, we are now optimizing the implementation and refactoring it to fit frontend requirements. The current milestone is nearing completion, clearing the path for the team working on the CLI to take over with full steam.
With PR 869 merged, we rounded up the new data types implementation, making all the three types feature-complete and putting an end to the data-types PoC milestone. Once the RFC process is closed we will review the implementation to ensure it aligns with the agreed outcome.
Recently, we created the new safe-nd Rust crate. This crate holds all the data types and identity structures that are common to both Client Libs and Vaults. With the vault implementation off to a good start, a number of breaking changes came into the safe-nd crate. The team took the call to address these changes now to avoid any technical debt in the future. Moving forward, teams working with Client Libs and Vaults will be working closely together on a compatible interface that will make switching to non-mock simpler than ever.
The next steps would be to adapt the components of Client Libs such as safe_authenticator and safe_app to make use of the new data types. A project plan is already in place. We will be adding more tasks and kicking off this milestone soon. We are also starting to put some thought into the FFI layer which (with some SAFE Bindgen magic :wink:) will allow the API to be accessible from other programming languages too. Exciting times ahead!
Vaults
With last week seeing the general structure put in place, this week saw work on implementing RPCs and client communication. First out of the gate is storing and retrieving immutable data. We welcome 
SAFE Browser
Another piece of fantastic news this week. We've been working towards the release of the next version of the SAFE Browser. We've got a good batch of (150+) commits of fixes and features coming to you with version 0.14.0. So whats new? This version includes fixes to some pesky bug issues, improved internal logging as well as an update to Electron v4. But don't take our word for it, go and download the latest version now!
Integration of quic-p2p into Routing
Most of this project was merged last week :tada: so work has been focused on simplifications and clean up. Always feels good when you can wrap up a project, especially as now we can shift more resources to Vaults which is top priority.
Reliable Message Delivery
Reliable Message Delivery is another component we can soon place in the completed column with the last task now in review :smile:. This means we can swiftly move on to the next step which is Secure Message Delivery and BLS.