Modern XMPP project discussion - 2026-02-22

MattJ understandable, I am trying to get the devs here preferably

Kris: i will forward this to them

> For those that don't have the context, Spacebar is a free, open source, and self-hostable software that is being written to attempt to 1:1 reverse engineering of Discord's protocol and API. Please consider joining and assisting in development. I am currently trying to assist the main dev set up a Prosody server so that the main Spacebar server can be eventually be peered with the XMPP network. Here is the Discord server link where we are currently holding the group voice call. > https://discord.gg/xmfAepRKzP just curious, how much is this work shared between other private reverse engineered servers like hummus'? ↺

> I got the Spacebar main dev to agree to host their oen XMPP server on their domain thats huge ↺

>> For those that don't have the context, Spacebar is a free, open source, and self-hostable software that is being written to attempt to 1:1 reverse engineering of Discord's protocol and API. Please consider joining and assisting in development. I am currently trying to assist the main dev set up a Prosody server so that the main Spacebar server can be eventually be peered with the XMPP network. Here is the Discord server link where we are currently holding the group voice call. >> https://discord.gg/xmfAepRKzP > > just curious, how much is this work shared between other private reverse engineered servers like hummus'? I do not know what 'hummus' is, cal you elaborate, svp ? As far as I know, Spacebar is the only project I know of trying a 1:1 reverse engineer of Discord. If there are others I am unaware of, please let me know and I will try and connect them all together.

>> I got the Spacebar main dev to agree to host their oen XMPP server on their domain > > thats huge Task failed successfully... Main devs website went down trying to get Prosody set up with a reverse proxy and gave up for now. XMPP documentation for setting up servers NEEDS to be more accessable.

And correct

Nginx config broke on the XEP page

Who maintains that?

> >> For those that don't have the context, Spacebar is a free, open source, and self-hostable software that is being written to attempt to 1:1 reverse engineering of Discord's protocol and API. Please consider joining and assisting in development. I am currently trying to assist the main dev set up a Prosody server so that the main Spacebar server can be eventually be peered with the XMPP network. Here is the Discord server link where we are currently holding the group voice call. > >> https://discord.gg/xmfAepRKzP > > > > just curious, how much is this work shared between other private reverse engineered servers like hummus'? > I do not know what 'hummus' is, cal you elaborate, svp ? As far as I know, Spacebar is the only project I know of trying a 1:1 reverse engineer of Discord. If there are others I am unaware of, please let me know and I will try and connect them all together. basically a 2018-era discord "fork" that runs their own server, might be of help but i cant seem to find too much info about it outside the webclient on sys42... ↺

Douglas Terabyte: do you know why there is motivation to federate Spacebar with XMPP?

Douglas Terabyte: The ngnix part of proxying prosody http stuff is the same as if you proxy anything. If you find whats confusing for you don't heistste to tell at the prosody channel so it can be improved

>> I do not know what 'hummus' is, cal you elaborate, svp ? As far as I know, Spacebar is the only project I know of trying a 1:1 reverse engineer of Discord. If there are others I am unaware of, please let me know and I will try and connect them all together. > basically a 2018-era discord "fork" that runs their own server, might be of help but i cant seem to find too much info about it outside the webclient on sys42... If you can find it and link it to me, I will share it with the Spacebar Devs

> Douglas Terabyte: do you know why there is motivation to federate Spacebar with XMPP? Motivation, or reason? ↺

Probably the same thing in this context

>> Douglas Terabyte: do you know why there is motivation to federate Spacebar with XMPP? > > Motivation, or reason? Because Discord's API does not have the ability to federate with itself, so every Spacebar server (only two main instances right now) cannot talk to each other. I have personally discussed with Cryptography specialists on Telegram, Spacebar devs on Discord, and XMPP devs here about the possibility of running Spacebar's server and API as an extension on top of XMPP and gotten positive response from all three communities. ✏

Hi, I'm people

https://lucidragons.de/blog/2026/2026_02_20_loving_xmpp.md

People have told me if XMPP had the UI and features of Discord and Spacebar had the federation and extensions of XMPP they would self host it immediately. ✏

If you are developing XMPP (you intend to use and support it), you have to be inherently motivated, the same way that if I want to be a FreeBSD or Linux developer, or work on VR, I need to be inherently motivated. That's the difference between reccommending or liking something and developing it. There are *reasons* to federate. There are also reasons to approach feature parity. Motivation? We're *it.* If we all drop XMPP for Facebook, no one will be 'motivated'. That's why I'm being pinged on my weekend to help the Spacebar guys learn about XMPP. That's why I'm writing a Unix socket multiplexer.

luci: hi luci, thanks for popping in :3

Luci is a friend from Saotoks gang of cryptography fans who showed an interest in Spacebar and XMPP merging

