MaidSafe Dev Update - October 19, 2017

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 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.


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 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.



Edit:. What luck! My first first. Will read the update now. :grinning:


Second! Gah! Zoki you got a trigger finger brother


So many new faces to @maidsafe welcome all! You’re joining a great team, project, and community!


My concern about the browser plugins is that it could open the door for deanonymizing attacks by creating a hyperlink in a safe page linked to a clearnet website that the attacker controls.

Having a dedicated Safe browser that blocks clearnet traffic should be the only default way of browsing safe sites.
And if browser plugins are created, it should block all browsing/redirecting/linking between different protocols.
Not even a warning asking for a confirmation, just block them all if the SafeNetwork plugin is on.

Also another thing that I’ve wondered is what about drive-by browser exploitation from malicious SafeSites?


It’s Friday morning in Australia again and I see the Ants have been busy. Keep it up you guys and gals.


I agree with this, a SAFE browser or Plugin should not allow anything not on a SAFE url. I also think it should show Green or similar in SAFE mode and Red in other modes. Something like that, I would hate folk to make a mistake like that after all our hard work.


Another thing that worries me is browser fingerprinting (+cookies).
If the same standard browser that’s been used for the “clearnet” was browsing a safesite honeypot, a pretty big adversary (ahem) could end up matching up identities.

Also we have to have in mind that such systems are building up identity dossiers automatically, and global internet data (not only metadata) are kept in their vaults for 15 years.

I think plugins and add-ons for everyday clearnet browsers can potentially be a PR disaster.


Is there a binary release for this? I think it’s just what I need and would like to test it :slight_smile:

Great progress - a lot of important work in this update. Welcome from me to @Rachit, @povilasb and Sarah. You are joining a great venture and community. Good luck :slight_smile:


Why maidsafe need plugins to old browsers? I thought there will be only maidsafe browser?


The point of SAFE clients will be that they leave no local data at all. Cookies etc. should not be something we need in SAFE. Session state can be held by clients if necessary. In terms of session based data (the original cookie purpose) we can and should do much better.

good point though SAFE browsers / plugins should not accept cookies etc. I am stuck in lower levels right now, but this does make sense.

I don’t worry though, after all the work we have done, we wont let stuff like that trip us up. Neither the team or this community will accept that AFAIK :wink:


Oh, I am not worried about cookies. I understand it is completely unnecessary on the SafeNetwork, especially if people are using the dedicated SafeBrowser.

But with plugins on clearnet browsers it could be a nightmare.

Also, browser fingerprinting is a real menace that is quite challenging, especially with new techniques as these:

Normal browsers have no chance of escaping from that type of fingerprinting.


Thanks again for the update!


Congratulations to the whole team, hopefully there will be little left for the next milestone.


Has this guy gone rouge or what?

1 Like

Great news about the refactoring of the examples , async was a declic for me, suddenly javascript became compatible with my brain :slight_smile: So it will be a pleasure to read the examples and … to frankenstein them even more muhahaaaa

I’m eager to read the comments plugin too ! Lots to learn here about permissions and user registration , which I really need to get a better grasp.

But, but, why does the ghost of browser plugin shows again ?? I thought this had been set last year, and had resulted in making Beaker the base for a dedicated Safe browser with NO clearnet mode ( which reappered sneakingly at some point ! )

I see big concerns revived down this road. Firefox, Chrome, Brave and the other ones are tracking machines designed to leak . Just the URL bar is a privacy nightmare !!
We talked extensively of these issues for monthes, I am surprised to see this raising again.

What will happen when user Joe types “sqfe://” in their Firefox/Chrome URL ‘smartbar’ while in ‘green’ mode ? Instantly Firefox fails to connect because ‘sqfe’ is not a supported protocol, and a web search is triggered, leading to Google and an army of trackers reselling Joe’s dissident profile, and marking him as a very probable Safe network user.

Same goes for external requests in safe sites, localstorage and other macromedia fun, not to mention I’m certian nobody actually knows what really happens under the hood in these browsers . Lets ask ourselves what really motivated creating Chrome.

To me, this move would be similar to having distilled a precious liquor 12 years old, and choosing to deliver it in colanders because people find colanders convenient. But hey we designed special little plugs to use with it, so no worries…

The only reason I can see for Maidsafe to develop these plugins, is that someone else will eventually do so at some point , possibly with a weak design or even bad intentions, so it may be better that an official version is widely available before that.

Will it need a Launcher ?


Great, detailed, update! I am looking forward to messing with the Java integration again. I want to revive my FUSE drive work again once something is available.


Warm welcome to all the new people out there!


Thanks again Maidsafe devs for all our hard work.

Welcome @povilasb & Sarah Pentland.


Didn’t Firefox open up for sandboxed tabs with the implementation of ?