So the UX is that when the app wants to sign something a share screen pops up, the user taps the signer and the app gets the signature?

GM Fren 🌞 have an amazing day today 🤗

The share sheet has to open, and the user needs to tap “Sign Nostr Event”. But depending on their signer preferences, they may or may not be prompted to take action on an additional screen. Here’s a screencap of a trusted signer action that doesn’t require additional action.

@rabble @Matt Lorentz @jb55 @Fabian @Pavle @miljan @PABLOF7z ^ Let me know what you think of this proof of concept UX screencap for a native iOS Nostr signer and if you’d be open to adding it in your clients once I get it production ready. I think this is the best possible UX given that the Nostr client stays in the foreground. The alternatives were: 1. Ask the user to install a shortcut (non-intuitive) + invoke the shortcut (Action Button on iPhone 15+, accessibility back tap < iPhone 15, non-intuitive) + clipboard hacks (inefficient, error prone). 2. Use nostrsigner:// deeplinks to switch to the signer (forces app switching twice).

Doing this for every action such as liking things is going to be a ux nightmare

Yes, unfortunately it has to show the sheet each time with this approach. I don’t disagree with you. Developers and security conscious people would be the target audience for this approach. I would not say that the UX is close to good enough to be the primary way of signing events. However, as Nostr scales over time, there are bound to be clients that are malicious or have bugs that lead to bad data being signed. The native signer could be a reasonable compromise for those who care.

Would be better

It would also require client rewrites to support it :( having unsigned events everywhere

I hope iOS users will be able to use this instead of rawdogging the nsec into every client.

FROST signer just doesn't have proper permission management yet. Nsec.app does, and has a log of access, and list of permissions that can be revoked.

what’s wrong with the nsec.app PWA for iOS?

Appreciate your detailed response.

Yes you interpreted nsec.app's architecture right, it depends on a server that detects unanswered requests and sends push notifications to wake up. iOS is actually broken with a PWA, the issue is that PWAs don't receive push messages on time after the last iOS update, which makes nsec.app basically unable to work in the background. Offline signer like Amber using native inter-app comms is obviously a much better approach, but it doesn't work on iOS or across devices, so if you're using desktop you'll still need something like nsec.app. Confirming every action is a UX nightmare for active daily use - people complain very hard here every time Alby popup shows up without much necessity. I think it's inevitable for iOS to come up with inter-app comms API someday, so maybe all we need is just wait a bit. It's great that you're exploring options on iOS and I bet there will be useful building blocks created as a result, so please keep doing it and sharing your learnings!

We're not using background notifications, we are PWA and are required by browser standards to show the visible notification, which we do. We're not getting _any_ notifications delivered until the PWA is manually launched, at least we didn't the last time we investigated this several months ago. Things worked before the last iOS update (web push was experimental and had to be enabled in iOS settings, but when done - it worked).

I had the issues you describe with nsec.app on iphone 12 mini but on iphone 16 it feels like it works well

You mean it's PWA and working well in the background? Does it show you push notifications?

Yes, the push notifications are how i know its working. With iphone 12 i often had to bring the app to the foreground to get the app to sign

Can you please check which exact iOS version you're running where push are working? Thanks!

Thanks, will check again!

Hm... that's interesting!