Improving App Integration User Experience: Streamlined Logins

Core Blockchain
#1

The Stealthy protocol aspires to empower users to access and use their data across the dAppsphere. If you have an awesome Travelstack post, we want you to be able to use it conveniently within Graphite or vice-versa. To that end, we’ve started working with our App partners to make this a reality.

At dApp summit we discussed the challenges we’re seeing with the Blockstack team, this post is a continuation of that discussion. This topic was discussed previously for integrated web products here:

Take a look at the video linked below and observe the process on mobile today (video has been edited to remove some lengthy delays and password information):

Here are some thoughts about how we could improve this process:

  • Ideally users might achieve the web Blockstack browser login at the same time that they login to the mobile app (i.e. Stealthy in this case) or there might be some facility to allow them simplified or easier login to partner apps within an existing Blockstack mobile app.
  • When restoring a Blockstack browser session, the user is prompted to re-create a password and provide email, but I believe that information has already been provided the first time they used Blockstack on the web.

It’s worth noting though that once the user has restored a Blockstack web session within stealthy, subsequent Blockstack App logins are more convenient and just require choosing an id.

3 Likes
3rd party Blockstack App Auth
#2

I think the email should be moved to be stored (encrypted) in the profile.json. (I also think requiring it is a mistake but I digress. [email protected] works fine for me.)

It is also odd how it requires you to recover your account twice, but not three times. I guess it’s related to how the webcontext is created within the app?

I think one way to streamline logins (for iOS at least) would be to store the encrypted private/recovery key within the “keychain”; Android could use something like the AccountManager I guess, though I assume that was already disscussed when creating the mobile SDKs and I’m out of the loop on that decision.

Are you using the Blockstack iOS SDK, though?

edit: if the email is going to be stored encrypted, Blockstack, please make sure it’s aes-192 or something cross-compatible and not the triplesec whatnot you have as your encrypt function.

1 Like
#3

I think this is an interesting alternative to collections (a write-once read-many abstraction on top of Gaia meant for sharing data common to many apps). I like this approach better than collections for three reasons:

  • Gaia hubs do not need to retain any state, whereas in collections they do
  • Implementing multi sign-in is more straightforward than implementing a collections API endpoint (i.e. it can all be achieved by extending the authentication protocol in a non-breaking way)
  • We can re-use our work on associationTokens to grant one app write-permission to store data to another app, without sharing all of the apps’ private keys.

The way I think this could be achieved by having the “main” app (i.e. the one that does the redirect) request Gaia associationTokens for a list of “secondary” app origins. In this case, Graphite would be the “main” app and Stealthy would be a “secondary” app. I think this can be implemented as follows:

  • We expand the authRequest payload to include a request to sign into multiple app origins at once (i.e. a “main” origin and a list of “secondary” origins). No existing fields are modified.
  • The Browser’s sign-in modal lists all the apps that will be signed into at once, instead of just one.
    • As a PoC, all apps would be signed into at once. Down the road, the user could select which ones and for how long the “main” app will have write/list-files permissions in the other apps.
  • The Browser’s authResponse payload includes Gaia associationTokens for the other apps. This means that the “main” app gains temporary write and list-files access to the Gaia hub buckets for the users’ other app accounts. The associationTokens expire on their own.

Thoughts? cc @aaron @yukan @larry

2 Likes
#4

I think collections solve a different problem then the one posed here.

Collections would be made to solve multiple apps of the same type being used to access Contacts, Emails, Images, etc, like the folders in your user/home/~ folder. Like having ThunderBird vs Gmail access your emails, and Photoshop vs Preview vs GIMP accessing your images.

AssociationTokens (seem) to solve multiple apps trying to share data within a shared instance, like Graphite sharing information on who is allowed to view the document with Stealthy so that it can invite the right people to the chat room.

That being said, they solved that issue already, so I don’t really see the need for AssociationTokens. When would App “A” (i.e. Graphite) need permission to write/overwrite any of App “B” (i.e. Stealthy)'s data, or vice versa? Why not just use window.postMessage or something similar to communicate?

If AssociationTokens created something like a temporary bucket where they could share data while the instance is running/not expired, that would make more sense, but opening up App “B” (Stealthy)'s data for full modification to App “A” (Graphite) sounds a little odd to me, while also being a security risk.

1 Like
#5

After looking through this discussion, I think it could benefit from explicitly describing use cases.

L-UC-001:
Login on a Mobile Blockstack App (iOS/Android). The Mobile Blockstack App opens a WebView of a different Desktop Blockstack App which requires the Blockstack Browser to be restored. Both logins use the same ID, e.g. user.id.

L-UC-002:
Same as L-UC-001, but user wishes to login to Mobile Blockstack App as user.id and into the Webview of a different Desktop Blockstack App as usersOther.id.

L-UC-003:
Extending L-UC-001 to simultaneous auth of multiple Desktop Blockstack Apps.

L-UC-004:
Extending L-UC-002 to simultaneous auth of multiple Desktop Blockstack Apps with different user IDs.

L-UC-005:
Login to a Desktop Blockstack App. It features plug-in code (running within Desktop Blockstack App–non-iframe) from another Blockstack App that requires authentication to access it’s GAIA bucket. (I suspect this might require API changes for the GAIA session to be able to write to a GAIA bucket that is not within the domain of the current executing App).

L-UC-006:
Login to a Desktop Blockstack App. It features a plug-in (running beside Desktop Blockstack App in an iframe) from another Blockstack App that requires authentication.

L-UC-007:
Login to a Desktop or Mobile Blockstack App which features a plug-in from another Blockstack App which the user has not used yet.

For Stealthy these are all of interest, but L-UC-006 is lowest priority. I believe Jude’s suggestion may solve all of these issues with the exception of L-UC-005 (b/c of required API changes) and possibly L-UC-007. Jude, is my understanding correct?

L-UC-007 is interesting because Stealthy shares it’s public key in the user’s Stealthy GAIA bucket to facilitate encrypted communication. I suspect that wouldn’t be a problem if a user hasn’t signed in as the plug-in code could use the association token to pull the public key, but I also wonder if the apps property of a user profile would be updated in this case to show the user is using Stealthy?

As I mentioned in another thread, I really like the separation of encryption key pairs between Apps and think it is undesirable to expose one Apps private key to another App. However I think having an App plugin within another App that can decrypt content for it’s parent App without exposing the private key seems like the right direction to me (in the absence of an key sharing service between multiple Apps).

1 Like
#6

I believe we’re in agreement about not having an App writing ad hoc to other Apps GAIA. In some of the use case I mention above your suggestion on window.postMessage could work, but in some use cases alternate solutions are required.

There is utility in having an App be able to write to a strictly scoped portion of another Apps GAIA. I think the discussion on Inboxes might also provide some of that utility.

1 Like
#7

I agree that Inboxes may work for some of those, but I also think they shouldn’t be used as a replacement for “websockets”, so to speak. If data needs to be sent from one app to another, while the “other” isn’t active, Inboxes make sense, but if both are active I believe they need to make some sort of connection that bypasses Gaia completely, or somehow used a shared bucket/scoped folder instead.

That being said, if we were to go ahead with AssociationTokens, I do like the idea of it being a scoped folder inside of the child-app, that makes a lot more sense.

1 Like