Blockstack Mobile Plans

Browser
#1

There’s a couple of issues we want to think about and try to tackle when thinking about how to develop a mobile story for Blockstack

  1. Sign in with blockstack from mobile
  2. A Blockstack mobile app
  3. Name registration on mobile
  4. Possibly subdomain creation for large open source teams that don’t want their users to pay for a name

I’m starting with some notes around my thinking on these issues.

  1. Sign in with blockstack from mobile requires, as a first step, redirecting a user to browser.blockstack.org on mobile sign-in attempts. This is easy enough to do, but we may want to figure out a more complex mobile sign-in story first. If we are okay with using browser.blockstack.org on mobile devices for a while, this could be done pretty quickly.
    One potential snag – if we want people to sign in from mobile native apps, then we’d need a mobile auth API that would require more planning before I’d be comfortable estimating the effort.

  2. Implementing a Blockstack mobile app is varying degrees of difficult, depending on what we call a mobile app. If browser.blockstack.org is the app, then that’s done. If it’s a native wrapper around that, it’s eminently achievable, but would still require some engineering effort (for iOS, for android, we haven’t started, but it doesn’t require that much) – realistic timeline is mid-January if we focused on that over other things

  3. Paying for a name in mobile – that will be supported as soon as pure-JS operations are merged into the browser. I have some code that does the transaction generation, UTXO funding, etc, but it isn’t integrated into the browser, and doing so is not totally trivial. This is roughly a month of effort, but the question is when we’ll be able to prioritize this.

  4. Subdomain creation – we are pretty close to something like this. Basically, if we wanted to roll out such a service ourselves, we’d need to build some additional tooling, and in doing so, would be able to provide other teams with documentation and code to get started with it themselves. There’s interest from a bunch of teams for us to build this. This is probably one sprint’s worth of effort if that’s the focus. The point here is that this is mostly about building infrastructure, rather than making any deep software changes

6 Likes
Implement blockstack js into the mobile app
#2

Ken mentioned that this could be a good starting point for mobile authentication:

https://developer.apple.com/documentation/safariservices/sfauthenticationsession

1 Like
#3

Hey @aaron,

This is great and very clear. One question for you is the approach to storage. I think this all solves Blockstack mobile authentication, but storage is a whole other hurdle. Is that out of scope and this conversation is just about getting Blockstack mobile optimized for authentication flows?

1 Like
#4

We’re in the process of addressing storage in the sprint - we’re moving to an app writes directly to gaia hub model. The code is mostly complete and it will ship soon: https://github.com/blockstack/blockstack.js/issues/311 This model works on mobile.

I think we should think through this - we need a better incremental, asynchronous on-boarding process - a way for users without blockstack to immediately use the app they’re trying to use with the option of downloading blockstack later.

Linking to a previous discussion about this: Blockstack on Mobile

2 Likes
#5

@larry @aaron I have a quick question that I need some help with. On native iOS I am opening up browser.blockstack.org. I want to get my existing account. Would I be looking for a redirect containing an auth token of some sort which I would use to query the Core API directly for the user?

#6

Below is a brief overview of our plan for Blockstack on mobile devices:

Phase 1: Software Developer Kit (SDK)

Estimated ship date: Late Q2 2018
We plan to build software developer kits for both Android and iOS that provide the functionality currently available in blockstack.js and easy-to-use, in-app sign with Blockstack integration tools. The SDK will make it easy for app developers to on-board users to Blockstack in a low friction manner without leaving their own app.

In-app authentication

Apps that integrate with the Blockstack SDK for iOS or Android will be able to open a webview in their app. This webview will load a web-based version of the Blockstack authenticator software. If the user has previously on-boarded to Blockstack on this device, they will simply have to approve or deny the app’s request for authentication. If the user has not previously on-boarded to Blockstack, they will be prompted for an email (or phone number) and password as part of the process of approving the app’s authentication request.

Once the user has approved the app authentication request, the webview closes and the app receives the signed authentication token and user day in the completion callback handler.

As part of this process, the Blockstack authenticator software will transparently generate a keychain phrase for the user encrypted with their password and store it in the device’s browser’s storage. An encrypted version of the keychain phrase will be sent to users later along with instructions on how to fully on-board to Blockstack by backing up their keychain phrase and taking full ownership of their Blockstack ID.

During this phase, user identity management will be conducted through by visiting the hosted Blockstack browser in their mobile device’s web browser or by using the keychain phrase to restore their keychain to the Blockstack browser on their desktop.

Phase 2 - Native Blockstack apps

Estimated ship date: Q3 2018
We will build native iOS and Android apps that bring the Blockstack browser functionality including profile management, wallet, storage management, etc to mobile devices. This willWe’ll have a progressive on-boarding experience where users who encounter Blockstack from a Blockstack app can move from web to native as they are sold on the value of the Blockstack ecosystem.

