MaidSafe Dev Update - May 4, 2017

The seventh circle of hell is filled with unfortunates forced to compile node apps on Windows for eternity.


This looks great. I would say the two biggest features I am looking for from the authenticator workflow are a headless authenticator that can be set to auto-approve all requests when built against mock (to enable ci testing), and support for multiple users when built against mock (so that we can test user-interaction and permissioning bugs).

I’m looking forward to starting to poke at the authenticator API more seriously. Hopefully it can be a relatively smooth drop-in replacement for the old safe_launcher API. I may try writing some typings for safe_app_nodejs while I do.


I agreed with you when I read your comment, but now have changed my mind, I think.

On the plus side, I like the elegance of a single password. It is like a bitcoin private key, which allows a single string to access the content.

However, as I had that thought, I realized that I do not want a bitcoin private key. I want something I can remember, but that is also secure. People who do Brain Wallets, using clever pass phrases to generate their bitcoin private key, are constantly losing their bitcoin.

I want to be able to log in from memory, with a reasonable expectation that my passphrases are not vulnerable to bots that try permutations of common phrases.

Forcing people to use two pass phrases, and perhaps forcing them to have those pass phrases have a long Levenshtein distance from each other, should help to achieve that.

I would vote to call them Password1 and Password2. That conveys that they can be alphanumeric, should be kept secret, and are both important.

Password or passphrase, neither is properly descriptive!? Tricky UX :slight_smile:


@JPL Encouraged to know it’s possible, I’m wondering why I’m not able to simple action the same Linux build…

Noting my fail here, in case useful step forward for others:

See for more info.

didn’t help with Linux Mint having an old version.

Instead, I found a good route to getting the latest version of nodejs and also then npm
curl -sL | sudo -E bash - sudo apt-get install -y nodejs
Looks good then as
$ ./node -v v6.10.3 $ ./npm -v 3.10.10 $ rustc -V rustc 1.16.0 (30cf806ef 2017-03-10)

this fails on your system: npm ERR! cd app && npm install && cd ../ && npm run build-safe-app
So, I did also the obvious
npm run burnthemall
but same result.

In both attempts I also see what I expect are less important warnings
which compound my impression that npm is not useful friendly in suggesting how to resolve WARNs.
npm WARN deprecated minimatch@2.0.10: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue npm WARN deprecated minimatch@0.2.14: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue npm WARN deprecated graceful-fs@1.2.3: graceful-fs v3.0.0 and before will fail on node releases >= v7.0. Please update to graceful-fs@^4.0.0 as soon as possible. Use 'npm ls graceful-fs' to find it in the tree.

So, I’m surprised it doesn’t just compile… I don’t expect that is just because I’ve now got node v6.10.3 :confused:
While we’ve got JPL’s version of the browser that works ok here, I wonder the examples need npm to be working to get those compiled.

Might try again later this weekend :slight_smile:

1 Like

I completely agree with you.

There has been a whole topic dedicated on the subject in the dev forum (Two passwords for login process) and a majority of people didn’t like 2 passwords and would prefer a name (call it common name, account name, pet name, friendly name …) and a password.

IMO the traditional solution (name + password) and deriving both the location and encryption/decryption keys from these 2 elements was the way to go. I argued here and here) but I failed to convince MaidSafe. Maybe you could revive this topic and be more successful than me.


We just added this tutorial to the SAFE Dev Forum:

It explains how to build the SAFE Browser with Mock-Vault and how to upload a website using the SAFE Hosting Manager app. We are also planning to add a few code examples that will help you understand how to use the SAFE Browser DOM APIs to build dynamic web applications. We are having some issues with some of the code examples, so we can only publish one of them for now. We’ll update this tutorial with more code examples once we resolve these issues. :slight_smile:


This is very very awesome, and needed :slight_smile:

Great work :rocket: :rocket: :earth_africa:


Oh yes indeed. I should have also been more explicit and mentioned salting and key stretching… but the intent behind using some sort of hashing instead of splitting is to retain the full password strength for both fields, whereas splitting means each part would be weakened.

