Modern XMPP project discussion - 2026-02-18

Hello, nice to meet yall.

welcome

Trying to get back into XMPP development after years of making the mistake of using Discord as a primary chat platform

cool

Discovered the Modern XMPP website on the xmpp.org links

any specific plans?

Yes

I have friends who are Discord reverse engineers and friends who are making their own XMPP client/server from scratch.

We've been discussing with each other and came up with an idea to make new XEPs to port the reverse engineered Discord server architecture to XMPP as a backend.

That sounds like a bad idea, existing clients and especially servers are built on decades of experience, it’d be much simpler to add the specific things you’re missing into them, rather than start from scratch.

That is actually the idea

Good. :)

As a server developer I definitely agree, and would be happy to provide help and advice to anyone working on this

The reverse engineered Discord API is called Spacebar chat/Fermi.chat

My friends and I want to help port it to XMPP as a server backend by making as many XEPs as needed to make everything talk.

That way the reverse engineered Discord APIs features get ported to XMPP as a whole so any client can implement them.

And the existing Spacebar servers can gain federation from the existing XMPP network.

Win win

It would also mean all the software written for Discord would work with XMPP too instead of burning with Discords recent self sabotage

I've already been doing initial investigations on what existing XEPs could be leveraged to stitch this protocol extension together

you could probably write an adapter of some sort for spacebar to talk to an existing xmpp server via the "component" connection

Rocketchat did something similar for a while to add matrix support via the "appservice" interface of a matrix server

Yes, that's what I suspected

The idea is that Spacebar has only two reference servers, I want to add every XMPP server that is willing to participate to that list of hosts. ✏

Here, take a look: https://fermi.chat/

I want to be able to make my future self hosted XMPP server meet the 'Spacebar-Compatible Instances' definition to act as a host for Fermi.chat and other open source Discord clients.

> Rocketchat did something similar for a while to add matrix support via the "appservice" interface of a matrix server Yeah, one of the main Spacebar developers is more interested in Matrix as a potential backend than XMPP. I had to explain why XMPP was the better option by demonstrating what the X in XMPP means.

I may be biased, but I do believe XMPP is a better fit for such a project

Now we got a crowd of people who wanna make this protocol merger happen.

MattJ: would you like to share contacts? I'd like to learn more about XMPP server development from you and everyone here.

If you have any questions you can definitely post them here and that way anyone can reply rather than only one person seeing them

Definitely, I will be trying to bring others over to this channel too so there are morr hands on the project than just me. ✏

Douglas Terabyte, the fermi.chat seems to be only a webclient. what is that other Spacebar chat server you are referring to?

a quick search only came up with this: https://github.com/spacebarchat/server

I was about to link the server repository here

You got it

so no other server implementation?

that one seems a bit of a mess

Yeah, which is why I considered making another viable server implementation based on XMPP.

I will self host a Spacebar server myself for now, but would rather just merge the protocol reference into XMPP and self host an XMPP server.

well it is probably easier to use the existing spacebar server software and just add XMPP federation to it via a xmpp library for Typescript that supports xmpp components (maybe xmpp.js) and use that to link it to a Prosody server or so

but it will be a mess to host

and if you rewrite everything, honestly, why not just write an XMPP client that looks like Discord and avoid all that unecessary Spacebar stuff?

the Ejabberd people recently started coding a Discord looking xmpp client, and apparently it is half decent already: https://www.process-one.net/blog/introducing-fluux-messenger-a-modern-xmpp-client-born-from-a-holiday-coding-session/

you could probably write an Prosody or Ejabberd extension that exposes a Discord like bot API, if that is what you want to keep API compatibility with.

All good ideas and I will share them, but the idea is to get these two protocols to converge rather than fragment further into clones of clones that don't speak to each other. ✏

> and if you rewrite everything, honestly, why not just write an XMPP client that looks like Discord and avoid all that unecessary Spacebar stuff? My friend is already doing that too, I am about to invite him here

> the Ejabberd people recently started coding a Discord looking xmpp client, and apparently it is half decent already: https://www.process-one.net/blog/introducing-fluux-messenger-a-modern-xmpp-client-born-from-a-holiday-coding-session/ The Spacebar chat devs are not happy with the use of AI generated code.

But I am getting a positive response about collaboration with XMPP from the Spacebar userbase

Main dev really doesn't like XML and wants to be able to use JSON

I shared https://xmpp.org/extensions/xep-0335.html https://xmpp.org/extensions/xep-0432.html with them.

there are some libraries that hide away all the XML stuff and allow talking to them via json I think

but XML is actually better for non-web things 😅

> > the Ejabberd people recently started coding a Discord looking xmpp client, and apparently it is half decent already: https://www.process-one.net/blog/introducing-fluux-messenger-a-modern-xmpp-client-born-from-a-holiday-coding-session/ > > The Spacebar chat devs are not happy with the use of AI generated code. yeah, that they used AI to code that Fluux messenger is a bit concerning, but it isn't fully vibe coded. ↺

Yeah there's a stark difference between AI in the hands of a seasoned dev and just some random noob vibe coding something

I'm going to be somewhat busy for the next 4-5 days, but I'm working on an XMPP 'client' - might be more apt to call it a backend

