[bluesign]

"I think it would be better if the server didn't have metadata visibility into group membership, but that's a largely unsolved problem, and it's unrelated to confidentiality of group messages."

Although this is true, I guess in this case this is not related.

As long as all the communication between peers are e2e, I think this situation can be solved by peers advertising the people they have invited to the group, later clients can refuse to do key exchange with parties, which are not announced before.

Or server can send new member join messages, by relaying a invitation message signed by the admin (or whoever invited the member)

[yuliyp]

> As long as all the communication between peers are e2e, I think this situation can be solved by peers advertising the people they have invited to the group, later clients can refuse to do key exchange with parties, which are not announced before.

This breaks group join links.

[bluesign]

It does not then admin will just announce invite link and clients will check whoever joined with that invite link.

Ofc then whatsapp can reuse that link, but there is already some warning for invite links in whatsapp help

[dredmorbius]

Details?

[yuliyp]

See https://faq.whatsapp.com/en/android/23776567/?category=52452... for the details of the feature. The identity of the new member isn't known at invite time.

[baby]

It doesn't have too though, if you create a join link you could also advertise the code to other participants. When the new member joins via this invitation link, the code is recognized by everyone.

(I've been downvoted for saying that, but the solution works)

[Godel_unicode]

What public key do you suppose would be used to encrypt those messages without giving the server the ability to read them?

[baby]

messages are already encrypted in the group chat, but there is another problem I didn't think about (see other comment)

[yuliyp]

As soon as the code is redeemed, the server has access to the code.

[baby]

1. when you create a joining link, it creates a secret uuid

2. this uuid is shared with the rest of the group

3. if Alice joins the group, every uuid created is shared to Alice (except the one Alice used, if Alice used a joining link)

4. when Bob attempts to join the group via the group id, if Bob does not have a known code Bob is refused

5. if Bob uses a known code, Bob is accepted and everyone deletes the code

This does not prevent different participant views to be created, but this is already a problem in WA anyway.