Conversation
|
Tagged as needs-implementation even though the verification use-case in implemented, since the non-verification use-case is not yet implemented |
|
Given that |
|
(please use threads to receive in-depth/any replies) The way |
|
going to use the key verification framework as an implementation proof for this - https://spec.matrix.org/v1.2/client-server-api/#key-verification-framework |
|
@bwindels apologies, I've taken this over in an effort to get it through (finally). |
| A `rel_type` of `m.reference` is defined as a generic way to associate an | ||
| event with another event. As a bundle, `m.reference` relations appear as | ||
| an object with a single `chunk` field. The `chunk` is an array of objects | ||
| with a single `event_id` field for all the child events which `m.reference` | ||
| the parent. |
There was a problem hiding this comment.
It is just the first "page" of results, if there's a next_token, that can be given to /relations to get the rest.
There was a problem hiding this comment.
Perhaps we can just remove the word "all" in this sentence to eliminate any subtle confusion.
| for events to make a reference to another event. | ||
|
|
||
| A `rel_type` of `m.reference` is defined as a generic way to associate an | ||
| event with another event. As a bundle, `m.reference` relations appear as |
There was a problem hiding this comment.
It would be useful to link to MSC2675 here, which defines bundling related events.
There was a problem hiding this comment.
Actually, we can probably just remove the sentences about server-side aggregation given the information is repeated below under the "Server aggregation" header?
| A `rel_type` of `m.reference` is defined as a generic way to associate an | ||
| event with another event. As a bundle, `m.reference` relations appear as | ||
| an object with a single `chunk` field. The `chunk` is an array of objects | ||
| with a single `event_id` field for all the child events which `m.reference` | ||
| the parent. |
There was a problem hiding this comment.
Perhaps we can just remove the word "all" in this sentence to eliminate any subtle confusion.
|
|
||
| ## Server aggregation | ||
|
|
||
| [MSC2674](https://github.com/matrix-org/matrix-doc/pull/2674) states |
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
|
The final comment period, with a disposition to merge, as per the review above, is now complete. |
* initial draft of reference relations msc * change MSC number * Apply formatting * Convert to point at present rather than ideal * Clarify that multiple relations is a thing we don't have and won't fix here * Fix wording to match reality, again * fix a typo Co-authored-by: Travis Ralston <travisr@matrix.org> Co-authored-by: Andrew Morgan <andrewm@element.io>
|
Spec PR: matrix-org/matrix-spec#1206 |
* Spec reference relationships MSC: matrix-org/matrix-spec-proposals#3267 * Apply suggestions from code review Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> * Edits per code review Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
|
Merged 🎉 |
* Spec reference relationships MSC: matrix-org/matrix-spec-proposals#3267 * Apply suggestions from code review Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> * Edits per code review Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
Rendered
Implementation: The key verification framework
FCP: #3267 (comment)