Modern XMPP project discussion - 2025-06-24

Hi. Kris: while I would be happy to have DeltaChat compatibility, my main target is generic email (IMAP/SMTP gateway to be precise), DeltaChat is a side effect. I've implemented Autocrypt and can add other necessary stuff, but I have very limited time.

ah, my misunderstanding. I thought DeltaChat was the primary target.

personally I find that more useful. normal email does not translate well to xmpp.

No, a side effect. It's too niche for the moment and I don't have the resources. But it should more or less work anyway.

good to know.

Why would not it translate well? The goal of this gateway is to make it good UX, so if you have specific pain point, please let me know.

entirely different UX pattern.

email is threaded and long form.

XMPP has thread and handle long forms too.

kinda...

right we are just missing UI no?

It's because you're used to chat UI, but the UI can definitely be adapted.

most clients don't

^

Well, that why I'm working on it with Libervia. I hope other clients will follow.

I'll make a video when I find time, but I have now a kind of "inbox" view, with messages from XMPP + gateways, with a tag indicating the source. So you'll have e.g,, XMPP + SMS + Email + ActivityPub private messages there.

debacle: I guess this muc is suitable for the team chat discussion. So could you tell me what makes a good team chat according to you (haven't have time to check Prose yet, but I've seen screenshots). Note that I'm notably asking to see where I can focus my UI/UX efforts.

threads, spaces/servers, announcement/read only channels. i personally think zulip is the best team chat we have but i understand that is not a popular sentiment 😋

good bot integration also probably

I heard so many good things about Zulip. People say, it's better than Mattermost or Rocketchat. I don't know any of the three myself.

Yep what MSavoritias (fae,ve) said! I would add status messages with emoji as something we'd use a lot on the Mattermost server I was part of

Not a huge fan of Zulip, but indeed if you want to make a email / chat hybrid for "office" use it might be a good template to look at.

Zulip is so good, I swear if someone built it on top of XMPP it would convince everyone

ah nice to see im not the only one 😊

its the only threads that make sense imo

I like Mattermost, but also the one Zulip team I worked with was a bit dysfunctional and it was long ago so maybe I should revisit it 😅

What is important to me in a team chat, with spaces/servers, is the central management of rights: a user should have their role/rights configurable at higher level so that the creation of a new room doesn't need to do specific configuration for inviting the right person and giving them the right... rights

The email-clientification of office software is horrible. Zulip just does the least bad job at it.

MSavoritias (fae,ve), can you explain what you had in mind for threads? This is something there seems to be a lot of confusion about (Mattermost itself has two modes for it that don't really play with each other) so it would help to be more specific 😛

Mattermost is basically a 1:1 slack clone.

I'd go, but even I'm confused about how exactly I want threads to work

Zulip's threads are closer to email threads: they always exist, have a clear subject, and can be easily found. Most discussion should happen in threads because it makes information easier to search

Compared to slack/mattermost/discord where it's just a way to hide a conversation from the "main" conversation, in zulip all conversations are equal

What my sales colleagues say: 1. integrated A/V calls, both one-to-one and (small) groups 2. super-easy messaging to more than one person (most Jabber clients are clumsy with adhoc MUC creation) 3. fast access to all my mentions, e.g. of the last week, without tortuous searching through MUCs 4. fast access to all documents sent or received in the past, maybe with interface to e.g. Nextcloud 5. "bookmarks" (not what XMPP calls bookmarks, but to single messages in one-to-one chats or MUCs)

basically what is the slack model and matter most from what Kris, said: you reply to a message and then a button appears that takes you to a seperate screen that is the thread. there is a screen listing the threads you are part of, but as soon as you scroll the thread dissapears. so you basically have one screen/group for everything and you have to find the button under the message to list the threads. how Zulip works: there are no channels, only threads. you can create subthreads that belong to a parent thread dynamically. each one has a title and you scroll all of them like a feed. as rako, said its basically an email kind of thing.

spaces is new/experimental, but now present in XMPP, let's see how it goes. Threads is there, Movim and Cheogram do it. are the UI/UX good or not there?

the title of the thread being the "room name" kind of

Announcement channel is trivial. Or you need a special UX for it?

I add: 6. ideally no e2ee by default, at least none with PFS! ✏

agreed. its irrelevant there

goffi, do those points already help you?

and anybody can create threads in zulip. in contrast channel creation in slack at least is slow and requires people to migrate to the new channel. plus not easily searchable at all

debacle: yes, and I see many are done or doable relatively easily.

The difficulties is to now overload the UI.

Okay, so I'm guessing it starts with a bunch of top-level threads (maybe "general", "server-stuff" and "client-stuff"). I'm guessing we can send messages directly in that. What happens if I then want to make a new thread under "server-stuff" called "taking-backups", does that show amongst the messages like Mattermost/Discord or is it some kind of tree view on the sidebar?

I think I'll see if I can find a demo of zulip, and will try Prose too.

goffi Where can I see threads in action? Movim?

> What my sales colleagues say: > 1. integrated A/V calls, both one-to-one and (small) groups > 2. super-easy messaging to more than one person (most Jabber clients are clumsy with adhoc MUC creation) > 3. fast access to all my mentions, e.g. of the last week, without tortuous searching through MUCs > 4. fast access to all documents sent or received in the past, maybe with interface to e.g. Nextcloud > 5. "bookmarks" (not what XMPP calls bookmarks, but to single messages in one-to-one chats or MUCs) That list (and the addition of no PFS) sounds about right, along with the threads thing we're discussing! ↺

I think Movim has them yes, but I really testing rarely, I don't use it. Cheogram has them too (mobile).

> I think I'll see if I can find a demo of zulip, and will try Prose too. Prose is very easy to try. Download and unpack their web app, add a site on your nginx or whatever and that's it. Similar to converse.js. ↺

On Libervia, you can check my last video, but it's not on a side panel, and I haven't yet implemented multi-levels.

in zulip all messages are part of a thread. The sidebar allows you to choose to see all messages in a thread, all messages in a channel (a channel contains threads), or all messages everywhere. Every message is displayed with a "wrapper" that indicates which channel and thread it is part of, without cluttering too much of course

it's now* on a side panel.

badrihippo, ^

basically you can see all messages under a thread "group" like general and subthreads, or all messages everywhere

or any subthread group etc.

Zulip is written in Python and JS. Maybe somebody can "port" it to XMPP ;-)

