Actually, if you used hash(ECDH + your public key), both of you could calculate the outer key even without the invitation message.
Discussion
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