matrix-spec-proposals
matrix-spec-proposals copied to clipboard
matrix-org
MSC2409: Proposal to send EDUs to appservices
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
- https://github.com/matrix-org/synapse/pull/8437
- https://github.com/matrix-org/synapse/pull/11215
Signed-off-by: Sorunome [email protected]
bumping this up as it would help out of a ton of mx-puppet-slack users! :)
I really miss this while using mx-puppet-discord. Typing notifications add so much extra value to a chat!
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.
@auscompgeek would be even better if appservices could add a filter to their registration data to filter out anything they don't care about.
@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 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.
@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?
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.
Implementing backend at https://github.com/matrix-org/synapse/pull/8437 (available in 1.22.0) Implementing bridge side at https://github.com/matrix-org/matrix-appservice-node/pull/32 (available in 0.6.0)
mautrix-python impl: https://github.com/tulir/mautrix-python/commit/ee74e1706fc9d223b72c50ad5b40b949840be7c8
@turt2live it would be good to have a statement from the SCT on why it needs an implementation. If the Synapse / appservice portions aren't complete enough, it would be good to understand why.
From my PoV while there are concerns with performance, we're running this change across multiple customer servers and some large public ones and the Synapse team are still making incremental changes to the performance of the code. I don't think there has been an opinion that the spec mandates behaviour that would make for a slow or flawed implementation.
So yeah, would be good to know what's outstanding here.
This MSC gained the label because the implementation is not linked in the PR description.
From my perspective, the implementation is incomplete due to the performance issues and fact that it didn't try to send all the EDUs to the appservice, such as device list changes. I believe the latter of this is currently underway, but the former makes it very difficult to prove that this MSC works in practice if everyone is required to disable it once a small amount of traffic passes over the connection - this isn't to say it needs to be safe to enable on the likes of the Old Freenode bridge, but it should be possible for large bridges to turn it on and prove it works. It's a similar requirement that encrypted appservices will face in time.
This MSC gained the label because the implementation is not linked in the PR description.
Sorted. I think I had glanced over this because I thought Soru needed to do it, but in practise I can ~~ab~~use my matrix-org creds to update the list
From my perspective, the implementation is incomplete due to the performance issues and fact that it didn't try to send all the EDUs to the appservice, such as device list changes.
That's fair, I avoided the device updates in the initial Synapse PR to avoid spending ages on complexity I didn't need at the time. It seems entirely proper to wait for that work to land before considering it complete, especially as devices carry a much more complex architecture than a typing update.
but the former makes it very difficult to prove that this MSC works in practice if everyone is required to disable it once a small amount of traffic passes over the connection - this isn't to say it needs to be safe to enable on the likes of the Old Freenode bridge, but it should be possible for large bridges to turn it on and prove it works.
I'm more mixed on this. I believe the current performance problems lie in existing old homeservers turning on EDU support on bridges, rather than N traffic being the problem. This is why we turned off support on the OFTC matrix.org bridge, but have been running the libera.chat bridge with EDUs turned on from day one. That being said, I don't have numbers on the libera.chats raw processing metrics for edu transactions, probably something we should have. Either way, I think that once the performance issues get addressed for existing older HSes, we can re-evaluate the MSC.
hello, what is the status of this feature: can we receive typing events in the Application Service ?
Status updates are best asked in #sct-office:matrix.org so we can better provide an answer.
Currently, this MSC could do with a champion to bring it through the process.
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 (
typev.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.
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 🤔
I don't think it's worth trying to rewrite the world, let's just fix the proposal.
This FCP proposal has been cancelled by https://github.com/matrix-org/matrix-spec-proposals/pull/2409#issuecomment-2071316566.
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.