and you can directly edit the title of the thread group so that creates a "thread"

What I do in Libervia, is that all messages appear in chronological order, but if you over it, related messages are highlighted. If you click, there is a panel with only messages from the threads (and reply is in the thread).

> basically you can see all messages under a thread "group" like general and subthreads, or all messages everywhere I see, that (having it in the sidebar) does sound much more navigable than having it embedded as part of the messages! ✏ ↺

> or any subthread group etc. So, can you also do sub-sub-sub-threads etc. and have them displayed as a tree in the sidebar? Or is there a limit to the depth ↺

>> or any subthread group etc. > So, can you also do sub-sub-sub-threads etc. and have them displayed as a tree in the sidebar? Or is there a limit to the depth no, you only have channels (aka rooms) and topics (aka threads) ↺

Ah okay. Makes sense

Now I'm seeing where some of Cheogram's design could be leaning towards

debacle: yes I know it's easy to try, I just not easy to find time for it ;)

debacle: for threads in action in Libervia, you can check https://videos.libervia.org/w/gMhim6Ef3JFrEtayyXEbvJ?start=2m4s (UI has improved since). It's still WIP, but the basic idea is that you keep the workflow, and can move any time to thread view.

I'm guessing everything in topic (thread) is visible to everyone in the containing channel (room) and if you want to break to more specific people you'd create a separate channel (room) for that? ✏

Starting new discussion with a group is also show in this video.

Calling it "topic" has some semantical significance: it has a specific subject and talks about something. The idea is not to have a conversation tree. Maybe another comparison would be lemmy: a channel is a community, and a topic is a post with its replies. When you search for something the name of the topic can help, and sometimes the first post of the topic contains the answers. Zulip is closer to a forum in a chat ui, while Movim/Cheogram/Slack/Mattermost/Discord are doing chats with some management in a way

This somehow maps well to what I understand of the thread related XEPs as well. Mattermost and Discord got me so hung up on "threads start inline of the conversation" that I didn't think of navigating it separately 😅

Isn't channel and topic the naming way of IRC?

Maybe? I've never used IRC (except bridged from XMPP) so that's a design background I didn't have 😅

Also, putting it out there to clarify: replies are a separate thing from threads/topics and we're not mixing them right?

> I think Movim has them yes, but I really testing rarely, I don't use it. Cheogram has them too (mobile). No, Movim disabled them as the UI did not differentiate with replies and it became very spammy on auto threads with Cheogram. ↺

> Also, putting it out there to clarify: replies are a separate thing from threads/topics and we're not mixing them right? they are yeah ↺

We've had a long debate on xsf@ about replies and threads.

And on standard@

Yeah, that's why I wanted to make it clear from the start (regarding the idea of threads being discussed here) 😅

i think protocol wise they are also different

In Libervia, you can start a thread from any message, it will create a reply first, with a thread ID.

A lot of the Fediverse treats a chain of replies as "threads" but I don't think the Zulip method is going for the same thing

ah yeah i agree. tbh threads are something that needs a lot of thought UX wise

for example zulip also has the problem of people creating too many threads because its "so easy"

but with slack you lose conversations with threads so you are flooded with rooms instead (which is kind of what we do in xmpp too)

> In Libervia, you can start a thread from any message, it will create a reply first, with a thread ID. That sounds like Mattermost. Where the message you start the thread from also serve as the title of the thread ↺

> for example zulip also has the problem of people creating too many threads because its "so easy" and conversely of chatting and talking about unrelated things inside a given thread because they're already there

the question is how to make the UI of threads easy enough to encourage it, hard enough so its not overused but also inclusive enough so people dont "have to" use threads or know that they do use them

Oh funny, the description of Zulip on AUR is "Real-time team chat based on the email threading model"

> > for example zulip also has the problem of people creating too many threads because its "so easy" > > and conversely of chatting and talking about unrelated things inside a given thread because they're already there that too yeah. or replies to the "wrong thread" ↺

Unpopular opinion but I think creating temporary channels like IRC is still the best way to make "threads" 😎

Oh and one cool thing that might inform decisions: when messages in zulip are in the wrong channel/topic, they can be moved

right that could also be interesting

Is there a way in XMPP to set a thread "title" without it being linked to a chat message? Like, when I join the room, I immediately get the "titles" of corresponding threads?

Moving messages would be delicate, it may have security implications.

