For what it's worth, i just did a quick survey of other secure messaging systems to see how they manage group membership. These days Signal uses zkgroups as pe

For what it's worth, i just did a quick survey of other secure messaging systems to see how they manage group membership. These days Signal uses zkgroups as per https://signal.org/blog/signal-private-group-system https://signal.org/blog/signal-private-group-system; it looks like Wire is somewhere in a transition to MLS for client-managed group membership (although historically membership looks to be entirely controlled by the server). I dread to think what WhatsApp or iMessage do (anyone know if membership is server-controlled or not?) So yes: we should switch to client-controlled membership management, and we've already started the work to do so. However, the Matrix spec and its implementations has always been transparent that it's up to the user to verify the membership of the room - for after all, if they don't bother verifying users, then all bets will always be off anyway. For instance https://element.io/blog/e2e-encryption-by-default-cross-signing-is-here/#all-new-ui-ux-for-e2ee https://element.io/blog/e2e-encryption-by-default-cross-sign... explicitly says: "You’ve verified this user, but they have risky unverified sessions logged in! A room containing any red users is shown as red." I'm not sure this exactly counts as a research result, let alone a devastating one. However, totally agreed that we can improve on this, and we're on the case.