MSC1849: Proposal for m.relates_to aggregations

proposals/1849-aggregations.md

@@ -45,14 +45,26 @@ and
 }
 ```
 
+or if building a relation DAG (for ordering for edits, and for pulling in missing relations after a federation outage):
+
+```json
+"type": "m.reaction",
+"contents": {
+    "m.text": "👍",
+    "m.relates_to": {
+        "event_id": ["$another:event.com", "$another2:event.com"]
+    }
+}
+```
+
 And then the server just blitzes through `m.relates_to.event_id` and builds up all the relationships based on that field.
 This is kinda similar to pik's proposal below, but without the JSON schema.
 
-`event_id` should take either a string or a list of strings, to support relation DAGs (needed for ordering edits)
+XXX: `event_id` should take either a string or a list of strings, to support relation DAGs (needed for ordering edits)
 
 ## CS API considerations
 
-Then, whenever the event is served down the CS API, we inline all the relationships for a given event (modulo filters)?
+Then, whenever the event is served down the CS API, we inline the relations for a given event (modulo filters)?
 
 For edits, we'd want the most recent relation (by default)
 For reactions, we want all the reaction objects (or ideally their sum?)
@@ -97,8 +109,8 @@ So:
 
 ## Sending relations
 
-```json
 PUT /_matrix/client/r0/rooms/{roomId}/send_relation/{parent_id}/{eventType}/{txnId}
+```json
 {
     "m.text": "👍",
 }
@@ -111,9 +123,9 @@ adding the `parent_id` as one parent, but also adding any other dangling relatio
 
 TODO:
 
-/sync
-/messages
-/context
+ * /sync
+ * /messages
+ * /context
 
 ## Pagination considerations
 
@@ -169,8 +181,11 @@ XXX: We have a problem with resynchronising relations after a gap in federation.
 We have no way of knowing that an edit happened in the gap to one of the events
 we already have.  So, we'll show inconsistent data until we backfill the gap.
  * We could write this off as a limitation.
- * Or we could make relations a DAG, so we can spot holes at the next relation, and
-   go walk the DAG to pull in the missing relations?
+ * Or we could make *ALL* relations a DAG, so we can spot holes at the next relation, and
+   go walk the DAG to pull in the missing relations?  Then, the next relation for an event
+   could pull in any of the missing relations.
+ * Could we also ask the server, after a gap, to provide all the relations which happened during the gap to events whose root preceeded the gap.
+   * "Give me all relations which happened between this set of forward-extremities when I lost sync, and the point i've rejoined the DAG, for events which preceeded the gap"?
 
 In future, we might want to aggregate relational events (e.g. send a summary of the events, rather than the
 actual original events).  This requires the payload to be non-E2E encrypted, and would also require some kind of