It's actually important I think to slowly drive the community towards "proper" usage starting from where they are

> Oh and one cool thing that might inform decisions: when messages in zulip are in the wrong channel/topic, they can be moved I didn't know it was already a thing in Zulip, but I was going to suggest it! ↺

badrihippo: no, it's the message subject. Thread can have an ID and an optional parent, that's it.

Would be nice if we could "sew" messages together into threads after they've already taken place

yeah

i think that plus being able to refernce messages are linked

But it's an element, that can still be extended.

It commonly happens that 4-5 rounds of messages go past before someone says "maybe we should make that into a thread"

Is this possible in zulip?

making a thread from old messages?

🤷

with the moving feature maybe?

> Moving messages would be delicate, it may have security implications. It should be fine within the same channel (room) right? Because the participant list is the same anyway ↺

Yeah, but your reply may have a totally different meaning if it's in a different location.

> making a thread from old messages? Yes

> Yeah, but your reply may have a totally different meaning if it's in a different location. Ahh good point ↺

Hmm

like saying "I like it", change everything depending on parent message.

the moving could be done completely client side also. to avoid syncing different display history

because it sounds complicated personally. and as goffi, said with security implications across chats

> Would be nice if we could "sew" messages together into threads after they've already taken place A "service message" can be sent in the origin and destination topic, saying messages were moved. There is a linked to the other topic, and to the message if it's the destination topic

> the moving could be done completely client side also. to avoid syncing different display history You mean, the server doesn't change history but just sends all messages (including message moving) in the same order as before, and the clients decide to actually move them (or not)? ↺

> > Would be nice if we could "sew" messages together into threads after they've already taken place > > A "service message" can be sent in the origin and destination topic, saying messages were moved. There is a linked to the other topic, and to the message if it's the destination topic Yeah a service message would also let a client say that "This message was moved from [old thread] to [new thread] by [mod]" ↺

What I meant is that in Zulip it's there, the mover can decide whether the message is sent 😃

rako, what's the flow for that?

> You mean, the server doesn't change history but just sends all messages (including message moving) in the same order as before, and the clients decide to actually move them (or not)? yeah like I organize the discussions according to how i see fit. in case something was misplaced ↺

> Yeah a service message would also let a client say that "This message was moved from [old thread] to [new thread] by [mod]" Anyway, if I client has a way to indicate this then even if the meaning is manipulated (like by moving "I like that") at least it's clear something's going on. And in most cases I think it'd just be people cleaning up to file hings in the right thread ↺

idk if that makes sense tho tbc. im just brainstorming here

Actually when converting a one2one chat to group chat, you can send old messages (history);

> yeah like I organize the discussions according to how i see fit. in case something was misplaced Mmm I think some sync to other people is necessary; otherwise it could get confusing? ↺

> rako, what's the flow for that? The doc has some info ( https://zulip.com/help/move-content-to-another-topic), but basically: 1. select (one) message to move 2. a popup opens, where you select 2.1 send only this message or message until the end of current topic or all messages in topic 2.2 new channel and new topic 2.3 send automated notice to old topic or not 2.4 send automated notice to new topic or not

And only you can move your own messages? i.e. if there are several people in the discussion each of them has to decide to move their messages to the new topic?

no you can move everyone's messages

> When messages are moved, Zulip's permanent links to messages in context will automatically redirect to the new location of the message. Muted topics are automatically migrated when an entire topic is moved. This is cool (from the docs you shared)

> no you can move everyone's messages I see. And it seems who can move is configurable, which makes sense: > Organization administrators can configure who is allowed to move messages. ↺

Why are the automated notices toggle-able though?

> Why are the automated notices toggle-able though? Notices are persistent, so I guess if everyone is already aware they're useless. Also when you want to move multiple messages in the middle you have to do it one by one so I guess you'd send notices only for the first one

Funny: Most people here (myself included) think, that threads are important for team chat. But my colleagues did not mention it at all. They are happy with message replies.

I see. I'm thinking I'd prefer to have these notices sent from the server anyway (and let users hide/mute them from the client side if they want). If we implement moves as special "[person] moves [message] to [thread]" stanzas that'd happen implicitly I suppose, as the client gets the information for technical reasons andthe server decides whether to do it or not

goffi For a team chat, it would be cool, if the MUC description and subject can be visible all the time. It could contain links (e.g. to a Nextcloud document folder) relevant to the specific MUC.

Another feature, that is *very* helpful, but unfortunately gone from some Jabber clients: Presence with additional information ("away", "busy", "lunch", ...). Gajim had that (long time ago), and we used such stuff. Also nice: Roster groups to have organisational structure visible in the chat.

pinned messages would also be nice personally

slack has that at least

debacle: I put subject on retractable side panel because I actually think that subject doesn't need to be always visible: once you've read the important informations, it's a waste of place to display it permanently.

> Another feature, that is *very* helpful, but unfortunately gone from some Jabber clients: Presence with additional information ("away", "busy", "lunch", ...). Gajim had that (long time ago), and we used such stuff. Also nice: Roster groups to have organisational structure visible in the chat. I was talking about this as well. We actualy used it in Mattermost to know when people are online etc. ↺

It would be cool (though requiring a bit more spec work) to also allow setting a status emoji. In Mattermost this shows as a small icon next to the user's name, and when you hover it shows you their full (text) status message

