Groupchat 3.0 development - 2025-09-26

Hi

https://docs.ejabberd.im/developer/xmpp-clients-bots/extensions/muc-sub/

Is something like this planned for gc3?

Also, any news?

So this is where the Next Big Thing is happening

Hopefully?

I would love to hear that some of the ejabberd devs are on board. So far it seems to be more of an Prosody and maybe a little Openfire effort?

(1) Standard MUC being presence-based sucks for modern use cases (2) therefore everyone made custom extensions to address that, ProcessOne's MUC/Sub being one of those (3) MIX would've fixed that and other things but the community lost interest (4) GC3 is another attempt at fixing that (and maybe a few other things), yes.

We talked about it during the summit.

Personally I'm still not fully convinced of the day-and-night difference between MIX and GC3 but whatever solution finally ends up being adopted is good. If GC3 is it, I'd assume ejabberd will eventually support it as well.

For me it is really mostly about compatibility. MIX being a totally seperate thing is what killed it.

> For me it is really mostly about compatibility. MIX being a totally seperate thing is what killed it. 👆️ ↺

Yes that's MattJ's main argument as well, but that obviously depends on whether a compatibility layer (XEP-0408) is feasible or not. Answer depends on who you ask.

What I mean is that both MIX and GC3 are different from MUC and need some kind of mapping if they want to be compatible from MUC. I'm not sure the assumption that this mapping is impossible for MIX but straightforward for GC3 is true.

*compatible with MUC.

Possible or not aside, I guess if someone was going to do it they would have in the past 3606 days and counting https://www.moparisthebest.com/mix/

moparisthebest make that counter a countdown ! 😈

to what ?!?!?!? 😰

Maybe add another one for GC3? Because our ecosystem moves slowly everywhere.

Only parts of the community picked up MIX, some important projects didn't, that also demotivates the parts that did.

(And if you ask the Tigase guys then yes, someone actually did it in those past days.)

to be clear I only care about the public federated network, no backwards compat specified, planned, or implemented means it was dead from the start

I don't care what closed tigase deployments do any more than I care about what WhatsApp or zoom does /shrug

moparisthebest: Huh?

I am guessing Tigrase has some commercial deployments using MIX?

non-federated ones

Maybe but the code is Open Source and deployed on tigase.im and whatever.

And XEP-0408 is not production-ready but certainly documents that compat was "specified and planned".

But I have zero interest in this kind of discussion. As I said if GC4 is it then I'm happy.

GC3 :D

where is compat specified ? (Or planned for that matter?)

that the code is open doesn't matter either, if the spec isn't usable on the public federated network it's completely uninteresting to me is what I'm saying

moparisthebest: I have no idea whether you're just trying to say that XEP-0408 is not production-usable as-is or whether you're trying to say something entirely different or whether you just hate MIX. So I have no idea how to respond to your words in a sensible way.

I'm totally fine with an actual technical discussion on mapping MIX or GC3 to MUC but not in figuring out who's better at bashing. ✏

I'm just saying mix isn't usable as-is on the public federated network, that's all

There's missing pieces in the spec because it's not done yet. That's all?

But there's enough spec to make it somewhat usable. Maybe PoC level. Obviously way more than GC3 has today.

Anyway if you'd just explain that view without that weird Tigase/MIX bashing it would be way easy easier for me to grasp.

ProcessOne's MUC/Sub is WhatsApp. Tigase' MIX is open standard.

"maybe PoC level" with no movement for a decade smells dead to me

MIX seems dead, yes. But there's been some implementation work during the past decade which is precisely why I'm not quite as happy l with just starting from scratch again, given our super-scarce manpower.

All I said is that I'm not quite sure I fully buy the technical reasoning for us letting MIX die. And a MIX-bashing counter + "Tigase goes WhatsApp" isn't exactly technical arguments that would convince me.

the mix counter itself is so old it predates GC3 even being a concept the "technical argument" is simply it's not backwards compatible with MUC and in over a decade no one attempted to spec or implement that, without which it's useless for the public federated network

I don't know how good Tigase' XEP-0408 implementation is, Tigase people claimed it works while Matt said he failed to join. But why you keep repeating that it wasn't even attempted is beyond me.

I mean I can totally imagine you having an actual point but why not just make that point rather than trying so hard to stick that bashing level?

If it's just "I don't know why but MIX is dead" then we agree and there's no point in discussing.

> (1) Standard MUC being presence-based sucks for modern use cases (2) therefore everyone made custom extensions to address that, ProcessOne's MUC/Sub being one of those (3) MIX would've fixed that and other things but the community lost interest (4) GC3 is another attempt at fixing that (and maybe a few other things), yes. I don't think people generally are in agreement about (1) being presence based is fine for most purposes. I've heard it has scaling problems at some point but not sure what that point is ↺

singpolyma: You're not notified of messages while offline, which is a basic requirement for modern IM, no?

We use weird hacks to pretend you're present while you aren't to work around that issue.

I don't know why that would be a requirement for anyone. Mostly I'm never ever offline because I have my phone signed it and it's basically never "offline". Actually I use iPhone now so it uses push notifications and is thus literally never offline

I guess that's your way of saying "I'm fine with that hack".

In which case I'd think there's no pressing issue to get rid of MUC in the first place.

Many others aren't happy with the server keeping a stream management session open for disconnected devices just to avoid sending presence-unavailable to MUC rooms.

I mean I could imagine (re)defining the presence state of disconnected devices to "last known presence" as long as we assume them to be push-reachable (how long would that be?) but I haven't seen that being discussed outside of those XEP-0198 hacks.

Yes any push system needs some way to indicate presence that isn't the same as just "TCP socket open" for sure. This affect more than MUC

I'm not disagreeing but I think that would require more fundamental changes. For example, so far we make the assumption that a presence-available client is responsive (e.g. to IQs), which disconnected push clients may well not be. Monal is fighting hard against iOS to go that route …

As a user, I want my membership in a room to be completely unrelated to whether I'm logged in anywhere

> As a user, I want my membership in a room to be completely unrelated to whether I'm logged in anywhere Yes this is a different thing. We have that in MUC already too but it's not the same as the low level technical question of "which stanzas should the MUC relay to your server and when" which is what we were discussing ↺

> I mean I can totally imagine you having an actual point but why not just make that point rather than trying so hard to stick that bashing level? what bashing ? I certainly didn't mean anything to come off that way :/ ↺