Handle state deletion

proposals/4186-simplified-sliding-sync.md

@@ -419,7 +419,7 @@ When a user is or has been in the room, the following field are returned:
 | `is_dm` | `bool` | No | Flag to specify whether the room is a direct-message room (according to account data). |
 | `initial` | `bool` | No | Flag which is set when this is the first time the server is sending this data on this connection, or if the client should replace all room data with what is returned. Clients can use this flag to replace or update their local state. The absence of this flag means `false`. |
 | `unstable_expanded_timeline` | `bool` | No | Flag which is set if we're returning more historic events due to the timeline limit having increased. See "Changing room configs" section. |
-| `required_state` | `[Event]` | No | Changes in the current state of the room. |
+| `required_state` | `[Event\|StateStub]` | No | Changes in the current state of the room. <br/><br/> To handle state being deleted, the list may include a `StateStub` type (c.f. schema below) that only has `type` and `state_key` fields. The presence or absence of `content` field can be used to differentiate between the two cases. |
 | `timeline_events` | `[Event]` | No | The latest events in the room. May not include all events if e.g. there were more events than the configured `timeline_limit`, c.f. the `limited` field. <br/><br/> If `limited` is true then we include bundle aggregations for the event, as per sync v2. <br/><br/> The last event is the most recent. |
 | `bump_stamp` | `int` | No | An integer that can be used to sort rooms based on the last "proper" activity in the room. Greater means more recent. <br/><br/> "Proper" activity is defined as an event being received is one of the following types: `m.room.create`, `m.room.message`, `m.room.encrypted`, `m.sticker`, `m.call.invite`, `m.poll.start`, `m.beacon_info`. <br/><br/> For rooms that the user is not currently joined to, this instead represents when the relevant membership happened, e.g. when the user left the room. <br/><br/> The exact value of `bump_stamp` is opaque to the client, a server may use e.g. an auto-incrementing integer, a timestamp, etc. <br/><br/> The `bump_stamp` may decrease in subsequent responses, if e.g. an event was redacted/removed (or purged in cases of retention policies). |
 | `prev_batch` | `string` | No | A token that can be passed as a start parameter to the `/rooms/<room_id>/messages` API to retrieve earlier messages. |
@@ -464,6 +464,16 @@ The `StrippedHero` has the following fields:
 | `avatar_url` | string | No | The avatar url from the membership event, if set |
 
 
+### `StateStub` type
+
+The `StateStub` is used in `required_state` to indicate that a piece of state has been deleted.
+
+| Name | Type | Required | Comment |
+| - | - | - | - |
+| `type` | string | Yes | The `type` of the state entry that was deleted |
+| `state_key` | string | Yes | The `state_key` of the state entry that was deleted |
+
+
 ### Example response
 
 ```jsonc
@@ -600,7 +610,7 @@ in `/_matrix/client/versions` is `org.matrix.simplified_msc3575`.
 
 1. In the response should we specify which lists a room is part of?
 1. <del>Should `knock_state` and  `invite_state` use the same name in the room response, e.g. `stripped_state`?</del>
-1. In the room response how do we inform clients that a piece of state was deleted (rather than added/updated)?
+1. <del>In the room response how do we inform clients that a piece of state was deleted (rather than added/updated)?</del>
 1. We need to decide what to do with `unstable_expanded_timeline`. We can either rename it to `expanded_timeline`, or
    remove the functionality and replace it with a bulk `/messages` endpoint (for multiple rooms). See "Timeline event
    trickling" section.
@@ -628,3 +638,4 @@ Changes from the initial implementation of simplified sliding sync.
 
 1. Add `set_presence` URL param.
 2. Rename `invite_state` to `stripped_state`
+3. When state is deleted we return a stub `{"type: "..", "state_key": ".." }` in `required_state`.