Trying to add NIP-17 and NIP-59 gift wrap support to applesauce and I'm being constantly reminded of why its a bad NIP. only clients that have full access to the users nsec can realistically implement NIP-17 DMs in a performant way.
Its not a good user experience when each message requires two decryption requests and all of it has to be cached to avoid unnecessary future decryption requests
✅ EtherFi Airdrop Is Live!.
👉 https://telegra.ph/EtherFi-05-03 Claim your free $ETHFI.
Only works nicely with a single DM relay that only contains one author
trade offs
A remote key (and FROST) works well for bitcoin (e.g. bitkey) with infrequent signings only. But a remote key (nostr connect) for nostr isn't as great. I don't think the problem is with NIP-17 and NIP-59, I think it is with NIP-46. But all these NIPs could be just fine if we had a remote/FROST master key and a local signing key that has been authorized by the master key.
Agreed!
In my experience remote signing with nostr keys works well enough and doesn't seem to be the bottle neck since a signature is only needed when the user is taking an action so any delay can be handled with a loading screen.
Remote decryption is more of the issue since its slower than signing and usually requires more than a single call (user opens DM conversation). NIP-59 just makes this worse though by 2x the number of calls
I don't know what a good solution is but I don't think its key delegation or derivation since that requires either a messy permission language (NIP-26) or a extra metadata layer or changes to the relays 😞
Gift wrap works like it works because it provides certain guarantees that can't easily otherwise be provided. But yes it has this cost.
A agree that NIP-26 or similar key delegation is not easy and maybe not even a good idea in nostr. But it is a good idea in general if we started over.
I don't know, I tend to think the main reason nostr took off so quickly was because it had extremely simple cryptography compared to other systems and that it worked in a web browser
But that is probably just my bias since I wouldn't have started working on nostr if it weren't for that :)
A local signing key introduces too much bloat everywhere.
But a local key dedicated to encryption would be the ideal, I think: https://github.com/nostr-protocol/nips/pull/1647
Ok yeah, far more doable.
