MSC2409: Proposal to send EDUs to appservices

[Sorunome]

Rendered

This MSC is a continuation of MSC1888 and thus deprecates it.

Implementations:

• SDKs
  • https://github.com/matrix-org/matrix-appservice-bridge/
  • https://github.com/matrix-org/matrix-appservice-node/
  • https://github.com/turt2live/matrix-bot-sdk
• Bridges
  • https://github.com/matrix-org/matrix-appservice-irc
  • (and other matrix-appservice-bridges generally have support like Slack)
• Homeservers
  • Send some ephemeral events to appservices synapse#8437
  • Send to-device messages to application services synapse#11215

Signed-off-by: Sorunome mail@sorunome.de

---

FCP tickyboxes

[ericmigi]

bumping this up as it would help out of a ton of mx-puppet-slack users! :)

[MRAAGH]

I really miss this while using mx-puppet-discord. Typing notifications add so much extra value to a chat!

[auscompgeek]

It seems to me that it would be worth making appservices opt into receiving EDUs to avoid pushing EDUs to an appservice that doesn't care about them.

[Half-Shot]

@auscompgeek would be even better if appservices could add a filter to their registration data to filter out anything they don't care about.

[Sorunome]

@Half-Shot maybe in general add the filter object to the registration file? That way PDUs could also be filtered. That sounds like it should be a separate MSC, though

[Half-Shot]

@Half-Shot maybe in general add the filter object to the registration file? That way PDUs could also be filtered. That sounds like it should be a separate MSC, though

It was one from a while ago, but we dropped at the time as the performance gains from doing so weren't worth it.

[Sorunome]

@Half-Shot maybe in general add the filter object to the registration file? That way PDUs could also be filtered. That sounds like it should be a separate MSC, though

It was one from a while ago, but we dropped at the time as the performance gains from doing so weren't worth it.

Does it sound worthy to bring that up again, in relation with this MSC, and then leave filtering to, well, the filters?

[Half-Shot]

Yup. I think it's worth noting that we might need filters, but at this point I think that's a seperate concern. This MSC is facilitating the ability for ASes to recieve EDU traffic, another MSC can handle filtering of that traffic.

[Half-Shot]

Implementing backend at matrix-org/synapse#8437 (available in 1.22.0)
Implementing bridge side at matrix-org/matrix-appservice-node#32 (available in 0.6.0)

[tulir]

mautrix-python impl: mautrix/python@ee74e17

[Half-Shot]

Hey, it's 2023 (well, it's nearly 2024 but don't let that get you down)!

I'm thinking of picking this one up, as it's a few years later and we're (matrix.org bridges / Element integrations) are using this MSC a lot, which is generally a good indicator that we like what it does and it works well enough.

I think there are probably two tracks here to be cleaned up, which are:

Are we happy with the general format of the transaction body (type v.s. edu_type).

I'm generally of the opinion that since this landed in Synapse experimentally, we've managed to implement this without much pain and what is spec'd seems to work.

Is it performant?

This is harder to answer, but we did run the libera.chat bridge for a number of years with this enabled and Element runs several servers with this feature turned on so I think in a lot of cases it can be performant. There are a few outstanding Synapse bugs, but my feeling is these are implementation problems / details and do not pertain to the described spec.

In short, I think we're in a place to start considering this as a proper spec now. We've got implementations, we've got happy usage out of it. The next steps I believe are to hear what the consensus is from the spec team and wider.

[tulir]

I'm generally of the opinion that since this landed in Synapse experimentally, we've managed to implement this without much pain and what is spec'd seems to work.

It's implemented as type everywhere, but the proposal text still says edu_type 🤔

[Half-Shot]

I don't think it's worth trying to rewrite the world, let's just fix the proposal.

[turt2live]

Let's get this into the feedback engine :)

@mscbot fcp merge

[mscbot]

This FCP proposal has been cancelled by #2409 (comment).

Team member @mscbot has proposed to merge this. The next step is review by the rest of the tagged people:

• @clokep
• @dbkr
• @uhoreg
• @turt2live
• @ara4n
• @anoadragon453
• @richvdh
• @tulir
• @erikjohnston
• @KitsuneRal

Once at least 75% of reviewers approve (and there are no outstanding concerns), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for information about what commands tagged team members can give me.

[dbkr]

Suggested change

	Note that the EDU is otherwise formatted as it would for client-server API transport.
	Note that the EDU is otherwise formatted as it would be for client-server API transport.

