MSC4203: Sending to-device events to appservices#4203
Conversation
Signed-off-by: Tulir Asokan <tulir@maunium.net>
tulir
added
proposal
There was a problem hiding this comment.
Implementation requirements:
- Appservice
- Server
There was a problem hiding this comment.
It looks like both of these exist now 🙂
|
MSCs proposed for Final Comment Period (FCP) should meet the requirements outlined in the checklist prior to being accepted into the spec. This checklist is a bit long, but aims to reduce the number of follow-on MSCs after a feature lands. SCT members: please check off things you check for, and raise a concern against FCP if the checklist is incomplete. If an item doesn't apply, prefer to check it rather than remove it. Unchecking items is encouraged where applicable. Checklist:
|
| ### Implementation detail: when to delete a to-device message | ||
|
|
||
| Not defined by this MSC is an explicit algorithm for when to delete a to-device message (mark | ||
| it as sent). This is left as an implementation detail, though a suggested approach is as | ||
| follows: | ||
|
|
||
| * If the message is sent to a user under an appservice's *exclusive* namespace mark it as sent | ||
| and delete it. Note that retried transactions will still need to include the message. | ||
| * If the message is sent to a user under an appservice's *inclusive* namespace, mark it as sent | ||
| to the appservice but do not delete it until a `/sync` request is completed which includes the | ||
| message. Note that retried transactions will still need to include the message. | ||
|
|
||
| This approach is largely to align with how namespaces are used by appservices in practice, but | ||
| is not applicable to all scenarios (and thus is an implementation detail). The majority of known | ||
| appservices use exclusive namespaces, which typically also means that those users will not be | ||
| calling `/sync`. Because of this, the server may never get another opportunity to delete the | ||
| messages until it has confirmed that the appservice received the transaction successfully. Inclusive | ||
| namespaces are typically used when the appservice wants to impact a subset of users, but without | ||
| controlling those users explicitly. Typically, inclusive users are also calling `/sync` and so | ||
| the appservice should be CC'd on the to-device messages that would normally go down `/sync`. | ||
|
|
||
| For inclusive namespaces, servers may also track who created a device, and not wait for `/sync` | ||
| if the device was created using [appservice login] or [appservice device management]. |
There was a problem hiding this comment.
Leaving this as an implementation detail might be wrong. I think the approach suggested here also won't work when transitioning from /sync to transactions. There are currently a lot of appservices with exclusive namespaces who will /sync to get their to-device events. If the server starts sending to-device events over /transactions unprompted, the appservices could get events double delivered (if the event is in both /transactions and /sync) or not delivered at all (if they ignore /transactions and the event gets deleted before reaching /sync).
MSC3202 has an org.matrix.msc3202 opt-in flag, maybe it'd make sense to reuse that for to-device events (because all appservices using this MSC presumably already have that flag set) and also define a stable opt-in flag that encompasses both to-device events and other e2ee-related transactions data
4 participants
Rendered
Part of #3202, split off from #2409
Implementations:
SCT stuff:
MSC checklist
Not yet proposed for FCP