For more information, please see the notes from the meeting where this discussed:

We would love to hear your thoughts and feedback on this!

8 Likes
PBC-team
Improving app sign in behavior on mobile devices
Taking Blockstack Mobile: Announcing Mobile SDK Developer Previews
2018-03-08 Mobile Blockstack ID creation / onboarding update
2018-02-16 Product Meeting
#7

I am assuming the experience for the user would go something like this…

  1. User opens their favorite Blockstack app
  2. User clicks “Sign In with Blockstack”
  3. User is pulled out of their favorite app
  4. Blockstack mobile app opens on their device
  5. User is prompted to “Approve” sign in
  6. User clicks “Approve” and to sign in
  7. User is pulled out of Blockstack mobile app
  8. User’s favorite app opens and they are signed in with notification that they are securely signed in
  9. User starts using app

This seems like an ok initial process.

My questions are. Would this require the user to execute all 8 steps every time they fully close their mobile app?

This is quite imperative for app developers to be able to have their apps be native.

The documentation on SFAuthenticationSession does not explicitly say that the session ends upon the user fully closing the app but I am making the assumption upon close this session would be cancelled.

If so, I feel this is a starting point but we will definitely need to improve this experience so that the user is not constantly being required to sign in. That would surely lead to user drop off.

Such a huge plus. Really feel as though this is critical. Blockstack is the infrastructure. Let the application developers worry about on-boarding their own users.

Ok. Very cool. Now we’re getting somewhere. Love this. What exactly will that look like for the return user?

  1. User opens their favorite Blockstack app
  2. User is prompted to “Approve” sign in (Approve modal appears in Web View)
  3. User clicks “Approve” and to sign in
  4. User is notified that they are securely signed in
  5. User starts using app

Beautiful!

My next question is… Would the user be required to go through all these steps every time they enter a closed app?

#8

Well thought out phases everyone. I feel this is a more than reasonable approach to kick-off mobile.

I am sure we will have more questions around session time and encryption. cc @itsProf

#9

The process looks like:

  1. User opens their favorite Blockstack app
  2. User clicks “Sign In with Blockstack”
  3. A web view will slide up and open the web-based version of Blockstack authenticator software
  4. User either goes through a short on-boarding to create their Blockstack ID or click “Approve” if they already have an ID.
  5. User starts using the app

The app is responsible for storing the user session, so no they would not be required to go through all the steps when they re-open an app.

2 Likes
#10

Great stuff! @yukan!. Very excited to see this all planned out. Makes a world of difference. :slight_smile:

1 Like
#11

I have nothing constructive to add to this except for how excited I am for mobile support. It’s one of the first two questions I get almost every time I talk to someone about the app. Thanks for doing this work in the open all!

6 Likes
#12

So excited for this.

1 Like
#13

Hey team, sorry if I missed this somewhere, but we may have the opportunity to work with a large android developer event series and I’m wondering when we realistically think the mobile SDK would be ready for action like that? 1000+ attendees at multiple events, potentially.

2 Likes
#14

I still think end of Q2 2018 is a safe goal. We might get it shipped before that.

Here’s a video of the current status on Android:

Current limitations are:

  • You have to on-board yourself in chrome before signing on (@jeffd is working on a new on-boarding flow for this we’ll need to implement in the browser)
  • You’re limited to reading and writing single player encrypted text files on Android. I need to expose functionality for binary files (photos, etc) and the other configuration settings we have on the javascript API.

I’d say on Android we need to spend a week or two implementing additional storage functionality. The on-boarding changes for mobile aren’t Android should automatically work on both Android and iOS ready.

In terms of “when it would be ready”, if expectations are properly managed, I think it would be great to get Android devs using the SDK before the mobile on-board flow is complete. We’d just need to make sure they understand that the current on-boarding experience isn’t what they’re users will experience and that they on-board themselves in Chrome on their device first. If we can manage those expectations, I’d be comfortable with going forward after this coming two week sprint.

4 Likes
#15

In the meeting notes, it is mentioned to do as much cross-platform as possible for the SDKs. Does it make sense to use Kotlin’s cross platform features for both SDKs?

Furthermore, doesn’t it makes more sense e.g. for Android to support DocumentProviders intents (https://developer.android.com/guide/topics/providers/create-document-provider.html) or accounts (https://developer.android.com/training/id-auth/custom_auth.html). Is this part of Phase 2 and the Authenticator anyway?

If the SDK provides APIs for file storage as they are in blockstack.js right now and later the document provider becomes available developers might get frustrated. At least it should be made clear that the blockstack.js API is only temporary.