MSC3682: Sending Account Data to Application Services#3682
Conversation
reivilibre
changed the title
turt2live
added
A-Application Services
turt2live
left a comment
turt2live
left a comment
There was a problem hiding this comment.
Generally looks good! Thanks for writing it up.
Just a handful of relatively minor comments, all things considered.
| "@asuser1:example.org": { | ||
| "events": [ |
There was a problem hiding this comment.
we could also just collapse this down to "@user:example.org": [ {"type": ... } ] as we don't need the layer of indirection events provides.
| This introduces additional implementation complexity to homeservers which now need to detect when | ||
| account data changes and send changes. Specifically, it shifts the interaction from a pull model to a push model, which some homeserver implementations may not have been designed for initially. |
There was a problem hiding this comment.
it's somewhat worth mentioning that the "push" model is expected by servers already in the form of /sync: with long-polling, the request only concludes if no changes happened, which means an internal wake/push to the sync loop to do something. In the case of appservices, instead of it being a wake to the sync loop it's a wake to the transaction builder.
|
|
||
| Some Application Services may not benefit from this additional information in which case it would | ||
| be wasteful of computational resources to compute and transmit it. | ||
| ⇒ **TODO** opt-in/out in the AS registration file. Good idea or not? |
There was a problem hiding this comment.
Probably best as an implementation detail for now - the spec should support it not being present at all, though I've never been happy with us defining how a registration file works in the spec.
|
Note to future implementers: if your project has implemented MSC3391 then you may need to be cautious about when you fully "delete" an account data entry. Make sure you inform application services of the change first before you do! The second half of the description of matrix-org/synapse#14244 has some details about the implementation of MSC3391 in Synapse and tracking when a user's devices has seen an account data item be deleted. I don't imagine it'll be too bad as we'll likely inform application services of changes to account data right away - but just something to consider for your reliability model. |
Co-authored-by: Travis Ralston <travisr@matrix.org>
3 participants
Rendered
Preview: https://pr3682--matrix-org-previews.netlify.app