I’m not sure of the threat model here. I’d also need to better understand the possible ways to achieve a ‘change password’ feature. I think you make a good point in general - how do users detect and respond to threats to their account security on the safe network?

I think the point I’m making is getting lost in the technical details: the current user interface doesn’t inform the user to make the right decisions and leads to busy work. I’d be fine with two fields so long as I understand why I’m putting them in. Currently I do not and I suspect my account security is put at risk as a result (because I use the same password for both fields).

To really put the dead horse flogging to maximum, my truly preferred method is to behave like a bitcoin wallet - generate strong user credentials by the computer and save them to a credentials file which can be optionally encrypted with a password by the user.

The benefits are many:

  • the difference between ‘location’ and ‘encryption’ is abstracted and hidden away to the credentials file, which can be extended without having to change their login process (eg add wallet info, multiple accounts, remember app authentications etc)
  • an attacker must have both the file and the decryption password, whereas with remembered passwords the attacker just needs a network connection and lots of guessing
  • it allows headless authentication with an unencrypted credentials file, which allows professional users to abstract their security away to the operating system or other system that suits their needs (eg hardware module).
  • it simplifies the authentication process, since users are only asked for a password, it’s clear what that password is for, and the password is optional
  • it secures the login for the massive swathe of users who don’t want or know how to use strong passwords. This is most people (even Zuckerberg used dadada for his twitter). Good defaults go a long way.

I know there’s very strong opposition in the maidsafe camp to storing files locally and I fully understand this (even agree to a large degree).

I’m not going to harp on about this any more. The safe network is extremely user friendly in almost all ways. This particular issue can be easily resolved with a fork of the launcher. In the end it’s users who will decide and the current situation isn’t really too bad. Thanks again to maidsafe for the great network.


I’m with you. But I suppose it is from being comfortable with the ways of Bitcoin. Obviously the hard part with this for Joe Mainstream is making sure they don’t lose their credentials, and keeping them secure (and maybe just adjusting to a new paradigm). IMO hardware wallets were a huge step in that regard. Going back to a the old standby of making up, remembering, and typing in a (probably fairly weak) password feels like a big step backwards in security, and arguably usability. As a next gen redesign of the web, I feel SAFE should aim for greater security than what this login method provides.
Obviously I’m not advocating that users should have to buy a hardware device to access the network, just that it should be possible, at least in the future, to access the network in this way.


100% agree with you there.


Protonmail started with two inputs but then found they could get by with one. But understandibly its a much lower bar for a centralized server based email.


Yesterday I still needed to give two ?? One to logon and one to decrypt locally ? Maybe it’s changeable or why you have one ?

On safenet I think it should be coolest to have option between passw or passw+hw solutions 2fa…


Has anyone actually managed to follow the tutorial and get the web_hosting_manager to work?

This is how I and a couple of others are struggling…
trying to follow the tutorial

But don’t get me wrong, I’m having LotsOfFun™ trying :slight_smile:

Thanks guys and gals

And possible it should be. Adoption is growing in U2F FIDO


You can open a new account and will have a choice of 1 or 2 but standard now appears to be one as the Proton crew said they found new math that allowed equivalence with one and increased convenience.

I have two on one accoount (my first) and one on a later account.

1 Like

Yes, supporting this would be great. Then the network could be accessed via existing biometric devices too! I’d prefer UAF over U2F though (login directly via the FIDO device instead of using it as 2FA)

1 Like

Biometrics are avail on android/ios clients. no clunky=ez adoption, heres hoping.

1 Like

Yeah I’m more of the mind to just call it passphrase one and passphrase two because that’s essentially what it is. The username is more your public ID and eventually you’ll able to have any number of those.

has any work been done to help sort out the bugs with connecting to vaults from home? I haven’t been able to connect for a couple iterations now ever since you started requiring port forwarding and all that. Even when I did port forward and had UPnP enabled. Lots of glitches and I have submitted bug reports. I’m just wondering if any work has been done in that direction.

1 Like