You could deterministically generate the outer key from your private key and the recipient's public key, so it will be the same every time, even if your devices are not in sync.
https://www.youtube.com/watch?v=tldTGhcVWX8
Here’s a video demo of “Incognito Direct Messages” - showing a forked version of Hamstr that can send private NIP-04 DMs where no metadata is leaked to the public (no more inbox peeking).
#[0] #[1] and myself developed this as part of the Nostr Hackathon organised by Hard Yaka, Universal Names and #[2].
The main idea was developed by Anton and #[3] (developer of Hamstr.to). The essential idea is to create new disposable identities for each conversation you create, you exchange these identities with your peer secretly, and then the entire conversation takes place away from your public identity. It’s very simple, it works, there are some weaknesses (you have to trust relays), but it’s a step in the right direction.
Discussion
Actually, if you used hash(ECDH + your public key), both of you could calculate the outer key even without the invitation message.
Or you could just use the ECDH as outer key. Less subscriptions. And if you want plausible deniability ("the other guy sent it") you could skip signing the inner message.
Yes, we considered this, but to derive keys from your private key would require direct access to your key which isn’t supported through window.nostr and would require support from signing devices. Not impossible but a little harder.
And further more, if you never send invites it’ll be harder for clients to find open conversations. You’ll have to query a bunch of keys of people you follow to find conversations. So each variant comes with its own set of compromises
Fair enough. I hope ECDH can be added to window.nostr at some point. You could still send invites, but it would also allow you to operate in stealth mode if you want.
Agreed. Would open up a lot of options. Our temporary solution is to generate a new private key that we encrypt and store in a replaceable event, which permits us to derive any keys we want. It helps on the author side, but for recipients we still can’t derive their keys, so still need some sort of invite
There’s an existing protocol called XMTP that seems to use the same kind of system of sending an invitation to generate keys secretly. It’s in the alt-coin space and appears to be completely centralised for the moment, but we can certainly borrow some ideas from them https://xmtp.org/docs/dev-concepts/invitation-and-message-encryption