support time restricted use of more automatic room upgrades

[thestinger]

Room upgrades are not more automated than they are because it could be abused as a denial of service / spam attack. People could upgrade a room hundreds of times and have the users automatically joined to each of them. It seems this could be resolved by supporting a single automatic room upgrade where all users are added to the new room by each server that's still active and sees the upgrade. The new room will have the fact that it was an automatic upgrade recorded by each server and they can disable doing another automatic upgrade for the new room for a standard time like 1 month. Members on dead servers won't get added to the new one since the server is gone. Inactive users will be added, which is essentially harmless, but servers could optionally limit the automatic migration of users to active accounts with a login within the past 6 months.

Room upgrades are currently a very bad experience. The tombstone sends out a single notification to each user but many people who are still active end up missing it. It takes a long time for people to move over to the new room and it's a very confusing user experience. It severely disrupts the chat for a long period of time in large rooms. The discussion becomes about the room upgrade and many people who were having conversations need to wait until the people they were talking to see the upgrade and join the new room. This is particularly bad when people are using threads. Inviting each user from the old room helps move things alone but implies doubling the number of state events needed for everyone to join and it takes a very long time to federate each invite for large rooms. Many users seem to have invites hidden due to spam and most notifications disabled or ignored if they're already overwhelmed with notifications. They will eventually notice the room was upgraded when they explicitly check it, but in the meantime no one can mention them in the room, they won't get room pings (which we use in our testing volunteer rooms), etc.

The state resets continued happening for us with our newly upgraded rooms and upgrading our rooms every 6-12 months due to this will keep bleeding away large parts of our community which we're unwilling to do. Moving to another chat platform would be more disruptive than a room upgrade, but easier than consistently having to do room upgrades over and over especially when we can leave the Matrix rooms intact, bridged to the new platform and stop directing users to them due to state resets. We'd prefer to keep using Matrix for GrapheneOS but we need way to work around these bugs seemingly triggered by frequent raids.

[clokep]

Room upgrades are not more automated than they are because it could be abused as a denial of service / spam attack.

I have not heard of this being the reason that room upgrades are not more automated. I think they're mostly not more automated because they're hopefully rare. Thoughts on this have changed over time though.

It seems this could be resolved by supporting a single automatic room upgrade where all users are added to the new room by each server that's still active and sees the upgrade. The new room will have the fact that it was an automatic upgrade recorded by each server [...snip...]

I think this is pretty much an implementation proposal for transferring membership during room upgrades?

Room upgrades are currently a very bad experience. The tombstone sends out a single notification to each user but many people who are still active end up missing it. It takes a long time for people to move over to the new room and it's a very confusing user experience. It severely disrupts the chat for a long period of time in large rooms. The discussion becomes about the room upgrade and many people who were having conversations need to wait until the people they were talking to see the upgrade and join the new room.

Having transparent room upgrades would make this much better (although it might also require transferring membership during room upgrades).

Using today's technology, the trixnity client had a neat presentation at FOSDEM 2023 that shows how the timeline can be made a bit more transparent (around ~19 minutes into the video):

This is particularly bad when people are using threads.

Threads are currently per room, there is a tracking issue for this. It is limited due to event relations being per-room, so there wasn't an obvious solution.

Inviting each user from the old room helps move things alone but implies doubling the number of state events needed for everyone to join and it takes a very long time to federate each invite for large rooms.

I think transferring membership during room upgrades would be the overall fix for this. State events do get replaced when the user joins, so it does increase the overall number of state events, but shouldn't increase the "current" state of the room. I'm a bit surprised if it is taking that long for each invite to occur, unless you're hitting rate limits maybe? Regardless that sounds like a separate issue.

Many users seem to have invites hidden due to spam and most notifications disabled or ignored if they're already overwhelmed with notifications.

I think there were a couple of issues recently with invites being hidden in Element Web, this has bitten me a few times, but was recently fixed. I don't know of a way to actually hide invites, but I think you can disable notifications for them.

There was also a bit of research into reducing the notifications by default, but this is quite hard as different users have very different expectations for their notifications. (Based on what sort of rooms they join -- e.g. large public rooms, small DMs, etc.)

They will eventually notice the room was upgraded when they explicitly check it, but in the meantime no one can mention them in the room, they won't get room pings (which we use in our testing volunteer rooms), etc.

I think this is related to matrix-org/matrix-spec#455 from above -- if users were automatically joined to the new room then pings, etc. would work fine.

The state resets continued happening for us with our newly upgraded rooms and upgrading our rooms every 6-12 months

#14481 seems to be the tracking issue for this.

---

Overall there's some interesting ideas here, but it is mixing a lot of different issues together. Hopefully I've pointed you to some other areas where this work is being tracked.