Modern XMPP project discussion - 2025-08-06

> I've been driving Dino as the main one. What's the better alternative here? I've got KDE on the desktop, GNOME on the laptop. Interesting. Never thought of using a different DE on a different form factor. ↺

Oh and we also forgot the Thunderbird, a mail client that also has some XMPP chat. And this makes it probably the most widely available client. I also recently remember that there is Jitsi Desktop app written in Java that has XMPP support. But it's so outdated so that it still has the ICQ support. I'll check if it can be fixed and used.

I don't think Thunderbird supports OMEMO though. That's something to keep in mind

If you talking on own server i.e. company or family server on OpenWrt router then you don't really need for the OMEMO. It has OTR anyway

The OTR is supported on Psi and Pidgin but from mobile clients only the aTalk seems to support it

I think that adding the OMEMO and other essential features would be not complicated for the Thuderbird. Then it may easily become the most used XMPP client

> I've been driving Dino as the main one. What's the better alternative here? I've got KDE on the desktop, GNOME on the laptop. The saddest part is there is no better alternative. ↺

> I don't think Thunderbird supports OMEMO though. That's something to keep in mind I don't think Thunderbird supports anything that defines a modern messenger ↺

kurisu, are you proposing anything to be done or doing anything yourself? or is your plan to just complain and bikeshed about everything all day every day?

i see you across several xmpp related mucs, and i dont ever see you offer anything useful, you just shoot down suggestions and complain that everything sucks.... which helps no one

On a more constructive note, I wonder what it *will* take to implement OMEMO in Thunderbird? I'd be willing to put up with a lack of extra features if I can have all my communication in one app

And the other features can probably be added by and by (not sure what exactly the status is but I'm guessing it doesn't have reactions and stuff that came out in other clients relatively recently)

TB OMEMO feature request was asked ten years ago https://bugzilla.mozilla.org/show_bug.cgi?id=1237416 I guess this is more a question of the TB team priorities. All libraries are available.

> On a more constructive note, I wonder what it *will* take to implement OMEMO in Thunderbird? I'd be willing to put up with a lack of extra features if I can have all my communication in one app Someone that wants, is capable of and is willing to spend time on it for free. Or someone that is willing to spend money on it. In 10 years neither showed up. ↺

> added $50 to the bounty, Must be any day now.

I may try to contribute to the TB but for some simpler things e.g. registration. But I'll get to this later. Sources of the chat module https://hg-edge.mozilla.org/comm-central/file/tip/chat Insructions on how to build it https://developer.thunderbird.net/thunderbird-development/building-thunderbird/linux-build-prerequisites

> Someone that wants, is capable of and is willing to spend time on it for free. > Or someone that is willing to spend money on it. > In 10 years neither showed up. i repeat, do you have anything to offer other than bitching and moaning aimlessly? ↺

> On a more constructive note, I wonder what it *will* take to implement OMEMO in Thunderbird? I'd be willing to put up with a lack of extra features if I can have all my communication in one app Afaik it is just an javascript app running in an cut down browser kind of deal. The best bet is probably to replace the backend with some modern xmpp JS library entirely. ↺

I have a proposal: here we all can make a small but valuable contribution: we need to add doap file for clients that doesn't have it. The doap file describes supported XEPs and platforms. This will make it easier for users to compare clients. The xmpp.org collects the doap files and shows them on client page when clicked on Show supported XEPs button. This is a task on one or two evenings for one client. I'll start doing this on a weekend, will start from the Spark client, then will try the Thunderbird. The https://xmpp.org/software page has Other software list with all such clients without a doap. If anyone will aslo help with the task please let me know which client you'll add

> Afaik it is just an javascript app running in an cut down browser kind of deal. The best bet is probably to replace the backend with some modern xmpp JS library entirely. Interesting I didn't know that ↺

