Congrats on shipping this. One thought on
"NIP-4e, which separates encryption keys from identity keys"
The hard part is how senders know which encryption key is currently yours, especially how they can know when an old encryption key stopped being yours. Just announcing this through a 10044 doesn't do the trick, since senders can never know if they've received the latest announcement and thus can't be sure that they aren't sending their messages to a compromised encryption key.
Inkan solves this by recording key delegation and revocation declarations on-chain. The mechanism doesn't care what the key is used for, so it could be used under a 4E announcement.
I actually started experimenting with double ratchet, because Inkan makes it easy for an identity to assign (and revoke / rotate) device-bound keys.
View article →
Login to reply
Replies (1)
You’re right, this is indeed a problem. My current solution is relatively simple: when a user rotates their encryption key, they don’t immediately discard the old key. They keep it around for a period of time so they can still decrypt messages that were encrypted with the old key by senders who haven’t received the latest key announcement yet and are still encrypting messages with the old key.