> View from 1000 feet: maybe a way to lock a room's users would be interesting?

That's a really interesting idea - having immutable memberships could be a good band-aid. The problem is that right now the fact that room membership is typically mutable can be valuable: you add assistants into DMs (human or virtual); you can bridge the DM to other platforms; you can add (benign) audit bots for compliance purposes; you can migrate between Matrix IDs by inviting in your new ID and kicking out the old one; etc.

Of course, this same flexibility comes with a risk, and I see the point that it might be better to 'seal' membership if you know this is flexibility you don't want. We'll have a think.

> Or, instead, maybe an option to disable forwarding session keys older than the user's room join event, to keep forward secrecy so that a new user does not get to read old messages (or does this already happen every 100 messages?).

Currently we never forward session keys, so new users don't get to read old messages whatever. This obviously causes its own problems, especially for Slack/Teams style use cases where new joiners expect to be able to read conversation history. Work is ongoing right now to finally fix this (https://github.com/element-hq/element-meta/issues/39), but we are very mindful of the risk of not sharing existing history to the wrong users (or devices), which is one of the reasons it's taken so long to land.

The 100-message thing is separate: it's the maximum number of times a session-key ratchet can be advanced before it gets replaced. In other words, if you steal a session key, you can only use it to decrypt a maximum of the 100 subsequent messages sent by that device.