Add ejabberd as Matrix server #2780
Conversation
|
Thank you so much for this PR! Super excited about Matrix support in ejabberd. (Deferring to our Website WG on the review here.) |
|
Note: ejabberd 24.02 has started the Matrix support:
Matrix gateway setup with ejabberd:
Understanding messaging protocols: XMPP and Matrix: |
|
🎩 Website & Content WG We are very excited about this (you can find it in TWIM back around the initial support announced in Feb '24)! Before I make any suggestions, I need to know: Do I understand correctly that ejabberd implements (only) what it calls a Matrix gateway, i.e. pretty much the Matrix Server-Server API, plus some ways to map XMPP primitives to Matrix (e.g. user IDs)? Specifically, you would still be using an XMPP client to access the Matrix federation? Am I missing any aspects here? |
No, that's pretty much what makes it interesting. One client for two protocols, but the server provides an XMPP component (internally) that works as a gateway to Matrix federation and the client is unaware. That means there's a way to just use Matrix (indirectly) using any XMPP client, simply by using ejabberd. Little bit buggy, as it is alpha-grade, but otherwise works well.
Not just that. It can also be configured to first try XMPP and fall back to Matrix if an ID cannot be used to reach an XMPP server. That way it is transparent without using gateway syntax like This just requires blocking matrix.org for XMPP, as DNS SRV records for matrix.org say there is an XMPP host on lethe.matrix.org, for some reason, causing it to fail. The other mode is what they call implicit routing. Anyway, works well. Helps me, personally, with using Linux phones until there are Matrix clients for Linux phones that work for my use-case. |
|
Really cannot say anything bad. It's still an early implementation, but given how early it is, it works really really well. |
That matches my understanding -- the only part of Matrix it implements is the Server-Server API. This does include some interesting bits like state resolution, but it isn't really a Matrix server if you're trying to use a Matrix client. |
Well, it speaks the Matrix protocol to other servers, just not to clients. Maybe they'll add that in the future, I don't know what their plans are. In any case, it serves Matrix. And keep in mind that it is a really early implementation, I'm pretty sure they're at least planning to improve it a lot. I'd like to see the reverse as well, Matrix servers that also do XMPP. I really want to see the gap closed. |
This is pretty much what my comment said.
I'm not trying to minimize what it does, just answering factually the current capabilities. |
|
🎩 Website & Content WG Thank you, @clokep for what I take as confirmation of my understanding with an SCT member lense. To summarise, this PR suggest adding ejabberd to our list of server projects with alpha maturity. Still, I am wary of adding it straight to the servers list. Our page itself uses both terms "server" and the more specific "homeserver" in its description. We believe that a reasonable expectation to a Matrix server is that you can connect to it using a Matrix client, and thus ejabberd is currently not a Matrix server, as much as a Matrix server with the Bifrost XMPP bridge attached is not an XMPP server. If you want to get technical, while not defining it here, we can learn more in our /docs and in the spec, where under Architecture it says "Clients [...] communicate [...] with their “homeserver” using the “Client-Server API”". In other words, C2S API seems to be formally defined as a requirement for a homeserver. That said, I think this is a matter of finding (or creating) the appropriate category on the website to fit this in. A natural first thought leads us to the bridges page, as I consider it, I am not convinced of this either, because it is not a component connecting Matrix to another platform, but instead a component (or actually monolith) connecting another platform to Matrix. Does anyone else have a reasonable idea? I am happy to add it to my private project (https://github.com/HarHarLinks/tune-your-chat/blob/tune-your-chat/content/ecosystem/tune/tune.toml) but that is much more a dumping ground with some effort to filter while the matrix.org homepage should have some higher quality standards. Regardless, even there I struggle to categorise ejabberd, short of creating new tags. Perhaps we introduce a page of "other things that federate with Matrix"? That could also host rocket.chat, for example. I am looking forward to your suggestions and opinions. Assuming we find a reasonable way forward: The following is not written policy yet, but I hope everyone can agree that usually the reasonable next step would be to ask the actual maintainers to confirm they want their project listed and advertised here. I think while in this case the implementation is backed by a reasonably large organisation, I would say this is still relevant given the feature is experimental, and the influx will be people with matrix expectations, not people with XMPP expectations who also want to try out a matrix gateway. |
|
Yeah, it does seem that we're seeing a new category emerge in what I might describe as Matrix-compatible servers. I'm all for creating a category to recognize these important parts of the ecosystem in a way that meets expectations of folks browsing this section of the website. |
|
Maybe @tulir as a bridge expert might have a thought on where this goes? |
That was my reasoning as well. Would have chosen
Yes, but there is currently no field where I could add
Well, Bifrost only speaks the XMPP component protocol (XEP-0114), so it is indeed not an XMPP server, it is just a component, similar to how appservices as those are the Matrix equivalent of an XMPP component.
This is exactly why I'd like to just add a note that says something like "this speaks Matrix to other Matrix servers, but is not a homeserver" to not mislead. Could we add such a "please note" field? Maybe we could also divide the server category into
Rocket.Chat docs just mention setting up Synapse and connecting Rocket.Chat via the appservice API, therefore the correct category for Rocket.Chat Matrix Support would be |
I've let them know that a comment in this issue would be appreciated. |
My oberservation so far has been: Mostly XMPP users enable Matrix supoort because their server supports it now and they use it with the clients they are used to, so it feels natural. |
I think bridges would be the most appropriate location, because the main purpose of ejabberd (from matrix.org's point of view) is connecting to Matrix from XMPP or vice versa. If you wanted to find a way to do that, you'd go to the bridges page, not homeservers. People going to the homeservers page most likely want a server that can serve their Matrix client. Also, nobody said bridges must always use the appservice API, making a server-server bridge is a perfectly valid choice too, it has even been documented in https://matrix.org/docs/older/types-of-bridging/ (but at the time those docs were written, nobody had written such a bridge)
Rocket.Chat is working on a built-in federation implementation, so it'll be very similar to ejabberd after that https://github.com/rocketchat/homeserver |
It's not about connecting XMPP to Matrix and it does not bridge. It gives you access, but does not allow users on any XMPP server to join a Matrix room. It does not bridge the network, it only allows participating in Matrix conversations. At least the term bridge does not fit. "matrix-compatible server" ≠ "Matrix server" ≠ "Bridge" It does not fit the categories. But bridges is the one leadt fitting, I'd just add it as a server with note that it technically is one, but only to other servers and does not act as a |
Offtopic, this has nothing to do with the Merge Request. It is not even the correct repo. |
|
Hello, just wanted to ask where we are now with discussing this MR, I still tink it'd be neat to have this server implementation listed. :) As @bluesomewhere said:
|
|
It is strange because @matrix-org team knows ejabberd, it has been cited in the recent vulnerabilities announcement: And I have already published on Reddit, and for example recently: |
Again. Please stop spamming the issue. |
6 participants
ejabberd supports Matrix now, support is alpha-grade. This is neat as it removes the need for bridges for those that need XMPP in addition to Matrix.