even then, you can't stop screenshots
Discussion
Yes but screenshots aren't signatures of stuff you supposedly said 😂
yes but the client still has those signed messages, and are you proposing DRM or closed source?
nope, then everything that is shared is potentially public
this is a simple fact of the game theory of communications and secrets
No I'm just saying screenshots are fine, it's not a cryptographic proof it's just some mumbo jumbo pixels anyone can make up.
but only the group would know it's not true if it wasn't, and could prove it
and the rest of the world can't know it's true, but you can't stop the user who makes the screenshot from inspecting their cache
True dat. Well, one way I've been thinking of is that the relay itself is the only one who knows who is who (who has authed). So you post, and it generates new keys for you on the fly for each message. So that narrows the trust vector to who runs the relay. Vs. everyone in the group.
there's also this problem:
It's all very interesting but I just wanna hear exactly why we need a special relay to do NIP29 when afaikt it's just an obfuscation that is easily de-obfuscated. Vs nostr group chats OG with simple mod capabilities.
agreed, there is no advantage
double ratchet and MLS are what lets you keep the cat in the bag outside of the key that is leaked
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.
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
and yes, this is what nostr:npub1zuuajd7u3sx8xu92yav9jwxpr839cs0kc3q6t56vd5u9q033xmhsk6c2uc has been doing with double ratchet and also now extending to MLS
simple kind 4 DMs require you to leak your secret to prove authenticity as well as leak the content
so do 1059 and 1060s
the double ratchet allows you to constrain that leak to one message, and MLS lets you do that with a multi party message
being able to constrain what can be leaked by providing the secret is another factor in this
if you want to out someone who sent you a DM, you have to give away your nsec, as well
double ratchet lets you avoid that problem, and ironically this is called forward secrecy with revocability because you can change that secret any time and not compromise your primary root key
MLS lets that happen to a whole group chat
yes, i get it now tho...
private is not secret
secret is only one person knows it
private is two or more
once it's private, it can become public, if one person betrays the pact