Update 4 November 2021

The ‘Safe’ in Safe Network stands for secure access for everyone, of course, but a Safe is also a strongbox where you can lock up your valuables. Put the two together and we can picture a network of Safes swimming in a sea of perpetually available information. It’s a nice picture.

No-one can lock anyone out of the public network—there’s secure access for everyone after all—but neither can anyone hoover up our personal data, our secrets and our stash of tokens when they’re tucked away in our Safe, protected by our painstakingly-memorised password and passphrase.

But hang on a second… what if we suffer a bump on the head? What if our paper backup copies are destroyed by fire or flood? What if we get old (it happens) and … just forget? Our precious stuff could be lost forever.

There has to be a better way—and thanks to the miracle of threshold cryptography there is! @JimCollinson explains more below.

Team news

We are in the last stages of appointing a finance officer (thank God) who will have a Fintech focus. This will add to the work Sharon did for us, but be a bit more detailed on launch, onboarding and token economics.

PROMOTION - @JimCollinson has accepted the position of Chief Strategy Officer. We all know Jim and we all know what he is capable of. This releases him to reach a larger audience with authority. Jim will work with others, including finance, to reach towards launch and beyond. We don’t need to tell you how good he will be at this, we already know :wink:

PROMOTION - @joshuef Has accepted the role of Chief Technology Officer. Josh as you know is as cool as cats and handles conflict, debate and team spirit in a way I have never seen before. A calming influence that is super focussed on progress. We are lucky to have him and again the focus is on launch where Josh will have a lot of interaction with the launch team. Like Jim, still on the tools and still plugging away, but with that extra authority to get things done even quicker.

Both promotions have been really welcomed by the whole team, which is super cool to see.

It’s all coming together folks :+1:

General progress

Last week we said we were tantalisingly close to removing Connection Pool from qp2p and taking it into Safe Network, and we’re happy to announce that @chris.connelly has now put this milestone firmly behind us. Sounds technical - and indeed it is technical, but in a way that simplifies things a great deal.

@yogesh is working on implementing another simplification, this one planned for some time but not rolled out yet to the testnets. When a node wants to join the network it has to do the work of aggregating the elders’ votes and then resubmitting them if it has enough.

Designing secure, resilient and usable credentials

The act of creating your own Safe is the act of creating some credentials. They are effectively one in the same. You make a set of keys that allow you, and only you, to access and use your own data; opening the door to your own conceptual secure space that starts on a single device but ends up on the Network, and spanning many.

So the first task for these credentials to be entirely unique. They won’t be stored on the Network, or on some server somewhere, like a traditional online account. So they must have enough entropy, or randomness, not to be stumbled upon, collide with someone else’s credentials, or suffer from a ‘brain wallet’ style attack.

More than that, there are another set of qualities which these credentials must imbue:

  1. They should be able to be created offline.
  2. Reliable to write down, and store on paper.
  3. Have a recovery mechanism.
  4. Can be changed, without breaking access.
  5. Should not rely on a human to create randomness.
  6. Can be used on any device. I.e. does not require me to manage separate credentials or passwords for each device I use.
  7. Can be used in a way to remotely revoke access to my Safe from a device I’ve lost trust in, without breaking access via others.
  8. Should not be stored online, on the Network, nor need to be transmitted.
  9. Should not contain any publicly identifiable or discernible information about me.

Going further, and making a system that is usable for people, means they should also have desirable features such as being:

  • Memorable
  • Multilingual
  • Ergonomic and usable on a variety of devices
  • Allow for additional factors to be used in future depending on my needs and hardware resources. E.g. allow me to use a hardware key, or biometric factors on my phone.

It’s quite a wishlist isn’t it? We could deep dive into each of these, but let’s just take a walk through a solution shall we, and I’ll explain on the way.

Safe Credentials using threshold cryptography

So can we do it? Well, here’s a proposal for how we can take a Multisig approach to credentials using BLS. Let me explain through the medium of wireframes.

Creating a Safe for the first time

