hzrd149 @hzrd149 - 6d
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
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 😞
Once I finish NIP-17 support I think I'm going to start looking into nostr:npub1g53mukxnjkcmr94fhryzkqutdz2ukq4ks0gvy5af25rgmwsl4ngq43drvk double ratchet NIP. It requires the client to keep state, but If I remember correctly it requires a lot less decryption requests from the users pubkey since it uses rotating random keys https://github.com/nostr-protocol/nips/pull/1813 nostr:nevent1qvzqqqqqqypzqfngzhsvjggdlgeycm96x4emzjlwf8dyyzdfg4hefp89zpkdgz99qyf8wumn8ghj7mn0wd68yat99e3k7mf0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qpqh76z8vrufl3f2x6r3w2tgzm53uvmguugg8s03v8e2d26z7f7ta7sfvcnpm
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 :)
