Last week, we released the first dev tutorial along with TEST 9.

The next tutorial will be announced in about 2 weeks. Our goal is to release a new tutorial roughly every 2 weeks (for a total of 6 tutorials).

The URL of the SAFE Dev Tutorials website is tutorials.safedev.org. The source code of this website is hosted on GitHub. Anyone can easily submit a pull request by forking this GitHub repository.

The source code of the SAFE Mail Tutorial app is also on GitHub. Even though it’s a desktop app built with JavaScript and Electron, it would be possible to build a similar app in other environments (e.g. a web application, a command-line application, etc.) and other languages (e.g. Python, Go, Ruby, Rust, C#, etc.) since the requirements for using the SAFE Launcher API are very minimal (developers just need to be able to make HTTP requests).

We don’t expect devs to build complex apps (e.g. a full-featured messaging app) right away, but we hope they will find these tutorials useful and will start using the new low-level APIs To give feedback regarding SAFE Launcher API v0.6, please use this Dev Forum topic.

API Documentation

We are planning to move the SAFE Launcher API documentation to a static website generator. We are exploring a few options and we will confirm which tools we will use next week. In addition to migrating the existing documentation, we will also add documentation for the new low-level API endpoints.

SAFE Launcher

We are integrating the CI this week for safe_launcher now that we’ve finished the React/Redux integration. There are few minor bugs identified with the SAFE Launcher binaries from TEST 9, they will be fixed this week.

After the initial implementation of the SAFE Launcher API for exposing low-level APIs, there are a few more APIs which are pending to be integrated. Along with that we are also planning to improve the efficiency of the low-level APIs by mapping them directly to the APIs in safe_core . To propose this change, Krishna submitted this pull request earlier today.

SAFE Core

We are now aiming to provide a common backend for low-level APIs and nfs/dns API paths. For instance, the directory hierarchy encryption scheme is being changed to the following: use a random secretbox::gen_key() for each private directory and store this key in the parent directory (and in the account packet for the root directory itself). Every time we modify the content, we will generate a fresh Nonce and encrypt the content. The final data will look like this: serialised(nonce + ciphertext) .

Apart from this, we are adding a few APIs that are wanted by Launcher - e.g. expose the version field of StructuredData and include the number of versions in versioned StructuredData in the data field itself for faster access.

Routing & Vault

A few more comprehensive tests for appendable data have been added and the routing table part of RFC 37 - Disjoint Groups is implemented and is currently in review. We are now working on integrating it with the core of the routing library.

There is also a lot of design work ongoing, and discussions about security measures like RFC 44 - Secure Vault Joining.

SAFE Browser RFP

@joshuef posted an updated version of the SAFE Beaker Browser yesterday.

SAFE Beaker Browser Updates (0.4.0) There’s an updated version (0.2.7) out now, which: should solve the packaging problems that have been plaguing linux users

has an integrated SAFE-JS API for app devs

blocks all http and https calls to the clearnet (localhost still enabled).

This week we are going to start looking at options for packaging the SAFE Beaker Browser with SAFE Launcher. For example, there could be a checkbox that lets users choose if they want to install the SAFE Beaker Browser at the same time they are installing SAFE Launcher. We will also need to think about the user experience (e.g. should there be a button inside the SAFE Launcher that lets you open the SAFE Beaker Browser?). We’ll start a discussion about this on the SAFE Dev Forum next week.