We had our own signals like 📹️ for being open to group video call and ⏳️ when waiting for something (like an article submission or review) to happen, but also use it for more fun things like ☔️ when it was raining (and in the monsoon season a bunch of people would have that umbrella at the same time so we'd know it was a rainy day in all those places)

On a related note, custom emoji is also helpful for team/community specific interaction. That was one feature we missed when trying out NextCloud Talk at some point

i'm not sure if there's an XEP for that though 🤔️

Evidently not

But anyway yeah I think emoji status and custom emoji are two things imported from I don't know where (Discord? Fediverse?) that Mattermost got right

> debacle: I put subject on retractable side panel because I actually think that subject doesn't need to be always visible: once you've read the important informations, it's a waste of place to display it permanently. Controversial opinion: topic (whatever you change with the /topic on many clients) is like a "status message for the group/channel" which keeps changing, rather than something more permanent (which would go in room description) ↺

At least we'd use it that way in Mattermost, like a reminder of what pressing things to focus on that day or a link to something being discussed (usually everyone in our small group had permission to change it)

badrihippo, you are notified when a the room subject is changed, no need to keep it displayed permanently.

> Why would not it translate well? The goal of this gateway is to make it good UX, so if you have specific pain point, please let me know. Goffi, sorry for late reaction re: painpoints email←→XMPP. (If only I could start a new thread from your question 😉) Since anything not explicitly forbidden in email _will_ arrive at the gateway, here are some things I believe could be challenging: ↺

*The sender of an email can add or remove recipients w/o restriction.* How does that map to XMPP room membership? In case of an added recipient, is it a JID or an email address? What about if one (or more!) of the recipients is a mailing list (with Reply-To and all that)?

*How do cc: and bcc: email recipients map to JID recipients (2-way)?*

*Multipart emails* Text rendering not equal to html rendering (content wise) _winmail.dat_ - Yay, Outlook

*Email clients often add the recipients of outgoing messages to an implicit address book.* When the intention is starting a new email conversation with an existing contact, will it be annoying if they have both an email address and a JID-via-email address? (Many clients no longer show the email address, only the display name.) What if people have a JID equal to their email address? (Maybe not a problem?)

*Email messages are free-form, leading to lots of fun (and dangerous?) parsing...* Footers would be annoying in a chat context. How to detect and remove them?

How to handle quotes from previous messages? They can be marked by ">", indents, or be in tables. Maybe even more ways? They can be top, bottom, inline. They can be intentional or automatically added (I think the latter should be removed)

How to handle formatting that XMPP lacks (roundtrip!?)? Embedded images (context provided by surrounding text) Tables with formatting (borders, backgrounds, etc) Font faces, sizes, text colour. Alignment Unordered and ordered lists ✏

> badrihippo, you are notified when a the room subject is changed, no need to keep it displayed permanently. Is that notified as in a pop-up of some kind, or is it a kind of message inserted into the stream? (Would prefer the latter.) ✏ ↺

Email←→XMPP: Everyone has an email address, so this is a very attractive feature. It would allow including (and possibly later on-boarding) friends in a group based on something better than email.

> *The sender of an email can add or remove recipients w/o restriction.* > How does that map to XMPP room membership? > In case of an added recipient, is it a JID or an email address? > What about if one (or more!) of the recipients is a mailing list (with Reply-To and all that)? My gateway doesn't use rooms, it's all single messages. From the email point of view, there is not JID, you're comunicating with the email (my gateway connect to an existing email account). extra recipients (extra to, cc, bcc) use XEP-0033. Messages body are cleaned, and I've planed to detected things suchs as footers or quotations. Mailing list are (will be soon) treated in an entirely other way, they are converted to XMPP blogs (or more exactly, forums). I think that showing sender/recipient name instead of address is a good thing and I plan to do the same. ↺

But I'm scared by the mismatch between the two media - people have very different expectations when they use IM compared to email. Friendica has an email connector that sees very ilttle use, is confusing to people on the email side, and generally only works for 1:1 - when it works at all.

I think that showing name _instead_ of address is bad, that is what lets anyone pose as Microsoft Support...

It probably won't be perfect for all use cases, but should improve with time and feedbacks. I think that we can do a pretty decent job fine for 90 to 99% of cases. Also the gateway doesn't prevent to use classic email program, you can use in parallel.

Showing both name and address is more to my taste.

Address should definitely be accessible, but it could be in details or something like that.

Yeah, I know I'm in the minority there 😉

What do you mean by "the gateway doesn't use rooms", like only for 1:1? ✏

mailing list are converted to blog/forums, and multi recipients use XEP-0033.

I could add a MUC at some point, I need to think about it. That implies new problems, as the ones you have mentioned, which don't exist with XEP-0033.

The use case I'm thinking of is not so much a proper mailing list, but the kind of group friends would form when discussing what film to see (so _To:_ field with a few addresses) - only mixed-mode XMPP+email. It would have been a room if XMPP only.

I need to digest XEP-033 to understand

I guess I have to try it out to be able to provide useful input. Anyway, it sounds like you already tackled quite a few challenges with the gateway, so here's to that 🍻!

epi: yes I know this use case. With XEP-0033 it should work as long as no recipient is lost (same as for emails). After it's a UI/UX things to make it look like nice. In Libervia, it will appear in your normal message with a thread, a click on it and you'll reply to all participants, it would feel like a group chat.

I'm experimenting, there will be improvments to do, but I believe that we can do a pretty decent job with gateways if we put enough time and work in them.

The main issue with XEP-0033, is when non supporting clients (i.e. most client) use it, they will see only the main recipient. I'm not sure yet how to deal with that.

> I'm experimenting, there will be improvments to do, but I believe that we can do a pretty decent job with gateways if we put enough time and work in them. Key phrase "enough work" 😉 I wish you success! ↺

Well, thanks to NLnet/NGI grant, it has been possible to put quite some work already.

as a note from the sidelines I very much agree we need to do work on the gateways if we want to have them, but also

we need to collaborate *a lot* more with other protocols and networks and have more open communication

both at the protocol level and at the community/developer level. i bet there are things other protocols/networks/communities can do to make it easier for us, and there are a lot of things we can do to make it easier for them

> The main issue with XEP-0033, is when non supporting clients (i.e. most client) use it, they will see only the main recipient. I'm not sure yet how to deal with that. Ah, I didn't think of the potential intra-XMPP mismatch on top of the email challenges. That will be confusing to people using a non-XMP-0033 supporting client. ↺

Does that also mean their replies only go to the main recipient? That would be bad for the conversation

XSF is ideally that, but there is not a lot of push from XSF for that kind of collaboration in my experience and not that many people involved in the XSF chats that are from other networks/protocols

MSavoritias (fae,ve): It's difficult, everybody is head in their own stuff, and nobody as time. For ActivityPub gateway, I've been helped by one of main Mastodon dev at some point. Beside that it's mostly about opening tickets.

> as a note from the sidelines I very much agree we need to do work on the gateways if we want to have them, but also Agreed, being in rooms bridged with IRC and Matrix isn't always a good experience. ↺

Oh yeah that's terrible with their `[M]` everywere and the bot-style conversion.

agreed

> MSavoritias (fae,ve): It's difficult, everybody is head in their own stuff, and nobody as time. For ActivityPub gateway, I've been helped by one of main Mastodon dev at some point. Beside that it's mostly about opening tickets. yeah.. i just hoped we had a place where it has open and bi-directional as a "meeting point" and bridged everywhere, instead of hidden 1:1 chats or github tickets to places ↺

that is not a comment on you goffi, if anything you are one of the biggest contributions to gateways we have 💜

Sure. It would be nice. But in my case, it's already hard to follow what happen just in XMPP, I barely follow xsf@ except if I'm mentioned or from time to time if I catch a conversation or ask something.

It also is a question of priorities, collaboration within the XMPP ecosystem and getting clients to a higher "shared minimum" functionalty would seem like a smaller atsk to me than doing that plus collaboration with other IM and AP developers.

MSavoritias (fae,ve), ^^^

MSavoritias (fae,ve): thanks :). Biboumi, and Slidge are also in the "modern" gateway side and did amazing work.

