Skip to content

Commit 5854ca2

Browse files
committed
Add note about adding m.historical
1 parent d40f3b9 commit 5854ca2

File tree

1 file changed

+5
-1
lines changed

1 file changed

+5
-1
lines changed

proposals/2716-batch-send-historical-messages.md

Lines changed: 5 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -39,6 +39,8 @@ Add a new endpoint, `POST /_matrix/client/unstable/org.matrix.msc2716/rooms/<roo
3939

4040
The `state_events`/`events` payload is in **chronological** order (`[0, 1, 2]`) and is processed it in that order so the `prev_events` point to it's older-in-time previous message which is more sane in the DAG. **Depth discussion:** For Synapse, when persisting, we **reverse the list (to make it reverse-chronological)** so we can still get the correct `(topological_ordering, stream_ordering)` so it sorts between A and B as we expect. Why? `depth` is not re-calculated when historical messages are inserted into the DAG. This means we have to take care to insert in the right order. Events are sorted by `(topological_ordering, stream_ordering)` where `topological_ordering` is just `depth`. Normally, `stream_ordering` is an auto incrementing integer but for `backfilled=true` events, it decrements. Historical messages are inserted all at the same `depth`, and marked as backfilled so the `stream_ordering` decrements and each event is sorted behind the next. (from https://github.com/matrix-org/synapse/pull/9247#discussion_r588479201)
4141

42+
All of the events in the chunk get a content field, `"m.historical": true`, to indicate that they are historical at the point of being added to a room.
43+
4244
With the new process, the DAG will look like:
4345

4446
![](https://user-images.githubusercontent.com/558581/126577416-68f1a5b0-2818-48c1-b046-21e504a0fe83.png)
@@ -161,6 +163,7 @@ The structure of the chunk event would look like:
161163
"sender": "@appservice:example.org",
162164
"content": {
163165
"m.chunk_id": chunk_id,
166+
"m.historical": true
164167
},
165168
"room_id": "!jEsUZKDJdhlrceRyVU:example.org",
166169
// Doesn't affect much but good to use the same time as the closest event
@@ -205,7 +208,8 @@ The structure of the "marker" event would look like:
205208
"type": "m.room.marker",
206209
"sender": "@appservice:example.org",
207210
"content": {
208-
"m.insertion_id": insertion_event.event_id
211+
"m.insertion_id": insertion_event.event_id,
212+
"m.historical": true
209213
},
210214
"room_id": "!jEsUZKDJdhlrceRyVU:example.org",
211215
"origin_server_ts": 1626914158639,

0 commit comments

Comments
 (0)