Today, we are releasing the first version of the comments plugin mentioned in last week’s update.
This JavaScript plugin can be integrated into any safe:// web page by following the instructions here. We’ve also set up an example at safe://safe-examples (on Alpha 2) for community members who want to try a hosted version of the comments plugin. To host your own version of this example, you can download example-blog.zip from here and upload it to the SAFE Network (Alpha 2) using the Web Hosting Manager application.
Apart from the JavaScript and C# libraries, the Java library should hopefully soon come into play as a language that we will be supporting. That’s what the back-end team are focussed on and the front-end team should be collaborating with them as well to support the safe_app API side of things.
Recruitment
In addition to last week’s new team member, @rachit, who will be working on Krishna’s team from India, we would also like to welcome @povilasb to the team! Povilas will be working with us from Lithuania. We also have Sarah Pentland joining us next Monday, she will work from our office here in Ayr and will be focused on driving more awareness of the SAFE Network and of the company in her role as Digital Marketer.
SAFE Authenticator & API
Web application handles are no longer freed automatically when switching pages/hash locations on a service.publicid. This means single page app developers will no longer have to reauthenticate whenever they manipulate the URL via pushState (the browser does still free handles if you change service or public id).
The SAFE Browser devtools have been improved for web development. Which set to use was less than clear and causing some confusion for the community. There’s now a much more obvious distinction between devtools for web pages and for the browser as a whole.
We’ve started the process of integrating spectron for the browser to automate basic checks and run plugin integration tests. This should improve the reliability of our builds as well as removing the need for as much manual testing.
The refactoring of the email app source code that @hunterlester has been working on is finished and has been merged into the master branch of safe_examples. This refactoring was meant to make the code easier to read by the use of async/await instead Promises, so we expect this will help developers in understanding the email app internal functioning. In addition to this, the refactoring also includes some reorganisation of the Redux reducers to abstract all the initialisation steps from the ones that are specific to the email application. These steps manage the app state and facilitate simple authentication of an app, as well as providing actions for connecting/reconnecting. The intention is to move towards the creation of a common pattern that can then be re-used by any other app, and @shankar is now working on applying the same on the Web Hosting Manager app to demonstrate that such a pattern can effectively be applied in different apps, along with several other enhancements in the code itself.
We have also started on some minor refactoring in safe_app_nodejs, which includes providing greater consistency in the way we import modules and hiding private symbols from the classes. We are also trying to expose some constants that will be useful for the apps in some scenarios. As an example, currently when setting/associating permissions in a MutableData for any user/app rather than for a specific sign key, a null value has to be passed as the signKey parameter. We will be exposing CONSTANTS.USER_ANYONE constant that can be used for this case instead.
@joshuef continued investigating different browser options last week. Brave, Firefox and Chrome all use a similar extension format, which throws up a few problems when you add a custom protocol. That said there were some positive results and a few potential paths forwards that we’ll be considering before making a decision here.
As mentioned in the previous dev update, we solved issues in all supported platforms related to the registration of the system URI scheme when the browser is launched in dev mode, i.e. when launched with yarn start. This implied changes not only in the browser but also in the plugins and some minor changes in safe_app_nodejs. @hunterlester is now working on fixing the same type of issues on our example applications so they can successfully receive authorisation responses from the Authenticator when launched in dev mode.
SAFE Client Libs
Continuing our efforts from the last week, we have finished our discussion about language bindings and we’re starting to get to the implementation part. Our top priority is Java & Android bindings, but we are aiming for C# and Xamarin too. We have considered several options to automate and simplify bindings generation, and we concluded that SWIG does not fulfill our requirements because our foremost goal is to provide language bindings for mobile platforms, which are not supported by SWIG in a way that we need. In addition to that, SWIG does not fully automate bindings generation either: we still need to provide and generate interface files and JNI bindings for it. Another disadvantage that we have discovered is that the end result doesn’t feel as idiomatic Java or C#.
The option that we decided to go for instead is the combined approach of manual coding and automatic generation. We already have language bindings for JavaScript (in safe_app_nodejs) and C# (safe_app_csharp), so what we want to do is to generate function declarations from our Rust code base by deriving the information about function arguments and return types from the abstract syntax tree, which we can get by reusing some of the components from the Rust compiler itself (namely, the syntex crate). We already have some proof-of-concepts for both JNI (Java) and C# in this repository. We intend to produce a simple bindings generator tailored to our specific needs based on these PoCs. We also want to document it well for interested community members to reuse it and add support for new languages, such as Python or Ruby.
Routing & Crust
With Section Graphs having matured to some extent, we are now also looking at a solution without branching. Section Graphs allow for section states undergoing multiple changes simultaneously, which creates branches in the graph. We employ methods that attempt to accelerate the section converging on a single state as fast as possible, but this is not deterministic - it will, however, happen eventually. But what if we don’t consider branching and see the chain as linear? We think trying this approach should help simplify the code to an extent. If there are branches, then we would simply apply rules to re-arrange the blocks so that they become linear. To see what this buys us or if it has problems right away, we are now modifying the Ewok code in a way that will allow us to test this idea.
Also, we are now starting to look into more serious (catastrophic) scenarios such as a mass node loss. What if the entire half of the network goes offline (undersea cable cut, some country or group of countries have gone offline, etc.)? If such a thing happens, every section out there on an average will have been reduced to half strength immediately and we need to see if we can devise a way to recover from it. We have a few promising ideas, but much work is still needed in this area.
Work has continued on the port of Crust to futures/tokio. The implementation is finished, though not fully tested. It’s currently available at GitHub - canndrew/crust-futures: Port of crust to futures/tokio though will be merged into the main Crust repository once we are satisfied that it’s stable enough to replace the old implementation. We also have a new member of the team, Povilas, who’s currently learning the ins-and-outs of Crust and whose next job will be to help us write more test cases. The next step for Crust is to port over our p2p nat-traversal library to futures/tokio so that it can be used to greatly enhance Crust’s ability to connect to peers who are behind NAT restricted routers.
