Last week, we released the third dev tutorial (WebRTC video chat app).
The next tutorial is going to conclude the tutorial series for now. The existing tutorials are still going to be supported, but there will be a period of no specific activity in terms of new tutorials. We are currently discussing the future of SAFE Launcher and we are about to present a couple of RFCs related to that.
Our idea is to change the SAFE Launcher to a SAFE Authenticator, which would only be used for authentication/authorization process: Once an app has a token, it will be able to directly interact with the SAFE Network (using a language binding we provide). We want to make this change in order to be able to support mobile platforms (Android/iOS).
Also, we would like to bundle SAFE Authenticator directly within SAFE Browser. That way users wouldn’t have to download two separate apps. They could simply download SAFE Browser and use it to create an account or log in to an existing account.
See this Dev Forum topic on for more info.
SAFE Launcher
We have been working on the last example that was planned for the tutorial series. We are also trying to fix some of the issues that were raised in the safe_launcher repo.
SAFE Core
Async safe_core is done. All examples and test cases pass. We will continue to keep it in dev (along with self_encryption which is also in dev) until all frontend code interfaces with it, works and finally the frontend guys give us the green flag, at which point we will move it to master and do a crate publish.
We are now looking into sketching out the paradigm of how things are going to work with mobile and have some sort of design that will work well both on desktop and mobile. This of course changes the FFI layer and the fundamental concept of Launcher as a single point of contact (doesn’t work on mobile) but we think we can have an agreeable solution to it (we are working on putting up an RFC). Currently we are analysing from the point of view of safe_core, routing and safe_vault and noting down all that we will require in terms of changes to support a SAFE Authenticator based paradigm.
Routing & Vault
We’re still in the process of re-enabling the mock Crust (i.e. without a real network) tests, one after another, and fixing all issues that we discover that way. Last week, we’ve fixed several issues with splitting groups (when a group is large enough, it splits into two new groups). We feel that some of those fixes are workarounds that we won’t need with a slightly better organisation of the joining process – keep a node in a separate container until it has made all its connections and is ready to route messages – so we will address that next.
At the same time, however, with group splits being functional, we will enable the tests for merging groups, and for churn handling in general.
Once that is done and all issues are resolved, we will move to in-house network tests with actual vault binaries, and work towards stabilising these: After a change to such a fundamental concept, we expect to find some regressions all along the way. However, this stabilisation process remains our top priority: We want to produce vault binaries that users can run from home as soon as possible.
In parallel to these efforts, we are working on the new message routing/accumulation algorithm: We ripped out the old one and are replacing it with collecting signatures in the first hop. After that is done, there are two more steps to secure message routing: Each group will have to maintain signed member lists of all neighbouring groups, and then it will need to append the appropriate list to each message it is relaying. That way, a message sent from group A via B and C can be validated by the recipient D: D knows the members of C, who have signed and attached a list of members of B, who have signed and attached a list of members of A who have signed the message itself.
Finally, in our discussions of the security simulation results, we concluded that:
- We want to extend the simulation to include more attack scenarios and make sure it makes worst-case assumptions.
- We will look into ways to allow larger groups without impacting performance.
