From 14b98a02203b913956d876c1b00f406ba047b65a Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Wed, 17 Oct 2018 20:28:53 +0100 Subject: [PATCH] A couple of clarifications - the body of the tombstone is defined by the server. - the client can follow tombstones until it finds a live room --- proposals/1501-room-version-upgrades.md | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/proposals/1501-room-version-upgrades.md b/proposals/1501-room-version-upgrades.md index 55af33411..fc0bf71e1 100644 --- a/proposals/1501-room-version-upgrades.md +++ b/proposals/1501-room-version-upgrades.md @@ -77,10 +77,13 @@ When this is called, the server: } ``` + The `body` of the tombstone event is defined by the server (for now, at + least). + * Assuming Alice has the powers to do so, sets the power levels in the old room to stop people speaking. In practice, this means setting `events_default` and `invite` to the greater of `50` and `users_default+1`. - + Bob's client understands the `m.room.tombstone` event, and: * Hides the old room in the room list (the room continues to be accessible @@ -96,6 +99,10 @@ Bob's client understands the `m.room.tombstone` event, and: for a while and eventually fails. Synapse 0.33.3 should at least give a sensible error code.] + If it turns out that the replacement room also has a tombstone event, the + client may automatically keep following the chain until it reaches a room + that isn't dead. + * Optional extension: if the user is in both rooms, then the "N unread messages" banner when scrolled up in the old room could be made to track messages in the new room (so in practice the user would only ever see the