> >> I do not know what 'hummus' is, cal you elaborate, svp ? As far as I know, Spacebar is the only project I know of trying a 1:1 reverse engineer of Discord. If there are others I am unaware of, please let me know and I will try and connect them all together. > > basically a 2018-era discord "fork" that runs their own server, might be of help but i cant seem to find too much info about it outside the webclient on sys42... > If you can find it and link it to me, I will share it with the Spacebar Devs https://hummus.sys42.net ↺

You need to be motivated on your own. I can only give you reasons to supplement it. Our purpose to experiment is in the MUC subject line.

I am

>> If you can find it and link it to me, I will share it with the Spacebar Devs > https://hummus.sys42.net This gives me a login prompt but no repositories and I can't seem to reach the top level domain.

> If you are developing XMPP (you intend to use and support it), you have to be inherently motivated, the same way that if I want to be a FreeBSD or Linux developer, or work on VR, I need to be inherently motivated. That's the difference between reccommending or liking something and developing it. > > There are *reasons* to federate. There are also reasons to approach feature parity. Motivation? We're *it.* > If we all drop XMPP for Facebook, no one will be 'motivated'. > > That's why I'm being pinged on my weekend to help the Spacebar guys learn about XMPP. That's why I'm writing a Unix socket multiplexer. "Motivation" in the context of stratself's message means desire or reason. ↺

yeah as i said i havent been able to find too much about it but i know it exists thanks to a mutual the author and i have, i'll see if i can ask for a contact instead...

> People have told me if XMPP had the UI and features of Discord and Spacebar had the federation and extensions of XMPP they would self host it immediately. I guess I'm just not understanding what the point of this additional complexity is vs just creating a native XMPP client with Discord-like UX ↺

Like again all of the building blocks are there from a technical standpoint for an XMPP client with voice channels and whatnot. It's just a matter of actually creating the UI.

Spacebar is compatible with existing Discord bots I guess but rebuilding them for XMPP (which has various decent libraries for such things) would likely be a lot less work than trying to duct tape Spacebar and XMPP together

Desire and reason should not be conflated, but I can still supply answers. Creating a proper translation means gaining the ability to transplant Discord data into XMPP. Migration. If you can't think of a reason to migrate users and their communities to XMPP, you can practice that belief by dropping XMPP and going to Discord.

I desire it, and so does Spacebar.

> yeah as i said i havent been able to find too much about it but i know it exists thanks to a mutual the author and i have, i'll see if i can ask for a contact instead... svp: please do, I would appreciate the help on outreach :3

distaza: words can have different meanings depending on context. Anyway not sure why that's a battle you're picking. > Creating a proper translation means gaining the ability to transplant Discord data into XMPP. Migration. Creating a simple script that dumps Discord/Spacebar data and converts it to XMPP data would be nothing compared to making Spacebar federate via XMPP. If the former is the main desire, the latter would be extreme overkill.

If you think so, sounds like a plan. You wanna do it, or is it a recommendation?

I mean I have no use for Discord data 😄

> Whatever is needed to make this work, please assist

Well, I'll do *both*, then. :p

I like overkill. They have a saying about it.

If you don't agree, that's fine. You won't be using it or working on it, even though you're still here?

> > yeah as i said i havent been able to find too much about it but i know it exists thanks to a mutual the author and i have, i'll see if i can ask for a contact instead... > svp: please do, I would appreciate the help on outreach :3 unsure if you received the channel PM i sent ↺

Big Mike: Is there something you would like to see worked on with XMPP, in particular, perhaps something you're fiddling with yourself? ✏

Apologies for any typos, this is a touch device. Not my preferred input mode.

I wonder how everyone ended up in this channel and not in xmpp:jdev@muc.xmpp.org?join 🙂

> I wonder how everyone ended up in this channel and not in xmpp:jdev@muc.xmpp.org?join 🙂 OwO what is this

*joins*

> I guess I'm just not understanding what the point of this additional complexity is vs just creating a native XMPP client with Discord-like UX Seconded, honestly... I'm currently trying out Mov.im, and it actually looks fairly close to being a good alternative, but it was also built ground-up to interface with XMPP ↺

> I wonder how everyone ended up in this channel and not in xmpp:jdev@muc.xmpp.org?join 🙂 More seriously, because both channels are relevant. Thank you for providing an additional communication channel for me to speak with.

Movim has similar goals with Spacebar including - Plans for SFU-backed calls - Forum/groups stuff - Spaces (which should map to matrix spaces, discord guilds) and other social media features ✏

it'd be nice to see such forces join together, maybe? :> Imo having good, scalable voice chat on XMPP would make this protocol quite perfect in many ways

> it'd be nice to see such forces join together, maybe? :> > > Imo having good, scalable voice chat on XMPP would make this protocol quite perfect in many ways I haven't looked at it yet, but aren't STUN/TURN Servers already what is commonly used, and thusly decently scalable? ↺