[richvdh]

This doesn't appear to be the case, based on the example above. For example, the C-S API puts typing notifications under the corresponding room, so doesn't need a separate room_id key in the m.typing notification itself.

I'm not really sure what the word "otherwise" is doing in this sentence.

Please be explicit about exactly what format each type of event should use.

[dbkr]

Could this get a mention back where the ephemeral key is introduced please? ie. give a summary of what's being added and then give the detail on each.

[dbkr]

Would maybe make more sense to wrap the to_device events in their own object which contains the metadata for this transport layer? ie.

{
  "to_user_id": "@_irc_bob:example.org",
  "to_device_id": "ABCDEF123",
  {
    "type": "org.example.to_device_event_type",
    "sender": "@alice:example.com",
    "content": {
      "hello": "world"
    }
  }
}

...then there's no chance of overlapping keys (although obviously this would be unlikely anyway) and the receiving server can just take the inner object out and pass it on verbatim?

[richvdh]

you'd need a name for the property that contains the inner object

[dbkr]

nitpick, perhaps, but since this file is describing the app service, should it be, receive_ephemeral rather than 'push'? (indeed, the comment below is phrased in this way too).

[dbkr]

I'm not 100% on this but it feels slightly confusing that ephemeral here matches the new ephemeral section the body, but it also controls the presence of the to_device section. Could it be clearer to just have a separate field to control whether the AS wants to_device messages (and maybe this could actually be useful for an AS to be able to subscribe to to_device message without getting presence, etc?)

[richvdh]

indeed, maybe we should have separate settings for each of presence, typing, device lists, etc?

[turt2live]

In my opinion a filter would be best suited for a future MSC. Appservices already don't have an option to filter what events (PDUs) they receive, but it would be great if they could.

"Ephemeral" here is also inherited from the server-server API rather than client-server API: it includes to-device messages, but changes shape to be more useful as a representation. We could absolutely package it into ephemeral, but appservices will already be translating it to fit their crypto engine shape anyways - might as well give them something directly compatible.

Overall, appservices being closer to federation than clients makes things weird. We should improve them, but I don't think this is the MSC to fix everything.

[richvdh]

please can to_device be mentioned here (and probably in the example), rather than introduced as a plot twist halfway through the description (which I assumed until then was going to be all about ephemeral)?

Alternatively, introduce the two arrays as separate changes with their own sections in the MSC.

Edit: oh, this has already been mentioned below

[richvdh]

Please be explicit about exactly what sort of events are included in ephemeral. AIUI, it's typing and presence? Or are there more? Read receipts? Device lists? Account data?

[richvdh]

Suggested change

	MAY be omitted entirely if there are ephemeral no events to send.
	MAY be omitted entirely if there are no ephemeral events to send.

[richvdh]

indeed, maybe we should have separate settings for each of presence, typing, device lists, etc?

[richvdh]

you'd need a name for the property that contains the inner object

[richvdh]

This doesn't appear to be the case, based on the example above. For example, the C-S API puts typing notifications under the corresponding room, so doesn't need a separate room_id key in the m.typing notification itself.

I'm not really sure what the word "otherwise" is doing in this sentence.

Please be explicit about exactly what format each type of event should use.

[richvdh]

Suggested change

	A complete example of the transaction with all 3 arrays populated would be:
	A complete example of a transaction with all 3 arrays populated would be:

[richvdh]

Strongly recommend writing explicit rules for each type of event, rather than handwaving about EDUs in general.

(Also, note again that EDUs don't exist as a concept at all outside the federation API)

[richvdh]

Suggested change

	The homeserver needs to accuratley determine which EDUs to send to the appservice, as to not leak
	The homeserver needs to accurately determine which EDUs to send to the appservice, as to not leak

[richvdh]

The same is true of to-device messages?

[richvdh]

This seems to assume that a client somewhere is /syncing with the same device ID as the appservice? And both devices want to receive the to-device message?

I'll note that this does not yet seem to be implemented (element-hq/synapse#11423). Maybe that's ok since this is not a normative part of the MSC, but I'm a bit troubled that this is left undefined.

[richvdh]

I don't really understand why we can only delete messages for users under an appservice's exclusive namespace. There's probably some explanation somewhere in the depths of matrix-org/synapse#10653, but it needs explaining here imho

[Half-Shot]

Just for explicitness: I'm happy to shepherd this MSC.

[turt2live]

Canceling FCP while this remains a work in progress.

@mscbot fcp cancel