nip for "encrypted private room"?
earonesty opened this issue · comments
there is already an encrypted direct message
and encrypted group can be simple:
- create private key for group
- register group as a new "user"
- invite users to the group using NIP-4 direct messages containing the room's private key
- these events should be flagged as "invitations" somehow so clients know not to render them as regular messages
- clients can then ingest the private key and register for updates
- users can post to the "private room" using NIP-4 events
- revocation is handled by creating a new room
should not need any new event types, just a flag on a NIP-4 message for the invites
or does this already exist? happy to write it up if anyone is interested
i guess i could just build it as-is (no flag for invitations)
What if instead of sharing the room's private key via NIP04, there is a Metadata event, similar to NIP27, that encodes a list of "authorized users". That list includes the room's private key encrypted with the public key of each user.
The private key of the room can then be replaced at every time a person is added or removed. It won't change the way past messages were encrypted (they will still be available to the intruder) but from now on, users can be safe with a new key.
I think we should refrain from doing this until we've managed to find a workable solution for private messages that is good enough, as NIP-04 is not good enough.
the objections to nip-04 are, frankly, fully incorrect. full-anonymity is not implied, desired or needed in nip-04. the encryption is sound. the enemy is the perfect of the good here. nip-4 is a perfectly safe way of telling the whole world you sent an encrypted message that nobody can know the contents of - except the receiver, or an attacker who steals the receivers private key. it does exactly that, and it does so correctly. also the more we use nip4, the less the objections are relevant (because more stuff is now deniable)
@vitorpamplona i like your solution, except then the room's participants are public, which might not be a good thing. i think simply rolling a new room every time people enter/leave is good enough, can post a standardized "hey the new room is over here" message with the new room id. perhaps clients should only ever obey messages about membership and ownership changes from owners. (that way we can have a distinction between members + owners).