As many of you may already know, earlier this week we were able to release a new version of the SAFE Browser (v0.8.0), which changes were mostly related to the safe_app/DOM APIs while also improving the developer experience. This was accompanied by the release of new versions of the Email and Web Hosting applications, which have been updated to be compatible with the new API and Authenticator. See last week’s update for a summary of the API changes.
Custom browser
Today, we are releasing an initial version of the custom browser, which we first mentioned in this dev update. It’s a proof-of-concept and has a few limitations as detailed below, but it looks very promising!
Data chains
Another thing to highlight this week is that we just published a post about data chains on the Dev Forum. It is a slightly deeper discussion regarding data chains, but does try and stay high level enough to be able to convey the important messages. Along with these aspirations, it is hoped that this document is also as brief as possible, allowing discourse and hopefully agreement on the fundamental aspects of the network.
Marketing team expansion
In addition to all the development work, we have also been fleshing out our marketing strategy over the past couple of weeks and have started implementing some of our plans. While it is not our intention to get into specific details at this stage, as to do so would put us at a competitive disadvantage in some cases, it will be much more community-centric, and in fact a couple members of the forum have already been helping with some early ideas and have been very useful sounding boards. Mapping out the strategy confirmed our suspicions that we would need more internal marketing resource and we are delighted to announce that Dug Campbell will be joining @SarahPentland at our HQ from next week.
Dug has been a fairly central part of a small but flourishing Bitcoin scene in Scotland for a few years now. He organised Scotland’s first Bitcoin conference in 2014 and even spoke about it later that year at TedX Glasgow. He has been in touch with MaidSafe for the past few years and with his experience within other technology companies (Sky Scanner and Mii Card) in a variety of roles and his easy-going relaxed nature, he’ll be a great fit helping to plan and execute MaidSafe’s marketing and outreach strategy. Welcome aboard Dug!
SAFE Authenticator & API
We’re happy to show off an initial release of the custom browser. You can download it here.
For developers, the browser is rebuilt around a React/Redux application for the UI. This allows for much more robust testing. The release process has been automated across all platforms, and we’re working towards some real end-to-end testing with the CI also. The browser also features a more comprehensive logging setup, and the ability to work against the live network without packaging, which should help speed up dev/debugging considerably.
For end users, the browser features the DOM API and a new (currently very simple) setup for authenticating apps. You should be able to authenticate both web apps and desktop apps using the latest version (0.5.3) of safe-node-app package.
Known limitations:
- No localhost support in this release
- Placeholder authenticator messages (the prompt doesn’t show the app’s info and/or permissions requested as the current authenticator does)
- Potentially slow startup (network connection occurs on startup as opposed to first fetch)
- No reconnect notifications (if you start without the invite IP updated, you’ll need to restart, for example)
- UI has not been a focus yet
- No page loading indicator right now
The comments plugin example web app has been updated by @srini to be compatible with the latest changes in the DOM API as well, thus it can now be used with the latest SAFE Browser v0.8.0. The two versions previously published on the Alpha 2 network were updated and can be accessed at the same locations:
- Non-Editable Comments Plugin: safe://www.safe-examples
- Editable Comments Plugin: safe://blog.safe-examples
The CI scripts to automate the packaging/release process of the browser with mock/non-mock routing were implemented by @hunterlester and we’ll be testing them so we can use them for our next release. We now plan to automate this process for the example applications.
Some of the tasks we started this week are related to making sure all our applications work as expected also on 32-bit platforms. The safe_client_libs already supports them and we just need to work on some Node.js dependencies that seem to be causing problems in such platforms. In addition to this, we will be working on some minor internal refactoring in the safe_app_nodejs code, along with the addition of some new binding functions that are already exposed by the safe_client_libs, e.g. to get the app’s own container name.
The pull request for desktop support for the Csharp APIs has been merged. The API scope is also being enhanced in parallel. We will have to update the mobile Authenticator and also the messaging app with the new Csharp API to test end-to-end before we publish the NuGet package. The JNI bindings are being tested and integrated. There are few points like mock support in the JNI bindings which are being looked into. We will soon be starting to integrate the bindings for the Java and Android APIs. @joy has been away this week for personal reasons and once he resumes work we expect progress there to continue.
SAFE Client Libs
This week we worked on, finished, and merged an integration test which logs into the real Alpha 2 network and performs data operations. Writing this test has already paid off as it allowed us to find and fix a revocation bug (the fix is in the same PR). What happened was that the revocation flow was interrupted after deleting an app’s entry from the access container but before removing the app from the revocation queue. This resulted in all subsequent revocation attempts trying to handle this app from the queue that couldn’t be found in the access container. Now, if an app is in the queue but not in the access container, we simply exit early without doing anything and allow the app to be removed from the queue.
Of course, the real purpose of the new integration test is to guarantee data compatibility with the network. We ran the test and verified that the master branch is data-compatible with the Alpha 2 network, allowing us to safely deprecate the alpha-2 branch. All further code changes will go into the master branch with confidence that they will not break compatibility.
Work on the C# bindings generator has wrapped up and is currently undergoing review. Once finished, this generator will help the developers of the SafeApp mobile bindings to reduce most of the low-level repetitive boilerplate, allowing them to focus on more interesting parts.
Some of the manual patches we’ve needed in our lower-level crates (namely config_file_handler and get_if_addrs) when compiling them on mobile platforms are being addressed upstream and corresponding PRs have been raised. These are currently undergoing review. We are also planning to set up an automated build system for the mobile libraries, to streamline their releases.
Java bindings are almost completed too. We have written some simple tests and confirmed that the basic functionality is working. Soon the front-end team is going to start integrating it into the mobile project targeting Android. Currently, we’re working on automating the bindings generation by including it into the SAFE Client Libs build pipeline (there’s a pull request for C# bindings and Java bindings are underway too).
Routing & Crust
Today we are putting out a forum post for our proposal of the Data Chains. We have managed to simplify the chain quite a bit. It now has only a few states for the Elders - Live, Dead and Gone as explained in the post. They follow a natural constraint that Dead or Gone must be followed by a Live. This means we will always see these events happening in pairs. This is a simple but wonderfully powerful tool for chain validation. Peers on the Network cannot delete any individual Block from the chain, if they do so the chain-validity will no longer hold and it’s easy to verify this. This aspect is particularly important because we say a peer can be given only one copy of a chain by anyone in the Network and it can implicitly trust that to truly contain the correct sequence of events without any of them missing in between, provided there is a point in the chain that the peer already trusts. For a peer that was never on the network before, this could be the genesis block. For one that was in the network before, it could be the block it had before it left the network. All these will become more apparent when you look at the forum post. We have tried to make it concise and precise.
Triple Quorum
This is one of the ideas we have for applying to Secure Message Transfer. When we get a message block which is valid by the virtue of it being signed by the Quorum of the previous section, we have to vote on this message ourselves and obtain a block and pass it along. However, if our section was undergoing a merge, then our Elder group would likely be undergoing frequent changes. This might not have been realised by the previous section while it sent out the message block to us. It might happen that some of the peers it thought were Elders are now Adults. Under these circumstances these Adults relay these blocks (or votes that they get from Elders of their own section which still think of it as an Elder) to what they consider should be the current set of Elders. The triple quorum rule means that an Elder getting such a Vote or a Block from an Adult, which it would normally ignore, will consider it valid if that Adult was an Elder in either the pre-merge own-section or the pre-merge sibling-section. This allows us to not drop the message when it’s transiting from a section undergoing a merge.
Crust has been evolving at a steady pace. uTP is almost there and we should be able to test it next week. p2p integration is done which also resulted in codebase size reduced by 7% and more unit tests. Crust is developed hand in hand with p2p which also got some attention. There was a bug on Windows systems: if we tried to recv_from() a closed UDP endpoint (Windows would detect that if previously we sent something to that address), it would raise ConnectionError. So instead, we ignore the error and keep receiving datagrams. Also, UPnP port forwarding rules were infinite, but now they expire in 5 minutes. That should manage router resources more economically. Although, if we notice connections getting dropped, that might be changed in the future. In addition, now users have finer control over port forwarding over UPnP: one already could disable UPnP use globally. But now it’s possible to enable/disable it for rendezvous connections only and that allows us to avoid needlessly overloading routers. Some routers have a maximum limit of ports forwarded by UPnP. Hence, being able to better utilise them can definitely save us some trouble in the future.
.
