-
@ hodlbod
2023-12-21 20:35:02
We're currently having a conversation about the api for signers supporting NIP 44. Currently it looks like we're going to provide a `getConversationKey` method, which clients can use to generate and store keys used to decrypt DM history.
The justification is performance — it's expensive to re-calculate the keys on every call to encrypt or decrypt. It's also expensive to make lots of network calls as in the case of NIP 46. Both of these are easily solved though — the signer can cache keys just as easily as the client, and the network latency issue could be solved by adding `encrypt_bulk` type calls.
The downside of having a getConversationKey method is that clients can generate and store keys that are valid forever. Evil clients could do this without the user knowing, and send the keys to a server somewhere. From that point on, that person would be able to snoop on and forge messages between two participants. For me, this complete defeats the purpose of signer extensions.
Am I wrong?
https://github.com/nostr-protocol/nips/pull/940