Feature Request: Optionally Populate History on Room Upgrade

[ChristianTacke]

Description:

When upgrading a room it would be nice, if the new room could be populated with the old history. So that the new room has the full history.
As one server does the creation of the new room, that server should be able to prepopulate the history?

This behaviour most likely should be optional.

[rubo77]

Maybe optionally in the old room all messages could be redacted then to save space in the database

[ChristianTacke]

If everybody has moved to the new room, and the new room has no backlink to the old room, then the old room should be garbage collected (because unreachable) anyway?

NOTE: E2EE rooms could pose their own issues. If this IS an actual problem, then one could start this feature with unencrypted rooms first.

[anoadragon453]

This is more of a Matrix Spec feature request than one for Synapse. Importing the history from an old room is not straightforward as rules may change in a new room version that make old room events incompatible with the new room. Not to mention events include the room ID that they're sent in, which would not make sense if they were simply moved over. One server cannot replace the room ID of all events either, as each event is cryptographically signed by the sending homeserver.

Seamlessly splicing together upgraded rooms is something that has been talked about quite widely, and is generally agreed that it should be a client feature - albeit with some tweaks from the server-side, such as seamlessly transferring membership state from the old room to the new.

Also note that upgrading rooms can be useful in the fact that you get a branch new room without legacy state events bogging it down. Transferring all old events would remove this benefit.

Maybe optionally in the old room all messages could be redacted then to save space in the database

These events would need to be purged, as redacting an event is simple the act of sending a redaction event referencing the other event. You may as well just remove and purge the room.

If everybody has moved to the new room, and the new room has no backlink to the old room, then the old room should be garbage collected (because unreachable) anyway?

Synapse does not currently garbage-collect unreachable rooms, but that is something on the roadmap #4720.

TL;DR this is a worthwhile discussion, but one that requires thinking about a lot of tricky edge cases. I recommend taking it up on https://github.com/matrix-org/matrix-doc on one of the existing issues.

[ChristianTacke]

Thanks @anoadragon453 for the detailed explanations!

TL;DR this is a worthwhile discussion, but one that requires thinking about a lot of tricky edge cases. I recommend taking it up on https://github.com/matrix-org/matrix-doc on one of the existing issues.

Can you recommend some issues?

Or should I open a new one there?

[rubo77]

Why is this closed? Is the plan to seamlessly splice together rooms on the roadmap instead?

I think this should not be closed, just because it is difficult to implement, unless there are new issues on the right places.
And please link to those new issue here

[anoadragon453]

@ChristianTacke Sure, https://github.com/matrix-org/matrix-doc/issues/1942 is the meta-bug for it all.

I think this should not be closed, just because it is difficult to implement

It's not that this is difficult to implement, it's that seamless room upgrades shouldn't be solved by importing all room history from one room to another; for the reasons described above.

[rubo77]

So where should we open a new issue then to "Seamlessly splicing together rooms on upgrade"?

[anoadragon453]

@rubo77 I would start thinking from the client-side perspective. What do you want seamless room upgrades to look like? How would the clients be able to show the required information, and how would the backend handle it?

Once you have an idea of what's needed to get this to work, make individual issues on https://github.com/matrix-org/matrix-doc for the specific spec changes needed, and then issues for the relevant homeserver implementations to update their spec compliance.

An issue on https://github.com/matrix-org/matrix-doc could also be a good place to brainstorm.

[heini]

@anoadragon453, a room "upgrade" should IMHO not create a new room at all. Otherwise it should be called "room replacement".

[anoadragon453]

The idea is for clients to eventually have UX which makes room upgrades seamless, even though they are implemented as completely separate rooms that point to each other under the hood.