@@ -421,22 +421,92 @@ class RoomStreamToken:
421
421
422
422
s0 s1
423
423
| |
424
- [0] V [1] V [2]
424
+ [0] ▼ [1] ▼ [2]
425
425
426
426
Tokens can either be a point in the live event stream or a cursor going
427
427
through historic events.
428
428
429
- When traversing the live event stream events are ordered by when they
429
+ When traversing the live event stream, events are ordered by when they
430
430
arrived at the homeserver.
431
431
432
- When traversing historic events the events are ordered by their depth in
433
- the event graph "topological_ordering" and then by when they arrived at the
434
- homeserver "stream_ordering".
432
+ When traversing historic events, events are first ordered by their
433
+ "depth" ("topological_ordering" in the event graph) and tie-broken by
434
+ "stream_ordering" (when the event arrived at the homeserver).
435
+
436
+ ---
435
437
436
438
Live tokens start with an "s" followed by the "stream_ordering" id of the
437
- event it comes after. Historic tokens start with a "t" followed by the
438
- "topological_ordering" id of the event it comes after, followed by "-",
439
- followed by the "stream_ordering" id of the event it comes after.
439
+ event that comes after. The rest of the keys are joined together by
440
+ underscores in the following order and represent the position of various
441
+ data.
442
+
443
+ ex. `s2633508_17_338_6732159_1082514_541479_274711_265584_1`
444
+ 1. `room_key`: `s2633508` -> `2633508` `stream_ordering`
445
+ 2. `presence_key`: `17`
446
+ 3. `typing_key`: `338`
447
+ 4. `receipt_key`: `6732159`
448
+ 5. `account_data_key`: `1082514`
449
+ 6. `push_rules_key`: `541479`
450
+ 7. `to_device_key`: `274711`
451
+ 8. `device_list_key`: `265584`
452
+ 9. `groups_key`: `1`
453
+
454
+ For example, you can see how many of these keys correspond to the various
455
+ fields in the "/sync" response:
456
+ ```
457
+ {
458
+ "next_batch": "s12_4_0_1_1_1_1_4_1",
459
+ "presence": {
460
+ "events": []
461
+ },
462
+ "device_lists": {
463
+ "changed": []
464
+ },
465
+ "rooms": {
466
+ "join": {
467
+ "!QrZlfIDQLNLdZHqTnt:hs1": {
468
+ "timeline": {
469
+ "events": [],
470
+ "prev_batch": "s10_4_0_1_1_1_1_4_1",
471
+ "limited": false
472
+ },
473
+ "state": {
474
+ "events": []
475
+ },
476
+ "account_data": {
477
+ "events": []
478
+ },
479
+ "ephemeral": {
480
+ "events": []
481
+ }
482
+ }
483
+ }
484
+ }
485
+ }
486
+ ```
487
+
488
+ ---
489
+
490
+ Historic tokens start with a "t" followed by the "depth"
491
+ ("topological_ordering" in the event graph) of the event that comes after,
492
+ followed by "-", followed by the "stream_ordering" id of the event it comes
493
+ after along with rest of the same keys from the live tokens.
494
+
495
+ You will see this type of token when using the "/messages" endpoint.
496
+
497
+ ex. `t426-2633508_17_338_6732159_1082514_541479_274711_265584_1`
498
+ 1. `topological_ordering`: t426 -> `426` `depth`
499
+ 2. `room_key`: `2633508` `stream_ordering`
500
+ 3. `presence_key`: `17`
501
+ 4. `typing_key`: `338`
502
+ 5. `receipt_key`: `6732159`
503
+ 6. `account_data_key`: `1082514`
504
+ 7. `push_rules_key`: `541479`
505
+ 8. `to_device_key`: `274711`
506
+ 9. `device_list_key`: `265584`
507
+ 10. `groups_key`: `1`
508
+
509
+ ---
440
510
441
511
There is also a third mode for live tokens where the token starts with "m",
442
512
which is sometimes used when using sharded event persisters. In this case
@@ -460,6 +530,8 @@ class RoomStreamToken:
460
530
commonly used instance names) are at positions 58 and 59 respectively, and
461
531
all other instances are at position 56.
462
532
533
+ ---
534
+
463
535
Note: The `RoomStreamToken` cannot have both a topological part and an
464
536
instance map.
465
537
0 commit comments