heh true

> It also is a question of priorities, collaboration within the XMPP ecosystem and getting clients to a higher "shared minimum" functionalty would seem like a smaller atsk to me than doing that plus collaboration with other IM and AP developers. maybe. then again we can hopefully do both 😜 ↺

> Oh yeah that's terrible with their `[M]` everywere and the bot-style conversion. That, and the frequently lost connections (just one way, or both) and "is this thing on" messages... ↺

But the idea of connecting protocols, rather than siloing people off, is good.

We're always going to the same root issue, we lack resources, most project aren't funded, or not enough. NLnet/NGI did improve the situation A LOT (and we can appreciate the huge progress made possible in the last few years in many projects thanks to them). But we need also sustainable models to work full time.

I think the issue might also be to have some common goals between the different projects ✏

Like a grouped standardization and implementation

> Like a grouped standardization and implementation 👍 ↺

That would be a good way to stop the endless fights between floss messengers (for example) by saying "pick any, it doesn't matter"

exactly. projects and communities inside and outside XMPP don't communicate enough , or pool resources towards common goals as edhelas, said

and indeed we do need sustainable models so that its not one person that waits for NLnet/NGI funds to make the project sustainable. we need new ways as goffi, said

there is so much more sharing and mutual aid we could do than just messages in a chat or "open an issue" somewhere

For example I'm working with ProcessOne (ejabberd) that is not directly part on my NLNet funding on the Muji + SFU thing. It is a pretty big thing for XMPP to have multi-participants audio-video calls and having a group of clients and servers working on it could really help.

The thing is we need to sometimes align goals, which can be difficult, we all have our life/priorities :)

While I wouldn't disagree with any of that I think it's _also_ true that we tend to be too self-critical. Maybe due to having expectations sometimes bieng too high. Which in turn may be due to us competing against some global players and e.g. Matrix' multi-million VC-funding or whatnot. In the end, we're a two-digit number of people working on specs and implementations, many of which mostly/completely in their spare time, with, as edhelas said, sometimes very different goals.

The people who do comparison between messengers should instead compare what is possible with bridges/natively between them

You could also argue that all in all, we're doing a pretty good job given these constraints.

> You could also argue that all in all, we're doing a pretty good job given these constraints. I hope that you're doing a good job ! ejabberd is my main backend 😱 ↺

Arguing that way doesn't improve anything. Think about how to improve things is always good. I just think we shouldn't feel bad about what we did up to now.

edhelas: :D

Pretty good job of doing the same thing, only with a different protocol/stack is what's sad 😢

rako: You mean like Matrix vs. XMPP?

