Meta bug for edge cases that should be considered to make room upgrades transparent

[ara4n]

• Room membership (for public rooms) Membership should be transferred when upgrading a room #455
• Room membership (for private rooms) Membership should be transferred when upgrading a room #455 (and Current room upgrade behavior does not work nicely with invite-only rooms #425)
• Telling users about the new room if we are not yet syncing room membership (Fix required fields in /_matrix/key/v2/server response schema #1930)
• Arbitrary room state Consider adding options to selectively transfer state on room version upgrade #454, Consider supporting arbitrary state changes when upgrading rooms #427
  • it's unclear whether it's sufficient for the upgrading user to be able to re-create the state on behalf of the original users, or if we should get the original servers to re-create the state. Presumably if we did the latter, then we could solve Membership should be transferred when upgrading a room #455 too?
• Specific room state? (If we're not supporting arbitrary room state)
  • What flair is enabled for a room
  • What widgets are provisioned in a room Transfer widgets on room upgrade synapse#4994
  • Power levels
    • Bans Transfer bans on room upgrade synapse#4642
  • Federatability Copy over non-federatable trait on room upgrade synapse#4530
  • Server ACLs Transfer bans on room upgrade synapse#4642
  • Encryption Migrate encryption state on room upgrade synapse#4411
• Tag state Migrate direct message and tag state on room upgrade synapse#4412
• Room directory entries Room directory doesn't de-publish tombstoned rooms synapse#4948
• Per-room push rules Transfer user's push rules on room upgrade synapse#4838
• Community membership (i.e. which rooms exist in a given community) Transfer rooms on groups when the rooms are upgraded synapse#4897
• Making bridges and bots and integrations in general upgrade-aware (e.g. Support room upgrades matrix-appservice-bridge#100)

At the least, we should ensure the spec reminds implementors to handle all these edge cases...

[richvdh]

see also: https://github.com/matrix-org/synapse/labels/A-Room-Upgrades

[richvdh]

Arbitrary room state #454, #427

Neither #454 nor #427 appear to be "copy all state over by default", which is what I think you mean here?

[julianfoad]

See also
element-hq/element-ios#2486
element-hq/riot-android#3186

[anoadragon453]

Curious if these two issues are solved by client-side behaviour now, or if that's not considered the ideal end goal:

• Room membership (for public rooms) Membership should be transferred when upgrading a room #455
• Room membership (for private rooms) Membership should be transferred when upgrading a room #455 (and Current room upgrade behavior does not work nicely with invite-only rooms #425)

[Half-Shot]

I have nothing specific to add here, other than a datapoint that we upgraded a lot of rooms within a space today and it was a very painful experience to copy state over. A lot of the bots I tend to use in EMS-land use room state for configuration, and it doesn't feel like the bots should be responsible for copying that state over.

[clokep]

matrix-org/synapse#10774 made upgrading a space possible, which seems like it should be mentioned somewhere here. 😄

[dkasak]

Regarding carrying over arbitrary room state, there seemed to be some consensus that it was the way to go yesterday, but two points were raised:

• There'd be no way to have a room upgrade into a clean slate. This would be solved neatly by Consider adding options to selectively transfer state on room version upgrade #454.
• More specifically, we might want to retain the ability to drop m.room.member == leave state. This could be either special-cased or again incorporated into the mechanism suggested by Consider adding options to selectively transfer state on room version upgrade #454.