2018-03-08 Mobile Blockstack ID creation / onboarding update


Meeting with: Ken, Chase, Larry, Jude

Previous discussion:


  • Full prototype of user onboarding on mobile
  • Evaluated 3 approaches outlined by Larry (killed two because they contain a failure state where user is easily locked out)
  • Met with engineering team to validate the approach is possible and avoids any big security pitfalls.

Open questions / ideas

  • Can/should we require all new IDs to have a subdomain ID?
  • Can/should we allow users to store recovery phrase someplace else (iOS keychain, save to files, dropbox, etc)?

Key next steps

  • User test prototype with 5 users who have never created a blockstack ID

Overall goal and approach

  • Allow new users to create a complete ID on mobile.
  • Minimize the time/friction/complexity.
  • Allow users to defer the password and seed record steps (get into app faster, realize value faster)

Step by step UX

  • User clicks on app
  • User clicks “Login or signup with Blockstack”
  • User creates unique ID
  • User enters email/phone
  • User sees confirmation message, for specific app asking for access to ID.
  • User sees/starts using app
  • User gets email stating “your identity isn’t backed up"
  • User opens email client and clicks on link (can be days/weeks later)
  • Browser/app opens, user is prompted to backup their account.
  • User is prompted to create/enter password. User types in password. Clicks done. Confirms. Clicks done.
  • User sees seed in plaintext and is prompted to write down seed. User records seed.
  • User is prompted to type in the seed to confirm they recorded it. User enters seed.
  • User sees a message: “You’re all secure”
  • User gets email with two URLs
    • Restore via seed
    • Restore via link + password

Prototype screens

Steep adoption path for regular users

Hey Guys,

Really digging this flow, only part i would change is ‘Login or signup w Blockstack’ is a bit awkward, what about ‘Continue with Blockstack’ ?

Also, will this flow work on mobile web as well?



Thanks Adam. Yeah, mobile web + native is the intention. @larry @yukan feel free to chime in.

Steep adoption path for regular users

@jeffd loving this!

Just thinking,… can we make this a mobile responsive application so that we can share the code with our web onboarding flow?


@ryan raised a couple of “failure” conditions we may want to think about when it comes to losing the private key:

  1. Private-browsing mode (I think when you use a webkit widget from an application, this isn’t an issue, but we should look into it)
  2. Cookie resets – users may not actually be aware that a cookie wipe on their device will discard that private key
  3. Loss of device – not sure that’s solvable.

I think (2) is kind of important to think about, and (1) is also important for users who hit this via their web browser rather than mobile native.


Oh hell yeah, very well done. Loving this flow. See my comments below.

This is an interesting question and I believe the answer is yes and yes.

There are a few questions here so I’ll answer them separately:

Q: Can we have the user download a file or save a file to Dropbox?

A: On iOS the file could be saved to a note in the Notes app. I think the file needs to be encrypted, but I’m not sure, we’ll have to investigate this. I do know that the Notes app can password protect note files. On desktop, the file can be downloaded as long as it is encrypted with a strength-tested password. This same encrypted file could also be emailed to the user.

Q: Can the phrase be saved to the iOS keychain?

A: Yes I believe this can be done on iOS and locked with Face ID or a fingerprint or your pin. This could also be done on your Mac.

Both of these should be very promising.

We had earlier discussions where we favored “sign in” and “register/join” as a pair vs. “log in” and “sign up”, inspired by the following UX posting: https://ux.stackexchange.com/questions/1080/using-sign-in-vs-using-log-in. Also you’re literally signing a message to enter the app so there’s some interesting meaning behind it. That said you may have a good reason for going with this pair so curious what you think.

Interesting. Maybe a single verb like “continue” or “enter” could work. Found this one for Facebook that one website used:


Main questions I have are the following:

#1 Should we also have users enter a password on the initial sign up so that we can send them an encrypted copy of their passphrase? Or is it acceptable for us to only have the key stored in local storage initially and then do the backup process later? This ties into the concerns that @aaron just posted.

#2 For the backup process, can we include something other than writing down the 12-word phrase and storing a file in the keychain?

One option is to use a social recovery option where you enter the email addresses of 2-3 of your friends and we send them a piece of your key that can be recombined with a piece we send to your email.

#3 How do we communicate to the user that the phrase needs to be written down on paper and cannot be screenshotted or included in a file on the device?

Here’s some interesting copy inspiration from login.gov:

#4 How do we internationalize the 12-word phrase process?

Can we use different languages for the word sets like some apps do? Or should we have people write down a numeric or alphanumeric phrase if their language isn’t english?

Here’s a list of word lists in different languages:

Also here’s some inspiration from 1password and how they do secret keys and emergency kits:


Thx @aaron these came up in earlier discussions and seem kind of endemic to the process itself, if there are true solutions to those would love to hear more:

  1. There are ways to detect when someone is private-browsing/incognito correct? I’m guessing we should not allow or maybe discourage this since it’s likely to lead to a account the user can’t recover.

  2. There’s nothing we can do to stop this, so all we can do is encourage them to have their seed recorded or send it to them in a variety of ways. Anything else to consider here?

  3. Kind of the same as #2.


That approach seems safer, but might be worse actually, since forgetting ones password means you’re completely locked out. We know that happens millions of times every day. My first reaction is to say lets user test, but doubt we can get a realistic read on that scenario. Best might be to present a couple scenarios to users and see what reactions come up.


My point in #2 is that a user won’t necessarily be aware that resetting their browser history will have this result— this isn’t how most user account sign up processes work, so the user wouldn’t have a reasonable expectation that they could lose their account this way. I agree that there isn’t necessarily anything we can do to stop this, but I think we should try to make users aware of the potential problem.



  1. Can we start thinking about this as the onboarding flow for browser.blockstack.org for both web and mobile? Am I missing anything here that would prevent this @larry or @yukan?
  2. Based on the current flow, it’s not clear to me why the app needs Blockstack to work and why I should create a Blockstack account. There are some good suggestions in @digitalwaveride’s wireframes
  3. Maybe capturing the user email address + password would be a better first step since its more familiar. We could then also leverage the user’s email handle to prepopulate the identity field. For instance, if my email is cwackerfuss@gmail.com, my identity autofills to cwackerfuss


Allowing users to start using, or test out, an app before an ID is created has some obvious advantages. But I also assume that for many apps that will be a non-starter. No ID also means no storage and so apps like Stealthy are not usable (you can only chat with yourself) in a non-ID state. Do I have that correct?


100% agree – we need to capture the ID, I was suggesting we move ID creation to the step after email and password. I think the flow might be a bit better since A) users already feel comfortable with email/password registration, and B) we could then also leverage the user’s email handle to prepopulate the identity field and check if its available.


Technically there would be an ID, with a default storage … it’s just that it is “sold” as temporary thing with a weird hash as username, and it is not perfectly secure yet, cause the user has not verified the keychain etc.

You raised a good point for direct communication apps like Stealthy, which are a special case for sure.
They have to define their explore and growth loops in a different way then probably most of the apps . Meaning they very likely have to grow via direct invitation from one user to friends and snowballing from there.
Though they have the huge advantage that if a friend sends me a direct invitation and sells me on the advantages of a secure and decentralized communication channel, then I have a huge incentive and maybe even group pressure to sign up. Apps like these might convert fine, even with a personal ID creation process in the beginning.

One spontaneous thought for a case like Stealthy … not sure if it might work…
If I get invited by you to Stealthy, then I can finish a temporary signup process in 4 steps, and afterwards can chat immediately with you… all works fine… but the moment I want to contact others, invite other friends, import my contact book whatever, then I have to complete the personal ID.
Just a thought…