AFAIK, yeppers!

>> it'd be nice to see such forces join together, maybe? :> >> >> Imo having good, scalable voice chat on XMPP would make this protocol quite perfect in many ways > I haven't looked at it yet, but aren't STUN/TURN Servers already what is commonly used, and thusly decently scalable? the new architecture is Selective Forwarding Units (SFUs) which should be much more scalable than peer-to-peer based calls, especially in large rooms Afaik TURNs don't scale well and are more used as a relay method than an efficient transport arch ↺

(I wonder if TURNs set up multiple candidates if I'm in a multiparty call, but not sure if this is the right MUC to get a response)

Small check-in, what is our definition of "large"? The communities I am most concerned about have a userbase that leads to active voice-calls of around ~20 people *on very busy days* If a TURN server is fine with that ... Why not? Coturn says that it can handle a lot of ongoing connections, so I'm not sure where the bottleneck for you would be ... Client bandwidth?

On the topic of voice chat rooms, what about Mumble?

Seems good for the purpose, but I don't know how well it would integrate in an XMPP client ✏

> On the topic of voice chat rooms, what about Mumble? I used to use Mumble as a way to have group calls when we didn't want to speak on Discord and XMPP wasn't enough.

Eehh, iffy already because modern services also expect some basic way to do screen-share. Mumble *is* nice, but, a visual stream is ... Kinda normal these days. How does Discord do it ...

> Seems good for the purpose, but I don't know how well it would integrate in an XMPP client Now that is also an idea, make another new XEP to bridge Mumble and XMPP?

>> Seems good for the purpose, but I don't know how well it would integrate in an XMPP client > Now that is also an idea, make another new XEP to bridge Mumble and XMPP? Perhaps an idea to forward to the eyes and ears of that other Jabber/XMPP dev group.

I also just noticed XMPP lacks message forwarding.

Or maybe that is just Conversations ✏

> Eehh, iffy already because modern services also expect some basic way to do screen-share. Mumble *is* nice, but, a visual stream is ... Kinda normal these days. > > How does Discord do it ... I might agree, but then it isn't just a voice room to me ↺

> I also just noticed XMPP lacks message forwarding. I think that is a general trait ↺

if by message forwarding you mean including backlinks to the original message, then it's kinda hard to do in federated systems

> Small check-in, what is our definition of "large"? > The communities I am most concerned about have a userbase that leads to active voice-calls of around ~20 people *on very busy days* > > If a TURN server is fine with that ... Why not? > Coturn says that it can handle a lot of ongoing connections, so I'm not sure where the bottleneck for you would be ... Client bandwidth? thats large. you'd be uploading and downloading 20 streams simultaneously,with or without TURN (if my intuitions are correct). And imagine if some of them are video streams... So you'd need a central point to upload your own stream to, but download 20 others. Saving upload bandwidth is what SFUs do, and it'd fit with modern residential networks. Though dont quote me but I do believe discord (or any large platforms) would go with such designs too ↺

but xmpp can suit you if you have like 5 participants on average, or something in that ballpark. Maybe you can go to Jitsi or something on one of the rare busy days :)

If you want to forward a message, you'd need a s2s scaffold and/or a c2s scaffold to request a particular message by its ID, and you could add a property to MUCs to simply retransmit that message if it's in history, not just to a joined user. Simple, I think.

> thats large. you'd be uploading and downloading 20 streams simultaneously,with or without TURN (if my intuitions are correct). And imagine if some of them are video streams... > > So you'd need a central point to upload your own stream to, but download 20 others. Saving upload bandwidth is what SFUs do, and it'd fit with modern residential networks. > > Though dont quote me but I do believe discord (or any large platforms) would go with such designs too Well ... Yes. That's what the Game Nights for some of my groups look like. About ~10 people, 7 of them with a video camera on, 1 screenshare for a Jackbox game going. ↺

When you ask for messages when not a member of a MUC, I believe the server tells you 'no, you're not joined, sorry'. Just let it through, and it may simply work.

The tracking on what *should* be let through that way, that's where development would be, I think.

> If you want to forward a message, you'd need a s2s scaffold and/or a c2s scaffold to request a particular message by its ID, and you could add a property to MUCs to simply retransmit that message if it's in history, not just to a joined user. Simple, I think. I guess it can be tried with a proper namespacing of MUC JID + message UID XEP, though idk enough to see if it works or not. Have you looked at previous XEPs for this? ↺

Permit all, permit none, or send a special message saying 'I wish to share this' to the server, would be about right, I think. ✏

I haven't pinned this to a particular XEP but I'll start with my discovery in MAM, since that's most likely to be the affected greeble here.

also wouldnt play nice with graceful degradation and ephemerality - some main principles that I think xmpp strive for