Onboarding, creating a Safe for the first time, as I mentioned, involves making a set of credentials. To start I choose a password, and then I’m given a generated passphrase to take down, or print out:

This passphrase would be a BIP39 style phrase, with a checksum at the end.

So with these two elements, we have something you know, the Password, and something you have the passphrase; and in combination, we can generate a suitable amount of entropy.

This is the base, default, pair of credentials for a Safe. Both are required for access, so it’s strong and unique, but let’s make things a bit more usable shall we?

The next step, which is optional, allows me to create a device key if I trust the device I’m using. This is a third access key to my Safe which brings some handy features.

Firstly, it allows us to create a 2-of-3 key scheme (Multisig FTW), which means if I forget my password, I can still gain access using my phone and passphrase. Or perhaps I don’t want to enter be Passphrase each time I unlock my Safe; on this trusted device I can just use my Password and the device key, maybe utilising some inbuilt biometrics too, for an element of something you are.

I’m then ready to finish and open the Safe locally for the first time, using this set of three credentials, two of which are always required to unlock.

Mo’ Keys, Mo’ options

But I don’t need to stop there. I can create additional access keys, to provide more flexibility and resilience. From the options screen, I create additional Passphrases, perhaps a backup, perhaps one to store in different physical locations. And I can set up additional devices here too (including dedicated hardware keys like a YubiKey in future), or revoke access to any device or Passphrase I’ve lost trust in or no longer have access to.

From this suite of keys I have the ability to create a scheme to suit my own particular circumstances and threat model.

For example I can have 3-of-6 setup, or progress to k-of-n of my choice. Plus I can choose to always require a Password or Passphrase to unlock my Safe, denying access to anyone who happened to have access to two or more of my devices.

Unlocking on another device

So, I’ve created my Safe, but I want to open it on another device I’ve not used before. Let’s take a look at how that works.

I’m presented with an unlock screen, where I tap to enter an access key.

I’m then given a screen which allows me to scan a QR (which are on printouts of passphrases, or in the device key usage we’ll get to later) or I can simply start typing in a passphrase in the text input at the bottom.

If I start typing I go into Passphrase entry mode, in which we use things like type ahead, and suggestions from the phrase dictionary to speed the process. I can also rearrange the words in the phrase, or swipe to remove them if I make a mistake.

So here, we can make an interface that, while not super fast, can still be smooth and feel pretty easy to use when it comes to entering a long phrase.

When I get to the end of the phrase and enter the checksum correctly, I can proceed.

Note here that only after I have successfully entered that first key (either a passphrase, or a device key) am I prompted to enter a Password.
Here we see the Password being successfully entered and the Safe is unlocked.

After successfully unlocking, I’m prompted to create a device key on this phone, should I trust it. This would allow me to unlock without the need to enter the Passphrase each time, or get in if I forget my password.

And on that note…

Unlocking without a Password

…what do I do if I forget my Password? It’s a common occurrence, and overall one of the most significant threats to the security of our data on a decentralised Network. After all, there is no central authority to appeal to, no server to send a password reset request to, no list of usernames with password hashes. It’s down to me, and the tools at my disposal.

Thankfully, we can use those Multisig chops to get back in, should I go blank on my password, as I have a tendency to do.

I’m using a new device that doesn’t have a device key stored on it, and gosh darn it, I just can’t think what that password is. So I start by entering a Passphrase:

I’m returned to the unlock screen, and I can see the Passphrase I’ve just entered. I can’t enter a password here, because I’ve forgotten it of course, so I’ll need to use my other device to get in. I tap to Enter another Access Key and I’m ready to scan a QR I’ll produce via my other device.

Using my other device, which I’ve used before and have a device key saved on, I open the unlock screen:

By tapping the Device Key listed here, or via the meatball menu top right, or perhaps even just double tapping the lock icon I can produce a Device key screen which has a QR code to scan on the new device (or if I want to, I could show it as a passphrase and enter it more manually. Or down the line we could look at other options like NFC easy, but you get the idea).

