This is probably the best local UX given iOS limitations, still horrible (not your fault), but I’m open to adding it in Nostur
nostr:npub1wmr34t36fy03m8hvgl96zl3znndyzyaqhwmwdtshwmtkg03fetaqhjg240 nostr:npub16zsllwrkrwt5emz2805vhjewj6nsjrw0ge0latyrn2jv5gxf5k0q5l92l7 nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s nostr:npub1n0sturny6w9zn2wwexju3m6asu7zh7jnv2jt2kx6tlmfhs7thq0qnflahe nostr:npub1k6tqlj78cpznd0yc74wy3k0elmj4nql87a3uzfz98tmj3tuzxywsf0dhk6 nostr:npub16c0nh3dnadzqpm76uctf5hqhe2lny344zsmpm6feee9p5rdxaa9q586nvr nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft ^ 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).
Discussion
It’s really not though. A good UX would be to oauth to a server that does signing or which provides an expiring sharded key which works for the session.
Users don’t want to approve actions for nostr keys the way they handle wallet signatures because it’s a thousands of times a day thing and not a dozen times a week thing
I agree, I meant there is no better way without getting a server involved because iOS…
I agree. How does NIP-46 remote signing rank with what you described?
I’ve got a draft of a post asking questions about nip-46. When i provide an app the bunker url they’re able to then sign content on my behalf with the bunker without my ability to revoke access. I don’t see where bunker’s provide an audit log of which apps are using the bunker, lettting me see what they’ve done and revoke them. I can do this when i use oauth to authorize apps on github or twitter.
There doesn’t appear to be a round trip process for authorizing requests. I think nsec.app does but as far as i can tell the new nstart.njump.me stuff just kind of has you jump through all of these hoops with random nsecrypto strings which aren’t explained, FROST servers, etc… only to give you a bunker url to copy around, which provides no more security for a normal user than asking them to share their nsec…..
I just don’t get it. What’s the point of all this security and layers of confusion. I mean to a user, what’s the difference between pasting around an nsec string and bunker:// string? Both provide irrevocable permanent access to everything you’ve got on nostr and to do anything on your behalf.
With your thing nostr:npub1yaul8k059377u9lsu67de7y637w4jtgeuwcmh5n7788l6xnlnrgs3tvjmf it kind of goes the other way, make the user jump through a whole series of 2fa auth steps for each and every action they want to do on Nostr. Are either of these better than an auth server provided by google/microsoft/okta/apple where you oauth in to apps?
If you ask users too many security questions, they just hit the ok button until the popups go away. If you make a system that has unrevokable access then that’s in every way worse than a custodial auth system. I don’t see how the bunker system is better than a server that holds nostr keys, lets the client apps login via normal web login using oauth, and then lets the user see what apps are authorized so they can track which actions were done by what app and remove the authorization token.
That’s not my understanding of how NIP-46 remote signing works. Revocation is supported. All that needs to happen is for the user to tell the bunker to revoke access to the client-pubkey.
Bunkers can and do keep an audit log. It’s not mentioned in the spec but there’s no reason why it can’t.
The bunker can also refuse to respond to requests from the client depending on the user’s permission settings.
Passing nsecs around and passing connection strings around are not equivalent. Connection strings are single use as the secret is single use.
I think remote-signers do effectively solve security concerns around misuse of user-keypairs as long as the user trusts the remote-signer. My criticism of them is the required server round trips leading to increased latency, and increased difficulty in onboarding and UX. nsec.app and Amber seem to work decently under the circumstances, though.
I will look into adding NIP-46 integration into my signer, but I’ll have to be creative because iOS makes it difficult due to sandboxing, limiting seamless cross-app communication.
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.
Is there a doc to read more about FROST on Nostr?