Using Lua and sockets with a socket multiplexer Stated goal: - Allow arbitrary programs to interact with XEPs or act as XEPs - Break out valid XMPP XML generation by XEP - Support frontend applications by giving them sockets to plug into - XMPP in the back, arbitrary (desired) data in the front, GUI frontmost

And do TLS and security via third party socketed programs - encryption without binding it to program logic, which means controlled side effects and problems

I'm using socat or a socat-like for TLS already.

I have nothing special right now, just socat and a direct XML input mechanism that remembers closing tags for you (Empty LF closes tag)

STARTTLS, not sure if I need to do double TLS negotiation (initial TLS and then a nested TLS inside that) - I think I do

But once I get that rolling I can move right into implementing all the little things

I would drop starttls for a new implementation, just use direct tls

Unless you really need it to work with every server

If I get back a STARTTLS required do I have to use it if the connection is already TLS?

No, you won't get it requested by the server if you're already using it

Hm. Alright. Is there a specific port expecting TLS vice the normal port? I was a little unclear on that in the spec. ✏

Or should it just see TLS and go 'yep'?

It is a bit unclear right now, unfortunately. There are two options, in order of preference: 1) query for _xmpps-client SRV records in DNS, which will tell you the port to use, 2) try port 5223 which is the most common port for direct TLS

I've been reading off the RFC so you guys probably have some good insights like this. It's good stuff.

I'll add 'poke DNS' to the initial routine.

The RFC is certainly good reading, but it is a little old at this point and there are some rough plans to start work on a new RFC which would replace it, and update things like TLS

So in order of precedence: - Query DNS - Direct TLS @ 5223 - STARTTLS P.S. Check if getting STARTTLS required on already-TLS connection?

You won't get starttls required on an already-TLS connection

Yeah, STARTTLS is literally "connect and then start TLS", so... yeah. That's where the name comes from.

STARTTLS is a command to say "I want to start TLS now". It was used when TLS was newer and optional, and allowed easily reusing traditionally plaintext ports and upgrading them to TLS

Now TLS is basically mandatory everywhere, and we have SNI everywhere, it's less useful

I would expect that, yeah. I need to do some inspecting to see packets fly and come back from that hopefully screwed on straight

I'm using socat TLS:<address, port> but getting STARTTLS required.

I have an interesting issue regarding MUC configuration in Modern XMPP

https://github.com/movim/movim/issues/1516

And I can't figure out what setting I actually missed in https://docs.modernxmpp.org/client/groupchat/

Got a basic repo up to hack into. https://git.unix.dog/kohrokho/Dragon-PP

distaza, reminds me of https://23.fi/jj/ ✏

Ah, yep! I recognize that one. Very similar premise, just trying to break it up so that when inevitable dependency churn happens the core is not only OK, but hotplugged and running

Also why I'm trying to break out even the frontend + backend - I want socket data to be the interface and the data structures to be a program cross translation of XML - think a reversible generic or specific translator you can plug in and out

XML one side, function, arbitrary structured data pops out the other side ✏

FS interface can just be dynamic socket tracking

where you send a SIGUSR1 / SIGUSR2 to the multiplexer of a socket and it pops open a socket for you, you attach to it and install the other end in a FS hierarchy

Socket multiplexer is my next simple component to slap together. It does the hard part - making a shared data bus along the Unixy filter graph, like tee but oops, all sockets

so you have a hydra of sockets you can add / remove heads from as needed

Not solidified on exactly what signals, but one will sweep up all unused sockets, the other will grow a new 'head'

The multiplexing is very simple too - if you want advanced filtering you can do that by just having children be picky about sockets, no need to muck up the muxer with logic

edhelas: there is a setting to allow members to invite new members. IIRC the XEP is weird and Prosody and ejabberd have different names for the config field (I think we decided that they actually both behave the same and the XEP should be updated). Anyway, it seems like that's what you want.

Yes I played with that but it doesn't seems to work, both on Prosody and ejabberd

What happens?

``` <message xmlns="jabber:client" to="test-movim@chat.jabberfr.org" type="chat" id="fdc863df-54fe-473a-a32b-5ad8f51fddb6"><x xmlns="http://jabber.org/protocol/muc#user"><invite to="gnap@movim.eu"/></x></message> <message id='fdc863df-54fe-473a-a32b-5ad8f51fddb6' to='edhelas@jabber.fr/Movim.xTmCZ1~a5h7hgVTOoiH' type='error' from='test-movim@chat.jabberfr.org'><error type='cancel'><service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/></error></message> ```

With {http://prosody.im/protocol/muc}roomconfig_allowmemberinvites to true

(but its late, I'm maybe doing something wrong, going to bed and I'll have a look at this tomorrow again :))

Maybe remove the type=chat, but I'm not sure

Ping me tomorrow if you don't get it working

MattJ https://github.com/movim/movim/commit/2379bfd35c605d94a733150b8cbd935c74b44e99

Looks like that was it indeed

https://xmpp.org/extensions/xep-0045.html#invite-mediated

Today I learn that a type is not mandatory in <message/>

It defaults to "normal"