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
Discussion
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
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?