Yes, or if you trust your relay operator not to leak, nip42 auth with infinite keys, prevents all this in one fell swoop. It's as private as big tech.. where the OPerator Is the trusted party. At some point, gotta trust someone. And I'm not saying it's me, it could be you. It's the community leader.
Discussion
yes, there is two patterns of group messaging
one: you encrypt and send to a trusted central server (this is the IRC method) and they then encrypt it (usually via TLS) and send it to all the other clients - the encryption is just the connection, the raw data is all in the possession of the server operator
two: you encrypt each message you send to the group individually to each counterpart in the group... the cost in bandwidth expands linearly with the number of users, you also gain the ability to exclude group members from seeing your messages, and the others can't prove the authenticity of your messages to others without giving away their nsec
three: the MLS model, where the group uses a merkle tree style derivation scheme to generate a per-message key for each message that a central moderator can stop access of one user to it because they are the merkle root
four: to be invented
personally, i like two, because it lets me exclude people i don't want to read from reading my messages and everyone else can't out me without revealing their key and anything they say is hearsay otherwise
Yes and I *think 2 is NIP87...
the arguments against the user-side encryption scheme are simply the bandwidth costs
for each additional user, each user has to send another message to broadcast to everyone
there is probably in-between ways of doing this but the ability to prove authenticity is lost as soon as you start key exchange processes that are ephemeral or otherwise not computable without knowing some ephemeral random secret value and catching that key in the message stream
i think that the natural path of private messaging groups is in opposition to the growth of the number of members in the group
once you pass the dunbar number it's impossible to do it properly as a client side encryption and this opens up being able to authenticate the message and decrypt it without compromising your actual secret key identity at the same time
i think that it's worth making the cost of proving a message authenticity by forcing the breach of your secret key
because then everyone can decript all of your messages as well, it's like a three way mexican standoff