I'd fully agree then. I'm just saying the communication _within_ the XMPP universe isn't that bad, in my book.

Holger, yes, a pretty good job - and I'm grateful for all the work being done!

agreed. if XMPP is useful for us and our friends/family we are already doing work i would say

> I'd fully agree then. I'm just saying the communication _within_ the XMPP universe isn't that bad, in my book. I'm always surprised by the relative "horizontality" of it. ↺

we need to push back on "everything needs to be XMPP" or "XMPP gobal domination" imo

we need to be a lot of small protocols and networks holding each other up. the future is diverse and multi-protocol one.

> rako: You mean like Matrix vs. XMPP? I'd say "all floss messenging apps" as a starter ↺

Oh I'm all for sticking to world domination as the end goal :D Just against feeling bad as long as we aren't there yet :D

> we need to push back on "everything needs to be XMPP" or "XMPP gobal domination" imo 👍 ↺

rako: Yeah.

So World Domination will be written using XML, pretty bold 🤔

> So World Domination will be written using XML, pretty bold 🤔 😂 ↺

And my comments above about a higher "shared minimum" were not meant as criticism, more something _I_ would prioritize. Getting rid of some fallbacks, maybe aligning terminology as seen by people using the clients.

> Oh I'm all for sticking to world domination as the end goal :D Just against feeling bad as long as we aren't there yet :D So, all protocols should be compatible with xmpp and xmpp would be the rosetta stone of them all ? ↺

> So, all protocols should be compatible with xmpp and xmpp would be the rosetta stone of them all ? This was what Jabber was originally made for, right? :) ↺

Sure, why not?

Wanna be able to chat with everyone just like I can call anyone by phone.

But these days that seems to sound like an entirely absurd requirement :D

> Wanna be able to chat with everyone just like I can call anyone by phone. SMS and now RCS seems to be it ↺

You have quite some features in RCS, E2EE, delivery/read notifications...

Yup.

> we need to push back on "everything needs to be XMPP" or "XMPP gobal domination" imo I disagree on that (well, not the domination thing, that's cleary ironic non-sense), but I'm pro XMPP everything. > we need to be a lot of small protocols and networks holding each other up. the future is diverse and multi-protocol one. Yes, that's the XEPs! And existing protocol are used when possible. ↺

Say another way, XMPP is a standard API to everything.

Libervia certainly has feature creep 😅

But made in a modular way. It's not a big frankenstein thing. ✏

Goffi Wht is the state of the AP gateway by the way ?

edhelas: working, but some bugs to fix, and I'm rushing to finish email gateway grant first.

In July I hope to be able to do at least a pre-release.

But did you finished some milestones ? :)

The AP gateway is technically fully finished. But there will be maintainance, bug fixing, and maybe new feature with time.

And currently, I know that there is at least one blocking bug, easy to fix, but I need to find time.

Okay, waiting for the release note then ✨

edhelas: if you want to try it with Movim, I'll be happy to help you, and adjust what needs to be adjusted.

I'd prefer a package / tutorial / documentation then I can deploy it when I have time

Well documentation is planed, when I have time™.

Actually there is already documentation, it just a tutorial/how to that I plan to add.

> You have quite some features in RCS, E2EE, delivery/read notifications... Plus lots of Google? Got the impression many operators just outsource RCS to them

