Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

let's upgrade all public rooms from v1 and spec that all v1 rooms should be frozen henceforth #624

Open
ara4n opened this issue May 21, 2020 · 3 comments
Labels
A-Client-Server Issues affecting the CS API A-Room-spec Something to do with the room version specifications feature Suggestion for a significant extension which needs considerable consideration

Comments

@ara4n
Copy link
Member

ara4n commented May 21, 2020

to stop the residual echos of hotel california ringing in our ears

@turt2live
Copy link
Member

possible approaches:

  • Put in the spec that v1 rooms do not accept new events anymore
    • Without heuristics to determine if a room was upgraded (as the tombstone can be reset away), we would imply that all rooms are upgraded.
    • Could put a date on it ("no new events after January 1st, 1970 at 00:00:00 UTC")
  • Implement a "soft-shutdown" for Synapse/homeservers that does Option A without preventing history from being usable (as shutting down a room blocks all access to the room).
  • Option C goes here.

@turt2live turt2live added A-Client-Server Issues affecting the CS API feature Suggestion for a significant extension which needs considerable consideration A-Room-spec Something to do with the room version specifications labels May 21, 2020
@Half-Shot
Copy link
Contributor

I 100% support this, but the bridge crew would like a heads up so they can start migrating the many many many many many irc rooms still stuck on v1, which have so far been left like that because it's a matrix.org performance nightmare to migrate them at any sort of speed.

@KitsuneRal
Copy link
Member

I'd strongly prefer to keep read-only access to the rooms without ability to send any new events, ever, with every homeserver generating a block of synthetic events (tombstone, power levels) so that well behaved clients could run business as usual without extra changes.

@richvdh richvdh transferred this issue from matrix-org/matrix-spec-proposals Mar 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Client-Server Issues affecting the CS API A-Room-spec Something to do with the room version specifications feature Suggestion for a significant extension which needs considerable consideration
Projects
None yet
Development

No branches or pull requests

4 participants