Modern XMPP project discussion - 2025-09-01

Total XMPP noob here, but I'm wondering if anyone has been working on a client / functionality which gives sub-channel functionality to XMPP chats? By that I mean something similar to Discord/Slack/Element where there is a topline room/server/group which holds roles/privileges and then below that are topical chats/channels. I have a very simple conceptual hack to make this work client side with no change to XMPP itself, but it would involve making those rooms less convenient to use via other clients. [Essentially all messages go in one standard xmpp channel and the client appends a string to the end of each message, and the client filters the messages into different threads]. That said I have no coding ability and am a noob so I figure maybe someone has worked out a better way?

coopr8: could work with XEP-0201 or XEP-0461 perhaps?

> coopr8: could work with XEP-0201 or XEP-0461 perhaps? Im just learning, those are means of reducing message size by not using Markup for all message content right? ↺

https://blog.jmp.chat/b/january-newsletter-2023 > One of the big ones is an interface for having threaded conversations with other Jabber users (watch the demo video <https://kumi.tube/w/1LQQp5Uia4u8Pdojxen1y8>).

coopr8, https://xmpp.org/extensions/xep-0503.html

> https://blog.jmp.chat/b/january-newsletter-2023 >> One of the big ones is an interface for having threaded conversations with other Jabber users (watch the demo video <https://kumi.tube/w/1LQQp5Uia4u8Pdojxen1y8>). Video won't load for me for some reason ↺

but not implemented anywhere afaik

I think they were looking for something more like Discord's threads

> coopr8, https://xmpp.org/extensions/xep-0503.html ❤️ ↺

Yes thats right, seems like maybe the system Kris posted could be used to implement that in a client

related idea. some chat systems treat "threads" as sub-channels

the original implementation of threads in Discord was like that too, but they changed it again I think

Yeah, you could probably cludge it so that the admin of the channel can create persistent threads labeled by topic, and suppress it for other users

(not a big Discord user here)

> related idea. some chat systems treat "threads" as sub-channels This is what's in Cheogram, as shown in that video IIRC ↺

https://www.youtube.com/watch?v=apazJINa1UI maybe this is the same video?

Yeah, though that's more integrated into a single channel instead of subchannels like what discord has

no? Cheogram does the opposite

"This clustering is already possible in practice by using a dedicated MUC Service (Multi-User Chat (XEP-0045) [1]) to group several rooms, but this limits its spaces creation to administrator of servers." ... "this specification voluntarily does not cover access control, permissions, membership inside a space and its children rooms."

Oh I read threads

Good thing we don't have a million things that use the same word here.

Cheogram's threads are definitely mixed into the main channel, but IIRC you can choose to just view a single thread

yes, but "threads" are not clearly defined. in some chat systems they are treated as sub-channel rather.

in Zulip they also function more like seperate channels

Hmmmm... so maybe XEP-0045 is almost it, but would just require a sub-admin role on the server so that users can create spaces and manage rooms in those spaces without top level admin privilages

Yeah, sorry for imprecise language. On XMPP is "Modern XMPP protocol" a "room" or a "channel"?

I have trid several chat services recently so my lingo is jumbled

This place we're chatting in right now? Let's consult https://docs.modernxmpp.org/terminology/

> This place we're chatting in right now? Let's consult https://docs.modernxmpp.org/terminology/ ❤️ ↺

Awesome, thanks, I came to the right channel!

> in Zulip they also function more like seperate channels Is Zulip built on XMPP? ↺

> yes, but "threads" are not clearly defined. in some chat systems they are treated as sub-channel rather. In current client side implementations Threads are more like a set of replies to an initiating post within a main Channel, so they can be filtered to display only those replying messages, is that right? ↺

It basically just enables the reply feature within Cheogram (which I am currently using) it appears. I definitely wouldnt want to sacrifice reply functionality in order to enable sub-channels. Seems like a both-and scenario is necessary, as that is the current baseline of the competing platforms.

coopr8, no, just another example of a chat system with threads as subchannels (kinda)

> In current client side implementations Threads are more like a set of replies to an initiating post within a main Channel, so they can be filtered to display only those replying messages, is that right? that is how Cheogram does it afaik ↺

replies still work, but they kinda automatically asssume you want to start a thread

Yeah, that mirrors Discord and Slack in which a Thread is a special kind of Reply that creates an ephemeral sub-channel that goes away after a certain amount of time without a new post.

Hmmm, I mean if this has to be done server side the other way to do it would be to create a directory server side that specifies what Spaces exist and which Channels are assigned to each Space, the the client just pulls that information and displays the channels grouped by Space.

I see that is the proposal for XEP-0503 , I will have to read the document further. Shame no one has implemented it, there was a wave of exiles away from Matrix with the last security flaw reveal

if you know Rust you could contribute the the Muchrooms project that aims to modernize the group chats as a seperate component

xmpp:muchrooms@xmpp.rs?join

that way it isn't server software specific and would work with most servers

I think they would be open for a 0503 implementation in it

ofc. Prosody would probably also be a good test bed

Sadly I'm a code illiterate end user, though I keep thinking I'll take some courseware one of these days. I dont think I'd start with Rust though

> xmpp:muchrooms@xmpp.rs?join ❤️ ↺

Side note, are reacts native to all clients, or do they come out as annoying plaintext comments in some clients?

"It depends" 🙂

Reactions are certainly not supported by all clients (e.g. the terminal client I'm using)

The sending client determines how it will display to non-supporting clients

The popular options are "quoted reply" and "not".

Ok, so is it considered best manners to avoid using reacts?

No, fire away coopr8

(like: most popular clients have them now, and only cheogram adds quotes with an emoji for non supporting I think, the rest will just be invisible for non supporting clients)

> No, fire away coopr8 🎆 ↺

Any advice in why I would prefer to use a windows XMPP client vs a browser based one? Gajim vs Movim? I have found in the past some chat apps (discord) perform better in-browser so I save a browser instance/"app" rather than use the client. Also eliminates software updates, which is nice.

local software works better on bad connections

and in general more capable and less resource-intensive

Gajim allows you to connect to multiple accounts simultaneously, and a native app has some advantages for the security of your e2ee messages, but for most people I would recommend Movim.

L29Ah, not really true for Movim, since it has a server component

it smoothes out most of the connection issues, basically it is better than a local app in that regard.

the only advantage a fully local app has is that you can read and pre-compose messages while offline, but I find that a bit pointless for a messenger ✏

personally i grep my logs a lot

And the omemo key mess and security as you said.

sure

> the only advantage a fully local app has is that you can read and write messages while offline, but I find that a bit pointless for a messenger For PC use in particular I don't need to view messages offline for the most part. I see the advantage on mobile, which is one reason I'll stick to Cheogram for now on that ↺

OMEMO doesn't work well on Movim in-browser?

Omemo works in Movim (and was very recently improved a lot), but by the principle of loading the software from the server you can never be quite sure if your webapp is still encrypting the messages correctly

it is a possible attack vector that is much harder with native apps ✏

ah, I see