(My gut feeling is also that SMs

...incompatibility is RCS's fault, converting messages to an unreadable mess and charging for it)

> I'd prefer a package / tutorial / documentation then I can deploy it when I have time I'd like to add my +1 to this. I would like to deploy the AP gateway and then use it to implement and test microblogging in Converse

It would be so cool to be able to access the fediverse from my XMPP client

BTW Goffi, what's the motivation for the email gateway? Do you have a specific usecase or deployment in mind?

ActivityPub gateway? are there any online that do work?

i've seen sourcecode projects, but I haven't seen actual server service, that is ready to use as a client (without deploying own server)

jc:

Oops sorry

jc

> BTW Goffi, what's the motivation for the email gateway? Do you have a specific usecase or deployment in mind? Reaching people without XMPP account, mailing list to Pubsub conversion and all communication in one place (universal inbox). ✏

> ActivityPub gateway? are there any online that do work? I do the code, I count on others to open public instances.

I also just recently heard of Movim, and it does seems pretty interesting & intiguing as XMPP alternative to Fediverse ActivityPub

okay goffi, thanks

what's name of your project btw? goffi

Libervia

oh! that's nice! I've binged yesterday search results for gateways, and it come up on top. alongside with some eingAldeiwhatother project that I can't pronounce/recall

it seems like there are 2-3 gateway projects, for activitypub-xmpp

Hi. Did I miss the discussion about team chat?

Pururin: I'm not aware of any other ap/XMPP project.

> Hi. Did I miss the discussion about team chat? check history of today.

> Actually there is already documentation, it just a tutorial/how to that I plan to add. This is the last message I have. I just joined. ↺

Goffi, here is an article describing the difference between team chats and personal chats. https://blogs.gnome.org/tbernard/2018/05/16/banquets-and-barbecues/

I don't think I agree with that article, in the sense that you can't serve both usecases in one app. I think you can. Also, people use Slack for 1:1 and Telegram for large public chats, which is the opposite of what the author claims they're good for

> Goffi, here is an article describing the difference between team chats and personal chats. https://blogs.gnome.org/tbernard/2018/05/16/banquets-and-barbecues/ Yeah it's an old one I've already read it a long time ago. I could read it again though.

Snikket is of the opinion that the article is true, in the sense that their chat system is only good for smaller conversations, and that large team conversations require something more robust.

It's fine to specialize and diversity is good, but I think one can also try to cover both cases

That said, the Snikket project chat is hosted on a basic MUC... ✏

I doubt that snikket would say it's less robust then something else.

It's more about the options and the UI

Yes, but UI matters.

Snikket is mobile only so far, it's complicated to make team chat in this condition. ✏

I'm using my Snikket account thru Dino at the moment, until the web app takes off.

I'm currently going through Movim's locales.ini files to try to bring it more inline with modernxmpp's recommended terms and make it more accessible to newcomers. How should the term "chatroom" be handled when referring to both a private group chat and a public channel? Should it be left as "chatroom", changed to "group chat", or maybe "group chat or channel"?

It's Dino in this case.

Even if snikket is the name of service+client.

I appreciate Movim, but I avoided it because its UI is messy.

> I'm currently going through Movim's locales.ini files to try to bring it more inline with modernxmpp's recommended terms and make it more accessible to newcomers. How should the term "chatroom" be handled when referring to both a private group chat and a public channel? Should it be left as "chatroom", changed to "group chat", or maybe "group chat or channel"? Also, is "whispers" an acceptable term for MUC PMs? I would think that would be understandable enough ↺

Whispers seems fine

For chat room I would go for "group chat" as the most general term.

MUC

In some clients when send/receive PM, the client labels it Whispered.

Caleb Herbert: > Snikket is of the opinion that the article is true, in the sense that their chat system is only good for smaller conversations, and that large team conversations require something more robust. Agreed, MattJ ?

Sorry; I did not mean to speak for Snikket. Mea culpa.

(sorry if offtopic, but kinda bug, I don't/can't receive whispers in my Converse client. idk if this widespread, common thing. I'm new to xmpp)

I think that client doesn't support them.

In some clients like cheogram the support is also hidden by default.

xmpp:support@joinjabber.org?join

Is the better place to ask such questions

Conversations supports muc whispers, if muc management allows, so conversations forks do too...

> I appreciate Movim, but I avoided it because its UI is messy. I'm curious about why you see it as "messy" :) ? ↺

No seperate tabs for 1:1 chats and channels 😝

> I'm curious about why you see it as "messy" :) ? I haven't used it in a while, but there was a lot going on. It was very busy. I couldn't make sense of it all. ↺

> No seperate tabs for 1:1 chats and channels 😝 I'm not a fan of 2 clicks each time I need to switch between a discussion ↺

Why Movim should be like this and not most of the other XMPP clients ?

Most other xmpp clients either allow that or are mobile clients that make no seperation at all

Discord solves this by every group chat being on some "server" (think Gajim workspace) or another, except the first item on the "server" list is not a "server" at all but a list of all your 1:1 conversations

In movim you have a long list of open 1:1 chats taking up most of the side bar, and it is difficult to access the channels below.

Lots of scrolling up and down. ✏

Or constantly closing older 1:1 chats ✏

https://disroot.org/upload/0685ae87-b219-7e3c-96ad-a8db32d18b43/2025-06-24-23-32-41.png

Here's how it looks in Kori (the KaiOS app for Discord). I've selected the Beepy "server", and you can see all the "channels" within it

https://disroot.org/upload/0685ae8a-df55-7fd8-bbad-60e48876db03/2025-06-24-23-33-17.png

I don't want to share my private contact list, but basically the first item in the first screenshot will show a list of contacts (or 1:1 chats? I forget which) along with their profile pics and everything, instead of a list of channels

Hmm, I wonder if Gajim would benefit from a "automatically file 1:1 conversations in specific workspace" feature too. Maybe a plugin could be made for that? 🤔️

That can already be kind of done by setting a default workspace

default workspace per account, can indeed be already set

to facilitate separation of chats for different accounts

But can I set one default for direct chats and another for MUCs?

I suppose I could just manually file MUCs in the appropriate place whenever I join them

Gajim puts the chat in the workspace that is currently selected when you join the chat

no need for a option, the problem with 1:1 is, that if you receive a message for a closed chat

Gajim needs to decide the workspace

Ah okay

In which case it can go to the default workspace

Another idea (not sure if this is implemented anywhere) is to set conditional pinning (or maybe it should be called "raise to top" or something rather than pin

So we can have "raise always (pin)", "raise if unread messages", and "raise if unread mentions"

Similar to how we have "notify when..." at the moment

(This is just me throwing ideas; I haven't experienced it anywhere to see how it works in practice)

> This is the last message I have. I just joined. In that case I guess you did miss the discussion 🙁 ↺

I wonder if this room is archived anywhere?

https://chat.modernxmpp.org/log/modernxmpp/2025-06-24

I see reactions come nicely too!

badrihippo, you mean chats with unread messages go to the top in the list? this is the case in Gajim

Yes lovetox but more fine-grained, i.e. if I want some chats to stay in their place and not go on top unless there's a mention

So I'd put high volume chats as "raise only if mentioned" and smaller ones or ones I'm more directly involved in as "raise when there are any unread messages"

need to look but we have already two notification badges, grey count means message in muc but no meantion, blue count means mention or you want to be notified on every message

could well be that we consider that also for raising the chat already

but you would need to test this

Is this something that can be done as a plugin or would it have to be baked into Gajim directly?

nothing i would do with a plugin

are you saying you really need this?

sounded more like ideas not related to actual problems you have in a client

I'm saying I might find it useful, but not high priority or anything (also I didn't mean Gajim specifically)

> Say another way, XMPP is a standard API to everything. XMPP as a foundation is something more people should think about, but then most people who build websites would realize 80% of their needs are already met

We need a RubyOnRails/Django but based on XMPP haha

rako: Well, actually the web frontend of Libervia is built like a web framework. I did explain this years ago, when it was still called "Salut à Toi": https://www.goffi.org/b/96207aea-9bd8-4333-a346-63638c041ef7/build-decentralized-internet-with-libervia-salut

> rako: Well, actually the web frontend of Libervia is built like a web framework. I did explain this years ago, when it was still called "Salut à Toi": https://www.goffi.org/b/96207aea-9bd8-4333-a346-63638c041ef7/build-decentralized-internet-with-libervia-salut Yes but I guess every "client" has to install it right ? you can't build a web service out of it ↺

Not that it's bad, but it's not what's expected from "builders"

I don't get your point, you can make a web service, and only need a browser to access it, no XMPP client.

The point is that the web frontend is build around templating, and you can use XMPP features easily. For instance, no need to handle account, it's your XMPP JID. Admin is admin JID. You can use Pubsub to store data, with automatic cache. It's decentralized by default.

So it's exactly what you were saying just above.

> In movim you have a long list of open 1:1 chats taking up most of the side bar, and it is difficult to access the channels below. https://github.com/movim/movim/commit/5cb483ace8983af2d7e3c3e8f30de733bf2e091f ↺

Wow that's cool to see a user feedback taken into account so quickly, congrats edhelas :) .

> So it's exactly what you were saying just above. I'm not talking about decentralized services, but about centralized services. They're not better, but they're were people and developers are so my point was to make their lives easier while still using XMPP as a backend. I don't need to install anything to go to gitlab.com or to mov.im; that's the very nice experience I'd love to see for users. For developers of classical stacks that means having a plug-and-play framework like RoR or Django to quickly build apps

🫶

rako: the framework stuff I'm taking about is "a plug-and-play framework like RoR or Django to quickly build apps", it uses XMPP features (suck as Pubsub for storing data) to make developer life easier, but it can be use to make a centralised website (actually the official web page at libervia.org is done with it). It's explained in the blog post that I've linked above. The free decentralisation is bonus because XMPP is used, and optional.

It can even be used to generate static websites.

What about "follow" instead of "subscribe"? That might make more sense to people coming from social media platforms

goffi: makes sense ! I didn't know about that, I need to dive in more before talking 🙂

>> In movim you have a long list of open 1:1 chats taking up most of the side bar, and it is difficult to access the channels below. > https://github.com/movim/movim/commit/5cb483ace8983af2d7e3c3e8f30de733bf2e091f 👍 ↺

> What about "follow" instead of "subscribe"? That might make more sense to people coming from social media platforms Kris, opinions? ↺

I find follow terrible as a term for that.

So stick with "subscribe"?

I guess

Can't think of something better

"share your status"

I think this is for the blog in movim

It's kind of both, it's all through XMPP's subscriptions

> [...] large team conversations require something more robust FWIW I think "robust" is not the right term here. If I wanted Snikket to support "team chat" use cases I would design it differently, not more robustly.

It really deserves a blog post with some concrete examples, because this comes up a lot and I just end up repeating myself in MUCs whenever the topic comes up. But there are plenty of places in the UI/UX, as well as under the hood, where choices have to be made - you optimize for one thing or another thing. There are things you can do with 10 users that you can't do with 1000 users, and things you have to do with 1000 users that you don't need to do with 10 users.

And I'm not talking about performance or "robustness" or anything like that. I mean, those things do matter, but they aren't the main issue.

Some sort of paging in the interface at least

Paging and search are examples of things you really need with 1000 users that you don't need with 10, yes

(tho in-browser search might be fine with quite a bit more than one might expect)

Yeah, I've had a Snikket instance with 1000 users before for test purposes, and the UI was surprisingly (to me) snappy

Considering it hasn't been optimized for that at all

Browser vendors have spent quite some time optimizing tho, as long as you stay away from the React ;)

If the UI can be adaptive for screen size, why wouldn't be adaptive also for number of users?

Anyway I'm going to sleep. 😴

Because for small numbers you can usually ignore all the adaptations you otherwise have to implement.

Implementing is not the problem, the problem is UI right?

Similar to how finding a particular item out of 10 is easy by linear search, while finding one out of 10 billion might need fancy algorithms

Yeah but we are not in those extremes at all.

We talk about UI not adapted for 2 use cases similar but not the same.

I may have been confused about the topic as it seem to be overlapping with the topic of every other channel today.

The way I got it is that some are arguing that you can't have a UI which can do well both team chat and personal chat.

Making the UI adapt to different use cases is not implementing changes?

I was thinking of the paging example above.

And I think it's doable. But my team chat experience may differ of course, we may not be expecting the same things.

Friends and family vs Team chat vs Kubernetes Team chat vs XMPP project team chat all seem to be different :)

Anyway it's really time for sleep for me. Good night 👋

a startup with <50 employees and a multinational corporation with 500 000 employees will have different requiremetns :)