It should be noted that the Access Key (the keyshare to be more specific) represented by the QR displayed here is generated when the screen is opened. This is passed over to the new device and, used in combination with a second key, allows the Safe to be unlocked. This avoids exposing/passing around the device key itself, rather it’s a process of creating a key specifically for the destination device, via an existing one.

So I scan the QR on the new device…

…and I’m in. At this point I can add a device key on the new device, and of course go and reset my Password too.

And depending on my particular key setup, I could even regain access to my account using only a set of devices, should I need to.

So how does this proposal stack up?

What do you think? Will this fit the bill? A Multisig approach that gives us a system of credentials that:

:white_check_mark: Can be created offline
:white_check_mark: Are ergonomic
:white_check_mark: Allow for memorability
:white_check_mark: Are human readable and pronounceable, enabling them to be written down and reliably entered
:white_check_mark: Are resilient to credential loss
:white_check_mark: Can be changed without breaking access
:white_check_mark: They don’t rely solely on humans for entropy
:white_check_mark: Can be used across a multitude of devices
:white_check_mark: Can be accessible in multiple languages, and readily expandable
:white_check_mark: Allow me to revoke access to devices I’ve lost trust in
:white_check_mark: Need not be stored on the Network, online, nor transmitted
:white_check_mark: And require no publicly identifiable or discernible information.

Is that a clean sweep?

There will be kinks to work out, undoubtedly, such as recognising and handling password typos, and syncing credential changes across multiple devices that are moving between on and offline. But we have the basis here for a strong system that should be a win for usability and security overall.

Dig in to all the detail

If you’d like to take a closer look at the wireframe user flows for this proposal, you can jump right in to the fully documented Figma file below. There’s a fair bit more nuance to it than we can cram into a dev update, so feel free to have a poke about, and as always, we welcome your feedback and comments.

Useful Links

Feel free to reply below with links to translations of this dev update and moderators will add them here:

:russia: Russian ; :germany: German ; :spain: Spanish ; :france: French; :bulgaria: Bulgarian

As an open source project, we’re always looking for feedback, comments and community contributions - so don’t be shy, join in and let’s create the Safe Network together!


First for the second time!


Second!!! Almost first! Damn, just few seconds

Congrats @JimCollinson and @joshuef for the promotion!


Ahhhh almost made it at least I’m up from number 4 last week!!


Looks like an awesomely flexible and humane login UX. Really digging it. And so glad to see the network connection fix merged in. Another great week of work from the team.


Firstly, congrats on the promotions and on the upcoming hire! Secondly, the wireframes are gorgeous and what a great solution.


That’s a great update… nice to see such a strong team evolving with those promotions.

The unlock detail is interesting … two bits I didn’t catch… once you’re logged in, I guess there’s a simple lock/unlock toggle and an accepted risk or some management of what is preferred… logout or a soft lock that allows a quick re-entry.

Since so much of that was with mobile, surprised there seemed no talk of thumbprint as most mobiles come with that and while that becomes a limited set on the phone, perhaps is relatively useful.

So, that was for human agents but what of bots and others?.. Passphrases are just a simple presentation of what is beneath… is that beneath a single string or a couple necessarily?.. and expecting there will be a method to use that… perhaps instead of multiple words. Also, perhaps users will want to copy/paste where they understand the risk for that on a device that’s not a mobile.



In BIP-39 the terminology used is mnemonic, not passphrase. Maybe stick to the standard terminology? I always find the password / passphrase distinction confusing anyway since they sound so similar.


Thanks so much to the entire Maidsafe team for all of your hard work! You are making great progress.
Congratulations to @JimCollinson and @joshuef for your well deserved promotions! :racehorse:


Congratulations @JimCollinson and @joshuef, no need to say that, but super deserved!
Great to see the triumvirate is back!
Or is it a quadrumvirate now with a CSO… :wink:


Congrats @JimCollinson and @joshuef, well earned and deserved :clap:

Jim, this is a very nice and well thought out UX as usual, thank you to all who worked on this. You anticipated things I was thinking as I read (such as not requiring or relying on the device unlock, which I think is inherently flawed).

I’m wondering now about attacks, such as when someone has your device, maybe they can brute force the password which means you still have to provide a very secure password whenever you unlock your Safe which I’d expect will be very frequent. Also, once unlocked, I guess we’ll want the unlock to expire etc. It’s a big topic so maybe the above can be posted to a new topic to collect comment and questions?

Also I made a twitter thread from the credentials features if anyone wishes to retweet or like:


Great news on the appointment of a CFO and the promotions for @JimCollinson and @joshuef
I’ll go over the full details of the login security in Figma later but it all looks elegant flexible and secure, just what we have come to expect from @JimCollinson. Thank you

These promotions and appointment will hopefully spread the load and appease some of the more hysterical doubters.

An excellent update, thank you to all involved.


Would I be able to require a password for any login? As in, ensure that if I forget my password that no-one, not even me, could ever access the account again?

Also, would it be possible to give different devices different permissions? For example, having a camera that can write but not read or delete, a shared login that can read but not write or delete, and a private login that can delete?


I just saw this posted on a group for fans of Far Side type humour and thought of the project…



Thx 4 the update Maidsafe devs

Congrats to @JimCollinson and @joshuef, well deserved.

Creating a Safe looks great, feels familiar, to the current crypto auth solutions. Luckily in our case there are mo options :stuck_out_tongue_winking_eye:

Keep hacking super ants


Many thanks all, to say it is an honour to be the CSO is an understatement!

Yeah, these wireframe are really just to help demonstrate the core credentials scheme, there’s a lot more nuance in there, and many more of the subtitles you describe (such as a soft lock, perhaps behind a device/os level biometric or PIN code) can be accommodated at the client level, and depending on what the device has available.

Yeah, so this is focusing on the human element, which is in many ways the trickiest. But essentially what we have underlying it is a tree of KeySets producing KeyShares, which are represented by a Phrase. So there is still the raw value under that, such as what would be used as the device key… you could just use that if you wanted. A bear for humans to read and type, but bread and butter for a hardware device.

Yeah again, we’re not going into every minutiae of the interface here, and it certainly could be possible to copy and paste a phrase. Whether or not that is a secure thing to do, though, would depend on your individual circumstances.

Well it depends; if you are concerned about that, then you would haver the flexibility to set up a 3-of-N scheme, and have a mother device handy. But it would also be trivially easy for us to program the app to just nuke the device key after say 10 failed attempts; in which case you be then looking at brute forcing a maybe >160-bit key. By which time you presumably have changed the keys elsewhere.

Plus lets not forget that we can also use hardware security features for additional layers of both security, and convenience.

Yeah, again like the above, plenty of subtitles here. Happy to chip in on a evaporate topic!

Well, there is plenty of flexibility in the system for you to do something like that; and in fact the default 2-of-2 would have that result. Whether or not that is advisable/desirable is up to you really. We are largely trying to build a system that is resilient in the face of individual credential loss, because it is quite common, and also can be quite costly.

There isn’t really a standard terminiology I’m afraid, it’s all over the place. Mnemonic is used interchangeably with phrase, and seed phrase. I might even argue that BIP39 is using passphrase incorrectly (it’s really a pass_word_ in that case) :grinning:.

It’s gonna come down to what is intelligible and clear for most users, which thankfully is pretty easy to test. And on top of that we’ve got UI devices to help us out—so it should be far less of an issue that it appears.


Congratulations @JimCollinson and @joshuef to join MaidSafe.

Great progrese with setup account it looks really well. Anyway how can I trust to Smartphone :crazy_face:


Congratulations on the promotions @JimCollinson, @joshuef :clap:t2::clap:t2::clap:t2:


How about adding the date and time of account creation as a default third access key or is that too easy to brute force?

I’m doubting that ‘normal’ people are actually going to be remembering a list of words and think that they’ll just plaster their QR codes all over the place or only have a screenshot of it on the phone they will inevitably lose.