Oddbean new post about login | logout Maybe Nostr should separate decryption key from signature so that a decryption heavy client can use a remote signer without huge data usage and performance penalty nostr:note1xjpqkxsz9wjjacehcpjnzvmhkwcvvhyzuwsja022ynqyfxc8fzyshfsrph
We've considered two routes: * giving a conversation key to the client; so clients receive the private key needed to decode on a per-conversation basis * making nip-46 signers act as proxies, so that the client directly receives the decrypted payloads
Conclusions?
I understand the penalty of the initial load of all DMs, but you're probably writing them into the local cache so further operation shouldn't be costly?
Then you store plain text in the browser storage which is not secure. Decrypted content should not escape the memory.
How about generating a 'cache key', encrypting it using nip04, storing it locally, encrypting locally cached stuff with it, and then when you reload - decrypting only that key and then decrypting all the cached stuff?
This is OK. But this extra complexity may not be worth it. Currently I don't have a great use case for NIP-46 in Blowater yet. Maybe the new Relayed relay implementation has a use case for it in the admin panel frontend.
The use case is that I won't paste nsec to blowater, that I can have restricted permissions, etc. And the complexity is probably worth it in terms of performance bcs you can use native encryption instead of nip04
What do you mean by native performance?