Summary

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

@jimcollinson created a YouTube screencast to give a sneak peek at what the UX team has been working on during this design sprint: Editing and Publishing sites on the SAFE Network.

The milestone for having files containers supported by the CLI has now been fully implemented. See the CLI User Guide for detailed information about how to use the new files put , files sync and cat commands.

, and commands. We released SAFE Browser v0.14.1 to fix a few minor bugs.

Marketing

A short but sweet update from the marketing team this week. We put out our fortnightly tweetstorm today exploring some of the top stories that we’ve read this week. We’d love the community to be part of this so please send any news our way and we’ll include it!

Work hasn’t stopped on the exploring the Frontend milestones either. While last week we published a spotlight on the Perpetual Web (and @JimCollison has some more amazing updates to share below), next up we’ll be exploring Take Control of Your Data: this takes a look at users’ private data and really explores how our data today lives in the hands of others - and what this means.

This isn’t just blue-sky thinking or an impossible idea. No, we’re well underway with the work to bring control back to you, the user, and make it a reality. Our post will be live tomorrow so we’ll update you with a link when it’s out

The next two themes we’ll explore are Private Communications and The New Digital Economy, so we hope you enjoy these as much as we have enjoyed writing them.

And finally, a reminder about the SAFE Network: Glasgow meetup that’s taking place next Monday (15th July). Our very own @Jean-Philippe will be chatting about what he’s working on, together with a few folk from Ayr HQ. Getting to meet the community face to face is an incredible luxury so we are excited to see you all there!

Project Management overview

Its been a few weeks, so time for a wee project overview update

In the interests of continual improvement we’ve tweaked the gantt chart so you can see a today line, a high level progress bar for each project and a nice big green tick for completed projects (so satisfying!!)

You can see progress compared to the last update posted as well as having added in the Frontend milestones

As you can appreciate this is still at a high level, but it should continue to give you a visual on what’s going on. Enjoy

User Experience

In this design sprint for the Perpetual Web Browser, we’ve turned our focus from Laurel’s ‘Read-Only’ Persona, to Tony and his needs as a content contributor.

How can we make it fast and straightforward for Tony to create, edit, and publish a site on the SAFE Network, taking advantage of the serverless infrastructure, and the versioned perpetual data?

After last week’s challenges with presenting the wireframes, @jimcollinson whipped up a screencast to walk you through it:

Feel free to ask your questions, or make observations in this dedicated forum thread.

SAFE CLI

Files Command project plan

NRS project plan

The milestone for having files containers supported by the CLI has now been fully implemented. During the last week we were able to take it through our internal testing process to fix some issues and stabilise it, so we are very proud to share this with you today. Please do give it a try! As a quick reminder, with this milestone finished, we are now able to perform the following operations from the SAFE CLI (still using an internal mock rather than using SCL):

Create (published) FilesContainer s by uploading files and entire folders with the $ safe files put command

s by uploading files and entire folders with the command Retrieving and rendering the content of FilesContainer s and files (published ImmutableData ) using XOR-URLs with the $ safe cat command

s and files (published ) using XOR-URLs with the command Updating an already created FilesContainer by sync-ing it up with local changes made to files and folders with the $ safe files sync command

Why would we really like you all to try this out? Well, this should show you how easy it will be to upload data onto the SAFE Network and keep it in sync with local changes. It has never been so easy until right now, you should definitely check it out!

The CLI User Guide has been updated with detailed information about how to use these new commands (look for the Files and Cat sections in the ToC). We strongly suggest to read it thoroughly before trying them out. If you have already pulled the CLI code and built it, remember to pull the latest code from the master branch to get this functionality.

$ safe cat safe://hbyzg58n3kk8d7jiopppdtdry3ckiwp1z7mq3g8oiao5mrrm55twthgj5w/lets/safe/the/world.txt _,--', _._.--._____ .--.--';_'-.', ";_ _.,-' .'--'. _.' {`'-;_ .-.>.' '-:_ SAFE Network '=. ) > {_/, /~) |/ `^ .'

We’ve also been working on a new milestone and project plan which has been agreed and set up this week. This new milestone is about NRS (Name Resolution System) and the integration we started with SCL API. The main goals can be summarised as follows:

