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
This commit is contained in:
parent
b5e5a690f5
commit
14b98a0220
1 changed files with 8 additions and 1 deletions
|
@ -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
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue