Summary
Here are some of the main things to highlight this week:
- We released the first POC for the SAFE Mobile Browser.
- We published a blog post about Private Communications, the next topic in our ‘A Spotlight On’ series.
- We released a YouTube video highlighting the radical nature of the Perpetual Web.
- @fergish released a new podcast with UX Designer @jimcollinson.
Marketing
Happy Thursday folks! This week, we’ve been working on plans for this year’s event. Although we shared the idea of a hackathon a wee while ago, we’re keen to ensure that any event appeals to more than just developers, so that we don’t alienate those who are interested in SAFE but are not as tech-savvy. And replicating what we did last year in regards to the DevCon didn’t feel like the right move either.
So after much discussion, we came to the idea of a Summit-esque event in London, with guest speakers, a ‘build a dapp’ section and of course, the obligatory beers and pizzas. This, we thought would cater to everyone’s interests.
After scoping out the structure for the day, and working through costs and logistics for such an event we suddenly had a thought: Why does this need to be in a physical location? So we decided, instead, to host an Online Summit! With the community spread across the globe, this means everyone can join from the comfort of their own home without worrying about travelling. The set up will be fairly similar to the day we had originally planned - us presenting our latest work, an external speaker or two and we may (hint hint! 
) look to the community for a little extra help … stay tuned!
We’ll be announcing dates, schedules and how to be part of the day all in due course (but keep the week commencing the 11th November free). We hope you agree this will be a fantastic setup and we can’t wait to share more info!
We also published the third in the series of ‘Spotlight On’ which aims to go a little deeper into the ideology behind the Front End themes of Perpetual Web, Take Control of Your Data and the latest theme, Private Communications.
Private Communications is one of the most discussed network features by you and with good reason. Every day we hear stories of private conversations being exposed. We must be allowed to live in a world where we can communicate privately. And we’re on our way to making that happen. Go have a read, give us a clap or two on Medium or read the post here in the forum and share with your friends and family. This kind of content is perfect for those not so familiar with the SAFE Network as it fundamentally explains why we’re doing what we’re doing.
User Experience
Work on the Perpetual Web milestone continues at pace, with work concentrated on a smooth site creation and publishing flow in the Browser, and related modular apps such as the Data Manager.
As a nice wee bonus, we’ve also whipped together a YouTube video highlighting the radical nature of the Perpetual Web, the Future of History. It’s the first of (hopefully) many aimed at people new to the Network, so feel free to share far and wide.
Also, UX Designer @jimcollinson had a great conversation with @fergish this week over on the SAFE Crossroads Podcast. Well worth a listen for a deeper insight into the developing UX of the Network.
SAFE CLI
This last week we’ve been improving the implementation of the Name Resolution System within the CLI, with the addition of subnames. Essentially allowing safe://something.about.thenetwork to resolve, as well as declaring default behaviour for each public name. So, safe://thenetwork may by default resolve to the same data as safe://something.about.thenetwork, while another URL safe://anotherthing.about.thenetwork may also exist and point to another piece of data when the full URL is provided.
Alongside this we’ve also been making some tweaks to the command line interface itself, regarding how keys are handled, with the XorUrl generation (which now segments out content types vs. the safe data types), and with some help from the wonderful QA team, we’ve also been streamlining the CI process and PR process to automate some code quality checks.
We were also able to add some additional features to the CLI, like the case of being able to choose which port the authorisation request shall be sent to (with $ safe auth --port <port number>), and the ability to do a --dry-run for any of the operations supported by the files put and files sync commands, which will help users in understanding what a command would do before effectively applying the changes and spending the coins required for it. We will be extending the support for --dry-run to other commands progressively.
SAFE Mobile Browser
We are excited to announce that this week we released the first POC for the SAFE Mobile Browser! If you haven’t already tried the app, check out this forum post which has all the info you need to download and try it out for yourself. This is just the beginning of web browsing experience on mobile and we have a long way ahead. Read the Medium post to know more about the future plans we have for mobile browser and of course give us a clap.
New data types in SAFE Client Libs
We have been getting closer and closer to the completion of an important milestone in the project of bringing new data types to the SAFE Client Libs internals, providing a proof-of-concept for the two corresponding RFCs (which are both in the final comment period now). One of the main components of the library, Authenticator, which deals with apps registration and permissions, has been using the data types available only in the older (Alpha 2) version of the network. This has effectively obliged us to maintain two versions of the mock network implementation in Client Libs, supporting both old and new data types.
During the last couple of weeks, @lionel.faber and @yogesh have been working on replacing the internals of SAFE Authenticator to use only the new data types (including the new login packet type and changed account flow). This involved quite a lot of work because the Authenticator is not a small library by any means: there are lots of complex internal functions hiding beneath the simple API. The account flow change has been completed and merged now. The rest of the required changes upgrading the Mutable Data use in Client Libs are in progress now and a PR will be raised and reviewed during the next few days.
In addition to that, @marcin completed a refactor of the process_request function in Mock Vault. The main purpose of this change was to not return errors from this function in the usual fashion but to instead encapsulate them in the proper Response variant corresponding to the given Request before returning. The exception is if the Request could not be deserialised, in which case the only option is to return a standard error from this function (which we now handle properly at the call site, instead of using unwrap! which could panic). The refactor also added missing checks for mismatches between a requested mutable data address and the received data – so if we requested a Seq data but received Unseq, or if the retrieved data’s address otherwise does not match what was requested, an error response will be returned. Finally, this change reworked some parts of the function to make it simpler and easier to read. This refactor depends on several PRs raised to safe-nd which are currently under review: #78, #79, #80, and #83. These changes themselves are improvements on the safe-nd library and its API.
Vaults
The critical tasks for phase one are now complete and all that remains are some relatively small tasks which will clean things up a bit and others which will help lay the ground for upcoming phases.
Next step is to see the results of running the SAFE Client Libs test suite against an instance of the new vault. We’re expecting to see a few failures there - there are bound to be a few discrepancies between what vaults have implemented and what the client code expects vaults to have implemented. But such issues are probably (hopefully!) going to be trivial to resolve.
Most of the devs who have been working on vaults have now migrated to SAFE Client Libs to help get the refactoring done which will allow us to run the tests against a vault. We have set up a new project plan for this and started outlining the tasks required for completion of this project.
Secure Message Delivery
With the initial cards of the SMD project merged, we were able to start concurrent items on this project.
Recent work completed was to send out an acknowledgement on consensus of a section elders membership. In future work, a section will use that acknowledgement message to decide what proof to send with its following messages to the section that sent the acknowledgement. We are also updating our list of sending section’s public key so that we can verify and trust their future message.
BLS cryptography
This week, we completed our work on the Parsec side of things. After the last feature item, we carried out some cleanup and additional testing works. In particular, we tested that the Parsec behaviour is correct for events coming during, or after, the BLS key generation. Finally, we ensured we could dump and reload of the key generation state within tests.
With this part complete, we will pause further development on it, as we want to first progress further the Secure Message Delivery to allow for a smooth integration.
) and a cold beer. Will read the update in a mo.
and man people are gonna be stoked when they can visit sites with such pretty sub names. That alone is another topic for how this new internet has evolved.