> PLAIN, SCRAM-* etc -> password auth > EXTERNAL -> certificate auth > OAUTHBEARER -> login with OAuth2/OIDC (per XEP-0493) Zash: XEP-0493 seems concerned with letting the XMPP server be used as an authorization provider. From the XEP: > It allows a resource owner (such as an XMPP user) to safely and securely grant address to a resource (such as their XMPP account) to software and services that they choose. "Log in with Codeberg" is the opposite, Codeberg is the authorization provider, not the XMPP server. So to me it looks wrong to say that use-case is covered by XEP-0493, unless I'm missing something.

I'm very much interested in adding OAuth2 "Log in with XYX" to Converse. I looked at mod_auth_oauth_external but quite frankly got confused as to how it's supposed to work.

Sure is complicated because you have to register an OAuth2 client with XYZ

> I'm very much interested in adding OAuth2 "Log in with XYX" to Converse. > > I looked at mod_auth_oauth_external but quite frankly got confused as to how it's supposed to work. It passes through the auth request ↺

The XMPP server acting the identity provider makes easier since it can support dynamic registration

> Sure is complicated because you have to register an OAuth2 client with XYZ That just means going to xyz.com and setting up a developer account and registering the client. I've done that before.

> The XMPP server acting the identity provider makes easier since it can support dynamic registration Ok, but that doesn't let you log in with Codeberg etc. Rigth?

I added OAuth2 support to Converse some years back with hello.js (sending tokens over PLAIN) and it used to work but bitrot has set in

Here's the Prosody module I wrote for it back then: https://modules.prosody.im/mod_auth_oauthbearer.html

> > The XMPP server acting the identity provider makes easier since it can support dynamic registration > > Ok, but that doesn't let you log in with Codeberg etc. Rigth? No. Not unless the server does some sort of delegation I guess ↺

Yes, so XEP-0493 is the opposite case of "log in with Codeberg" (it would be adding "Log in with XMPP" to Codeberg)

I don't think it matters from the client perspective. You get a reference to an IdP and talk to it, get a token, continue with SASL OAUTHBEARER

And does `mod_auth_oauth_external` give you this reference to the IdP?

Yes

Looks like it's tied to a single IdP, right? Can you have multiple ones and let the user choose?

Just, if the IdP doesn't support dynamic registration, it gets complicated

I'd suggest picking an IdP that supports delegating to other IdP if you want that

Those exist?

Yes

At $work we use Dex which is the thing that you get a token from, but you actually authenticate to another provider.

Kris linked another thing. I think KeyCloak can also do it?

You (I assume it's you) mention in the `mod_auth_oauth_external` docs that you tested it against Mastodon and KeyCload, do you have an example config for this that I could look at?

The main problem is that without dynamic client registration it doesn't really work in an open federated environment, if every client (read: every installation) has to go create a developer account and set up stuff manually

Isn't there an example on the page?

I'm not too worried about that. I can register https://chat.conversejs.org for this. Yes it doesn't work for self-hosters, but at least people can try it out quickly...

Mastodon actually supports dynamic client registration, but in a non-standard way

> but in a non-standard way So fairly typical for Mastodon?

oauth_external_token_endpoint = "https://fosstodon.org/oauth/token" oauth_external_validation_endpoint = "https://fosstodon.org/api/v1/accounts/verify_credentials" oauth_external_username_field = "username" oauth_external_scope = "read:accounts"

Thanks 🙂

https://docs.joinmastodon.org/client/token/#app

> At $work we use Dex which is the thing that you get a token from, but you actually authenticate to another provider. 👍 ↺

I think to make that work, the server would also need an additional way to verify with the external Idp, no?

I know from Ergo ircd that they somehow pass a token to the server and that one then independently also talks to the idp.

I don't think this is currently supported by the prosody modules

The oauth external rather proxies the auth request and thus is directly verifying the auth itself.

It has two modes, one involves the client fetching a token and the server verifying the token. The other is password auth and then the server uses that to fetch a token, then verifying the token.

jc, using https://modules.prosody.im/mod_http_oauth2.html would be closer to XEP-0493 tho. I think it's mostly missing the scopes from the XEP