iOS Mobile sign up flow: find alternative to pop-up to create keys

[alltheseas]

what happens

When attempting to create keys on mobile (safari, brave, firefox) default setting on mobile browsers is pop-ups blocked. Wikifreedia specifically calls this out.

suggestion

Is it possible to authenticate/sign up with new keys to highlighter/other nsecbunker instances without having to go to browser settings, and disable pop-ups (i.e. without a pop-up of a new tab)? This will reduce friction, and therefore reduce customer drop-off (hardly anyone ever goes to settings).

[alltheseas]

@fiatjaf Pablo says this is your fault.

Wen fix?

[alltheseas]

Specifically at a bitcoiner conference in a room of 50 people no one was able to figure out how to use wikifreedia on mobile in limited time

[fiatjaf]

Isn't the popup a requirement from NIP-46 provider key flow? window.nostr.js by itself doesn't open popups, it just opens the overlay/modal thing. It only opens a popup when it gets an auth_url from the NIP-46 flow. @pablof7z please help.

Calling @dtonon just in case.

[pablof7z]

No, there's a redirect exactly because of how much mobile sucks

You basically redirect with an optional redirect url and after the flow you are redirected there with the created pubkey in the query string

This is the gist I've been sharing with others

https://gist.github.com/pablof7z/20911e5caa0c61f970f45fec1172e0c1#file-nip46-redirect-ts

[dtonon]

Actually we can open the popup only on desktop, and use a tab on mobile, this should solves the problem.
Or if the mobile browsers block also this, show a button/link that the user can manually trigger.
I'm testing it.

[alltheseas]

Nice! Happy to test when ready.

My gut left curve non designer non dev feel is that not having to leave the page poses the least friction.

[pablof7z]

Actually we can open the popup only on desktop, and use a tab on mobile, this should solves the problem. Or if the mobile browsers block also this, show a button/link that the user can manually trigger. I'm testing it.

just redirect to the challenge url, that's how the twitter's of the world do in this situations -- probably a new tab is worse than a redirect since the tab can't close itself so the user needs to take action to go back to the app

[dtonon]

just redirect to the challenge url

Is the callbackUrl param supported by all providers? I cannot see it in the NIP.

[dtonon]

@alltheseas

When attempting to create keys on mobile (safari, brave, firefox)

Was the problem only on IOS or also on Android?
I cannot reproduce it on Android, for me it always opens a new tab.

[alltheseas]

I only tested iOS

[fiatjaf]

In a room of 50 people everybody had iOS.

That says something.

[dtonon]

In a room of 50 people everybody had iOS.

Same thought :)

Btw, I'm going to test this use case, but without a standardized redirectBack param I suppose we are doomed.

Note: the redirect introduces some other problems, like the fact that we lose the state of the page (eg. a draft in progress), so the app must to save it somehow.

[fiatjaf]

There is a standardized mechanism, it's just not very clear in the NIP. I'll try to implement it and fix the NIP if I succeed.

[alltheseas]

In a room of 50 people everybody had iOS.

That says something.

Even in the US this is not true. Will test Android today

[fiatjaf]

Apparently there is a different bug with https://github.com/fiatjaf/window.nostr.js account creation, we're investigating.

[nostrband]

Redirect doesn't solve the popups needed for auth-url for event signing and other methods - we can't use redirects there because we lose the js/ws context.

iOS/Safari don't notify when they block a popup, also they have stricter popup blocker. But they do allow window.open as a direct result of user actions.

The best solution seems to be to wait until auth_url arrives, and then show 'Please confirm' button - click on it should open the known auth-url. That way it's not blocked anywhere. Nostr-login works like that now.

[alltheseas]

Tested Android experience, and shared findings here #27.

Good news: Pop-ups are not blocked by default.
Expected news: design is not mobile friendly, and there are at least a couple of bugs.

[alltheseas]

The commonality is that the nsecbunker key creation flow requires pop-up/new tab on both iOS and Android. This not a positive UX on mobile. Ideally no pop-up is required 🙏

[nostrband]

The commonality is that the nsecbunker key creation flow requires pop-up/new tab on both iOS and Android. This not a positive UX on mobile. Ideally no pop-up is required 🙏

You believe redirect would work better on mobile from UX standpoint?

[dtonon]

You believe redirect would work better on mobile from UX standpoint?

As already pointed out and agreed upon, redirects break the page's state.
Centralized services could use it because they can easily manage the saving of the state inside their own structure, here we are talking about an external component that should be as plug-and-play as possible.
I think the best solution is to open a new tab and auto close it at the end, or if this automatism fails, invite the user to go back to the preview window with a button that fires a window.close().

[alltheseas]

It's hard to say without testing.

What pop-ups or new tab present is a dev introduced navigation difficulty challenge. It might be higher friction than find the car captchas 😅.

1. you are now on a new tab (if it works)
2. you may not be aware you are on a new tab
3. somehow you must figure out that you need to, and how to navigate back to the thing you were doing

[alltheseas]

As already pointed out and agreed upon, redirects break the page's state.

Can this be fixed?

I think the best solution is to open a new tab and auto close it at the end

Agree, no action on user part is best.

or if this automatism fails, invite the user to go back to the preview window with a button that fires a window.close().

This is extra friction. If there is absolutely no other way, there should be a clear, friendly user interface/overlay that says something along the lines of "successful keys creation/log in! click here to back to wikifreedia" with a gigantic arrow towards the "X" / close tab button.

[dtonon]

Can this be fixed?

The state must be managed by the underlying app, and since the app doesn't know when the redirect happens it is not an easy tasks (unless window.nostr.js implements a notification system via callback and the app uses it, equally hard).
In any case window.nostr.js is designed as an easy plug-and-play, if an application needs to develop state management, it can implement NIP-46 login by itself and solve any problems.

with a gigantic arrow towards the "X" / close tab button.

You misunderstood the matter; on the concluding page the NIP-46 provider can put a simple button that auto close the tab, revealing the original application; there is no need to refer to manually closing the tab with the X (which is not there on mobile!). Window.nostr.js is ready for this, it is sufficient for NIP-46 providers to implement this best practice.

[alltheseas]

Window.nostr.js is ready for this, it is sufficient for NIP-46 providers to implement this best practice.

Ok - so is this now a nsecbunker issue?

[dtonon]

Ok - so is this now a nsecbunker issue?

If we all agree that the one mentioned is the way forward, yes

[fiatjaf]

This is extra friction. If there is absolutely no other way, there should be a clear, friendly user interface/overlay that says something along the lines of "successful keys creation/log in! click here to back to wikifreedia" with a gigantic arrow towards the "X" / close tab button.

Doesn't the popup just close itself and you're automatically redirected back to the previous app page?