There is also no post compromise security
I need the left side of the curve description of how this actually works. I don’t really understand how this hides metadata from what nostr:npub12262qa4uhw7u8gdwlgmntqtv7aye8vdcmvszkqwgs0zchel6mz7s6cgrkj has written.
Looks like you’d have to publish prekeys for every conceivable person you might want to talk with?
Discussion
Establish a new channel. Done.
fyi, your protocol lacks post-compromise security as the ratchet state is advanced deterministically. the post-compromise security comes from extra data being mixed into the state when advancing the ratchet that may not be observed by an attacker post-compromise.
The new data being mixed in is a new ephemeral key that is generated as the root ratchet is turned, which in turn derives the chain keys. That new key would only be visible/accessible to an attacker if the users device was completely compromised to an attacker. At which point nothing is going to be useful.
Post-compromise security refers to recovery from a total leakage of internal state.
The DH ratchet uses continuous key exchanges to update itself in a non deterministic way.
In your case, this is not actually a DH ratchet, but a symmetric ratchet without any data mixed in (the root) being used to feed the sender and receiver ratchets. This makes the system state determinstic and gets rid of post-compromise guarantees, and has equivalent security guarantees as using a single ratchet for send and one for receive.
I also do not see how the “active participant changing” would be defined in contexts where there’s concurrent events being sent.