I think there are some means to account for it, actually.

eh take a look https://xmpp.org/extensions/xep-0297.html

And XEP-0313 allows you to fetch messages by ID (if you're permitted to)

2013. Beautiful. And they did it at-time-of-forward, so static. Awesome.

Yeah, this will be perfect.

They were smart 😉😅

They sure were!

Man, every time I look at these XEPs makes my programming fingers twitch, 'cause I'm at that point where I just gotta do it, there's no other barriers anymore

Funnily enough Discord has no message forwarding at all, and it's been doing fine. It's one of those "Semi-useful but can easily be faked with just having a quote message with a link" things.

One thing I meant to say the other day, based on the way you described your planned architecture, I would caution against a strict plugin-per-XEP approach

Discord did recently implement message forwarding, within the last year IIRC. But functionally i don't know what makes it any different from if you just quoted and attached a link, except aethestically.

For folk who are newer to XMPP (either users or developers), there is a tendency to focus a lot on XEPs. A truth that eventually dawns is that features != XEPs, and usually a feature-based approach is better

For example, there are features which do not require any XEPs. There are XEPs which do not provide any features. There are features which require multiple XEPs, and some XEPs allow implementation of multiple features.

> For folk who are newer to XMPP (either users or developers), there is a tendency to focus a lot on XEPs. A truth that eventually dawns is that features != XEPs, and usually a feature-based approach is better MattJ: why is that? The 'features! = XEPs' part.

They (Discord) use dynamic forwarding too, which means the original message can be destroyed and the forwarded message gets destroyed too. Not ideal if you intend to CC. ✏

> For example, there are features which do not require any XEPs. There are XEPs which do not provide any features. There are features which require multiple XEPs, and some XEPs allow implementation of multiple features. Hmmm...

XEPs are more of the protocol building blocks I think, rather than a full feature suite

Because XEPs are just describing extensions to the protocol, and that's all. Sometimes you don't need to extend the protocol.

Hm!

I will have to learn more about this

You already gave a good example not long ago here: bridging Mumble and XMPP would require no XEP

No new XEP anyway

> You already gave a good example not long ago here: bridging Mumble and XMPP would require no XEP huh, you mean just put in a URL? ↺

How would you create a feature without any XEPs, or do you not include Core in that, etc etc? ✏

stratself: I don't think Mumble uses URLs

XMPP already has XEPs for audio conferences, and that's what Mumble is

you could make a bridge using a bot user, but it would probably be pretty janky. i've never used mumble for voice chat, though.

> No new XEP anyway Please elaborate

No, you don't need a bot

> stratself: I don't think Mumble uses URLs i see, but I guess you mean you can just add in something like a Jitsi link and have clients render it without needing a new extension ↺

No, I would probably implement it as a gateway component

It would give every Mumble conference an XMPP address

> No, I would probably implement it as a gateway component Oh, like that XMPP/SIP XEP?

And you could invite it to a call or whatever

But because all the XMPP server and XMPP clients see is a conference (they don't need to know or care that the backend is Mumble) you don't need a "Mumble XEP"

So you can see that features are possible without new XEPs, this is just one example

MattJ: has there been any A/V gatewaying between xmpp and another platform (not protocols i.e. SIP)? I presume this would require writing a bridge in the likes of slidge, but for live media ✏

Yes, bridges are generally needed. But most platforms build upon standard media protocols such as webrtc

And XMPP clients already support that

> How would you create a feature without any XEPs, or do you not include Core in that, etc etc? every XEP is built as an extension of Core, fyi ↺

Sure, but also some features simply don't need protocol changes

> MattJ: has there been any A/V gatewaying between xmpp and another platform (not protocols i.e. SIP)? I presume this would require writing a bridge in the likes of slidge, but for live media imho not worth it, but a SFU would open the way to have easy guest participants in browser client. ↺

Galene SFU which is what Libervia is experimenting with has that built in

> So you can see that features are possible without new XEPs, this is just one example Right, right, I understand! ↺

Yes, SFU is the way to go

XEPs are the inherent capabilities of the protocol, the 'how does it do that'. Features are capabilities of the program and by extension, the user, the 'what can *I* do'.

i'd say XEPs also serve the social-technical purpose of being properly vetted and agreed upon for open federation. As you may've seen with whatsapp and others, XMPP can be extended proprietarily to serve their own gains, too

distaza: yes, well said

stratself, that too

XMPP being extensible isn't enough. The XMPP Standards Foundation and the XEP process exists so that when client developers decide they want to implement reactions, and that requires new protocol stuff, everybody can agree on what that new protocol stuff is. Otherwise we end up with a bunch of incompatible clients that can't send reactions to each other.

XEPs also tend to consider the fallback case ("What happens when one of the clients receiving this doesn't support it?"), and in this case often some fallback to plaintext is used