Add EDUs to appservice transactions #1496
Conversation
Many bridges are interested in this information, and considering they can no longer sync themselves they need a way to get EDUs. Servers should send EDUs as per the rules for "interested events" defined elsewhere. EDUs are a new top level key for backwards compatibility and sanity. Having EDUs in the events array would likely break appservices which are not EDU-aware due to missing fields and unknown event types. The events array is still required for backwards compatibility. The added condition of it may be empty has been added so that appservices which are not aware of EDUs don't break with a missing field. Appservices should be iterating over the list, so a zero-element list should be fine.
| items: | ||
| type: object | ||
| title: Ephemeral Event | ||
| # TODO: Reference client schema for EDUs |
There was a problem hiding this comment.
I think this is something we haven't yet defined in the client-server spec, but would be nice to do. I'd like to fork that off to the "improve client-server spec" pile though.
| "content": { | ||
| "user_ids": ["@alice:localhost"] | ||
| } | ||
| } | ||
| ] | ||
| } | ||
| description: "Transaction informations" |
|
Just leaving a note: this is being put as r0-time-permitting and may very well end up in a post-r0 world. There's concerns about the complexity of calculations needed to handle presence for appservices, amoung other EDUs. The complexity comes about due to presence not being bound to a room. When a server receives a presence update, it would have to cross reference rooms that the presence user is in and rooms the appservice is in, which leads to a nightmarish loop. Initial attempts to implement this calculation have shown that it can take several seconds depending on the user at hand. The fastest approach appears to be looping through the rooms the sending user is in (and known to the server), then checking the membership list of each room for an appservice - returning early if needed. Servers with multiple appservices have other optimizations they can make (iterating until all appservices are discovered in the room, or the end of the membership list is reached). |
turt2live
added
the
blocked
|
Closing pending MSC |
Rendered: see 'docs' commit status
Synapse PR: coming soon
Many bridges are interested in this information, and considering they can no longer sync themselves they need a way to get EDUs. Servers should send EDUs as per the rules for "interested events" defined elsewhere.
EDUs are a new top level key for backwards compatibility and sanity. Having EDUs in the events array would likely break appservices which are not EDU-aware due to missing fields and unknown event types.
The events array is still required for backwards compatibility. The added condition of it may be empty has been added so that appservices which are not aware of EDUs don't break with a missing field. Appservices should be iterating over the list, so a zero-element list should be fine.
Fixes matrix-org/matrix-spec#270