connect
connect copied to clipboard
hirosystems
Add support for authenticator choice
The new alpha release of this library does not support mobile authentication. It always leads users to install the Stacks Wallet browser extension, which is only possible for users using desktop Chrome and Firefox. This locks out a huge part of the audience, using mobile devices, or other browsers.
Here are some alternative proposals:
-
We are developing an authenticator for Android (Circles), and I believe one for iOS is also being built by the community. The library could detect that a mobile device is being used, and lead users to a native alternative. The downside is that these alternatives would be hardcoded in the library
-
The auth popup could lead users to a well-known url. Authenticators could intercept that URL to proceed to sign-in/sign-up flow, if they are installed in the users device. And that url would fallback to a website pointing users to the authenticators they could install for their device.
Maybe this was already discussed by the Hiro team, but I couldn't find a public discussion on the matter. And while this isn't solved, it puts new apps that need transaction support in the tough spot of leaving out their whole mobile audience. And from our perspective, we would be releasing Circles with support for current apps, but it wouldn't support the next release of this library.
Thanks for starting this thread! We have indeed discussed this internally at Hiro PBC and have a general desire to support non-Hiro authenticators with @stacks/connect during hand-off soon, so it's good timing to discuss this more broadly with the community.
I thinking taking a hardcoded approach to start may be the leanest way to get the ball rolling here, and once the list of available authenticators expands to more than a handful, perhaps we can come up with a more scaleable version then.
I'm mainly interested in the UX challenge here at the moment, in that we should figure out how to modify the current introductory modal (which sends users just to the Stacks Wallet) in a way that informs new users about Stacks and presents them with all viable authenticator options given their user agent.
I suspect that showing the user's options there – and having them select exactly which one they want to use explicitly – would be better than automatically routing them to a given authenticator (and therefore making that choice for them implicitly).
@markmhx at least on Android, it would should a dialog where users can pick which of the already installed authenticators do they want to use, or instead continue using the browser. Users can also pick a default to skip the dialog. So the automatic routing on Android already has that covered, I believe.
Two well-trodden paths here in the web3 world:
- Injecting a global variable via an in-app web browser. This is how the new Web Wallet works. It injects a variable called
StacksProvider. type definition here - Do something like WalletConnect, which has become the de-facto standard now on ETH. It provides a really good user experience. The best part of WC is that it works in any web browser, as well as in native apps. It even works if you want to use your mobile wallet with a web app on your desktop.
CC @yknl
I'm confused I think. The proper way to do this would be for Circles to register as a BroadcastReceiver for intents, and have the library emit the broadcast the intent, when used on Android. I believe iOS has similar functionality. This would mitigate the need for hardcoding a specific URL and provide the opportunity for other authenticators to exist. It is quite possible I lack understanding here, so happy to learn why the broadcast/intent model wouldn't work. cc @friedger
Two well-trodden paths here in the web3 world:
- Injecting a global variable via an in-app web browser. This is how the new Web Wallet works. It injects a variable called
StacksProvider. type definition here- Do something like WalletConnect, which has become the de-facto standard now on ETH. It provides a really good user experience. The best part of WC is that it works in any web browser, as well as in native apps. It even works if you want to use your mobile wallet with a web app on your desktop.
CC @yknl
The problem with WalletConnect is that it intrudes on the user authentication process and adds an additional step. I don't know enough about Ethereum auth requirements, but introducing another screen seems counterproductive. In my mind the connect library should have a standard protocol for requesting authentication, regardless of platform.
@dantrevino it could even be simpler than using broadcasts/intents. Mobile apps can just say they support opening a certain URL, and if they are installed, the user will be prompted which app do they want to open. That already gives us a way of supporting multiple authenticators, plus it just fallbacks to a normal web url.
That's what we did for Circles, we just added support for app.blockstack.org sign-in/sign-up URLs.
For mobile authentication, if the user has a native authenticator app installed, you can use a URL/protocol handler (i.e. stacks://) to open the native authenticator app. However, the problem is that if the user doesn't have a native authenticator installed, the protocol handler call would fail with page not found. You'd need to have a web-based authenticator as fallback. In iOS, as far as I know, there isn't a way to detect if a handler for a certain protocol exists. So this will result in having to present the user with a prompt, asking if they want to use/install a native authenticator or continue with a web based one.
There's a potential workaround in iOS, which is to use universal links. But this is a centralized solution and will rely on the domain set as the universal link to work properly.
Finally, we can go the route of using dapp browsers, which other ecosystems seem to have settled on.
Also, it may not be part of this particular discussion, but is there a plan to keep app.blockstack.org working, or will it be deprecated? Because for stacks apps that do not involve currency directly, asking users to install a Stacks Wallet just to be able to use them, is a big usability step back. If it was called Stacks Connect it would be a less worrisome thing to propose a user, but something named "Wallet" might scare a lot of them.
I just created an issue here to track the sunsetting of app.blockstack.org separately: https://github.com/blockstack/ux/issues/970
This was a decision that we didn't take lightly given the security vs. usability issues involved, and I certainly hear the counter argument that "users of apps that don't involve currency" don't need an extension as much. However, Hiro PBC needs to focus on one of these paths and the one that emphasizes security seems the right one to choose ultimately.
That said, there's nothing stopping other companies or developers from hosting their own authenticators as they please and providing them as a choice per whatever scheme we come up with as part of this particular issue.
There's a potential workaround in iOS, which is to use universal links. But this is a centralized solution and will rely on the domain set as the universal link to work properly.
Universal links (ios), deep links (android), links (web) works well, let's say there is "auth.stacks.co". I'd like this as the best solution. When there is a decentralized protocol other than http that is supported by all platform the auth protocol could be adapted.
What would be the user experience for users that have the extension installed? There was a discussion to check for window.StacksProvider if that is not defined then fall back to a url. auth.stacks.co. Is that still valid?
How does everyone feel about scheduling a meeting over Discord #dev-hangout for us to discuss the various approaches we could take here?
Vote with 👍 on my comment if you like the idea, 👎 if you hate it 😄
Hi all, I'm looking forward to our meeting later today about this issue at 12pm EDT on the Discord hangout channel! 🚀
I've created a Paper document here with a proposed agenda to make the most of our time. Please take a look beforehand if you have the chance.
We can take notes in that document during the meeting then capture them in this issue (or create others) afterwards as appropriate for tracking next steps.
@markmhx I just noticed that @friedger is not on the invite. Not sure if he's available, but he likely had some good insight
Thanks everyone for the meeting the other day!
It was decided that the next best step would be for @hstove and @jasperjansz to work together on sketching out visually just how a WebConnect-type solution might work for our various needs here.
I'm assigning this issue to them so they can take on that task and share their results. Then we can either discuss async or schedule another meeting.
Here's the first draft of the flow: https://www.figma.com/file/ksq6tnGDWcm6icDNShdENt/Connect?node-id=11%3A2447. Would this work for you guys — or do you have another approach in mind?
Here's the first draft of the flow: https://www.figma.com/file/ksq6tnGDWcm6icDNShdENt/Connect?node-id=11%3A2447. Would this work for you guys — or do you have another approach in mind?
Thanks for putting this together, I left some comments on the Figma file.
Maybe I'm misinterpreting the purpose of this Figma flow. I was more looking for a diagram that outlines what happens behind the scenes with wallet connect.
For example:
- How information will be passed from the app to the wallet
- How does app connect remember that the user prefers mobile wallet vs browser extension
- Which protocols will be used in different scenarios, like desktop browser vs mobile browser or native apps
Just had a meeting with Mark about the stacks authenticator. I am interested in learning about the specification that will be produced by Ken and would like to attend any meetings where we discuss this in the future. If I could understand the specification well enough I would like to try to build an authenticator from scratch in a non-javascript language.
Some context that wasn't captured here earlier:
@yknl is going to help out by producing the technical diagram that he inquired about previously. Once he has that ready, we can all meet for another community hangout on Discord to review that diagram alongside the UI designs produced by @jasperjansz.
I'm hoping we can schedule this meeting by the second half of June to keep momentum going and decide next steps from there.
As @markmhx mentioned, Secret Key Labs is working on a proof-of-concept for mobile transaction signing support using wallet connect 2.0 and Xverse wallet. We'll publish the details relatively soon.
@yknl any progress?
We're working on it. Is there a specific flow or use case you are looking for?
@yknl yes. The Stack Circles Android Since intercepts app.blockstack.org to authenticate apps on Android devices. Using the latest version of the @stack/connect library, users are prompted to use the Hiro Extension, and never go through app.blockstack.org. I need to use a previous version of the library, but can't look for it since the library has no changelog and was rebranded from the old @blockstack/connect. So, basically, we need a previous version of connect compatible with the latest stacks libraries. Or a new protocol to authenticate on mobile devices.
@Filmaluco Presumably you want "a new protocol to authenticate on mobile devices." more than "a previous version of connect compatible with the latest stacks libraries", correct?
Since you want mobile Android users to authenticate with Circles, not with Blockstack Connect at app.blockstack.org.
@markmhx With no deadline to a new protocol we need an alternative for our projects, this issue was open on Feb and we still have no timeline.
@Filmaluco I think what you're looking for is a mobile web to native mobile authenticator link correct? We're working on multiple protocols that link apps from web, mobile web, native mobile to mobile and desktop wallets. Currently focused on the web to mobile wallet link using wallet connect 2.0. The proposal for a mobile web to native mobile wallet link was through app links. If you're blocked on this and would like to contribute we should chat.
this issue was open on Feb and we still have no timeline.
I agree and I'd love to see more measurable progress towards mobile support in particular.
@yknl @Filmaluco perhaps the two of you could sync up and figure out how to combine efforts towards setting such a timeline?
Given all the other work on the UserX team's plate at Hiro these days, it's not realistic that we'll be able to own this project on our end for the coming months. As such, it's imperative that ecosystem members who need this functionality step in and push this forward if we all want it available by EOY.
@markmhx at the moment we don't have time and resources to spend defining the protocol and in evangelization. It's not realistic that we'll be able to own this project either.
As of pushing this functionality forward, we wouldn't need to if the app.blockstack.org was not being deprecated or a equal alternative was presented.
This is not just a developers problem, mobile users can't properly authenticate on the latest stacks ecosystem vision, an entire group of users will be discarded with these changes, changes we have no control and are currently centralized.
we wouldn't need to if the app.blockstack.org was not being deprecated
To be clear, we won't sunset app.blockstack.org until a mobile alternative is available: https://github.com/blockstack/stacks-wallet-web/issues/970
Older versions of Connect do indeed hand off to app.blockstack.org whereas the newest version hands off to the Hiro Wallet extension. I imagine it should be relatively straightforward to submit a PR to Connect that allows the developer to pass a parameter (useLegacyAuth or the like) that sends the user to app.blockstack.org on click? Perhaps by borrowing old code from a previous version.
@markmhx that's a good idea, but for Mobile/Android developers such as our self's the best we can do is open issues... changing such complex code in a different environment is not something we are comfortable doing.