Implementation of a first PoC for the $ safe nrs create , $ safe nrs add and $ safe nrs remove commands (note that add and remove work on subnames)

, and commands (note that and work on subnames) Support for being able to $ safe cat NRS-URLs, with subnames and paths

NRS-URLs, with subnames and paths Have all existing commands and APIs work with SCL API, which would allows us to also run CLI tests with SCL’s “mock-network” feature

Note that in the same way as the previous milestone for FilesContainer s, we will be using a pseudo-RDF for the NRS Containers’ data representation for now. This is just to allow us to focus on the UX and UI of these commands, and we will be able to adapt the internal implementation to use RDF in the medium term without affecting the APIs or the CLI user experience.

SAFE Browser

Today we released another version of the SAFE Browser. You can download the latest release, v0.14.1, from here.

This small release was created to fix a bug we picked up internally in the last few days, where logs were not being populated on Windows platforms. We also included a small fix for a tabbing issue.

Mock interface

Project plan

The mock interface in SAFE Client Libs has been through a bit of maintenance this week. A number of internal improvements and semantic fixes were made.

The team has been working very closely with the Vault team which helped identify and fix a few issues. For example, previously the different variants of the same data type used the same address namespace. This resulted in the potential for address collisions that needed to be handled in the Mock Vault. After some discussion, we decided to use separate namespaces for each of the data type variants.

We also added some fixes to Append Only Data RPCs to fetch values for specific keys and to properly check the required indexes when appending to the permissions and owner fields. You can learn more about all of the changes in the project plan linked above. These changes are necessary for a hassle-free integration in the future with the real network.

A couple of feature additions were also done during the week, where we worked on the LoginPacket RPC handling. Formerly known as the AccountPacket , it is being revamped to fit the changes defined in the RFC, including the name change. This will now enable us to move on to the safe_authenticator module which makes use of the now called LoginPacket for logging in clients via self authentication.

Next in line, we will start planning quic-p2p integration. Mock quic-p2p will be replacing the current Mock Routing which Client Libs makes use of, to simulate the real network while handling all the RPCs in the Mock Vault. This will be a separate milestone for which we will be defining tasks soon.

Vaults

Project plan

Work on the Phase 1 of Vault has been coming along nicely. We completed a major feature this week with the implementation of the mock Safecoin (as defined in the RFC): now we support operations for balance creation and coin transfers.

There’s a trick, though: in the first iteration we allow all operations to pass through even if a user doesn’t have a sufficient balance, that’s including the balance creation. So yes, it is possible to create an unlimited Safecoin balance (isn’t that nice?).

We also completed Immutable Data (both published and unpublished) and implemented operations for the Login Packet data type (renamed from “accounts” to cause less confusion).

We are now moving on to Mutable and Append-Only data. Once that’s done, we’ll be ready to move onto integration testing with the SAFE Client Libs.

Integration of quic-p2p into Routing

Project plan

The work on resending messages on failures is almost complete. We merged 2 PRs on that front: one that implements the actual resending logic (#1705) and one that fixes some performance issues (#1709). At this point, the Routing part is done.

There is still work required on the quic-p2p side to update the API to include a feature that Routing now expects. While quic-p2p was functionally complete, we needed an enhancement to quic-p2p to complete the integration: quic-p2p will have to emit a confirmation that a sent message will no longer fail when it knows that this is the case.

With this almost out of the way, our efforts are shifting towards implementing Secure Message Delivery.

BLS cryptography

Project plan

On the BLS front, we continue implementing our DKG (Distributed Key Generation). The DKG is a way for the peers to collectively generate their secret and public keys.

We now have two new PRs merged. One enables us to record scenarios involving DKG and replay them in tests - this is important for our tests and benchmarks suite. The other one enables running a DKG with only a part of the section participating. This feature will be required for handling splits: The two halves of a section will need to run separate instances of DKG in order to generate keys for the new sections that will be born in the split.

Next up, we are looking at allowing peers that are not yet full members of a section to participate in the DKG. This will be essential anytime a new peer is joining. They’ll be able to obtain their own secret key and provide a share of the section signatures.

At this point we’re looking to split this big item into more manageable sub-tasks now that all the foundational work is complete and we have much better visibility.