jdev - 2024-12-08

Is there any way for XMPP to do decentralized MUCs (or even better, MIXes) without having them become a complete mess like on Matrix? It looks like this has been tried and retracted in XEP-0281, probably due to it not working out. Maybe it could work by having the room host only be federated onto a few selected hosts by the room owner instead of just doing it the Matrix way and having the mirrors be on every user's server?

> Is there any way for XMPP to do decentralized MUCs (or even better, MIXes) without having them become a complete mess like on Matrix? It looks like this has been tried and retracted in XEP-0281, probably due to it not working out. Maybe it could work by having the room host only be federated onto a few selected hosts by the room owner instead of just doing it the Matrix way and having the mirrors be on every user's server? This is an interesting idea. ↺

> This is an interesting idea. Decentralized rooms are something a lot of Matrix fans shit on XMPP for and I do think it is a good idea, but I want it actually working and stable ↺

> Is there any way for XMPP to do decentralized MUCs (or even better, MIXes) without having them become a complete mess like on Matrix? It looks like this has been tried and retracted in XEP-0281, probably due to it not working out. Maybe it could work by having the room host only be federated onto a few selected hosts by the room owner instead of just doing it the Matrix way and having the mirrors be on every user's server? one hot master hot standby is probably going to be the best bet ↺

where one server is still responsible for the room entirely, but if it goes down its replicated to "backup" hosts

In general I think this kind of distributed MUC is probably a bad idea, but it has been done with xmpp before in specific cases where it makes sense

> In general I think this kind of distributed MUC is probably a bad idea, but it has been done with xmpp before in specific cases where it makes sense Is there any way at all to get it working reliably, or is it better left as-is? ↺

There's XEP-0289 that has some implementations, but that needs to mature. It's focussed on reducing data transfer, not necessarily 'distributing' the MUC.

>> In general I think this kind of distributed MUC is probably a bad idea, but it has been done with xmpp before in specific cases where it makes sense > Is there any way at all to get it working reliably, or is it better left as-is? "better left unreliable" ↺

zayd, depending on your usecase, clustering your server over multiple nodes so that if one goes down the others can continue working seems much more sensible than replicating everything everywhere.

"everything everywhere" would probably not be viable in any scenario, as I said, mirroring only on a few selected servers would be better if not on the origin server

I just want to have rooms not be inaccessible when hosts go down

zayd, pick a server with clustering support, dedicate a few servers for high availability of this host, this seems like a much simpler way of achieving that than switching to a replicating protocol imo.

zayd, the issue with federation-decentralized rooms is that you get all kinds of funny inconsistencies.

you trade one kind of reliability for another kind of reliability.

look at the fun you have during IRC net-splits

> zayd, pick a server with clustering support, dedicate a few servers for high availability of this host, this seems like a much simpler way of achieving that than switching to a replicating protocol imo. true, just seems like something that would be uncommon in friends-only servers, private servers, etc ↺

from confusing partial conversations to room takeovers because permissions get out of sync and then get resynced in unpredictable ways.

> zayd, the issue with federation-decentralized rooms is that you get all kinds of funny inconsistencies. yeah I dealt with Matrix for a while before coming to XMPP and saw plenty of this ↺

sucks that there's no perfect solution

I prefer the XMPP way, where there's a single source of truth for an entire room's state, including message order.

zayd, because for friends server we don’t really need many nines guaranteed availability. If my server is down for a day, so be it, I’ll fix it in due time.

> I prefer the XMPP way, where there's a single source of truth for an entire room's state, including message order. I do too, I'd much rather have things function on one server than not function on hundreds of servers ↺

*nod*

and what Link Mauve says ... oftentimes, the friends-only servers will be those with the best uptime. small user group = low load, dogfooding = high incentive to get it up again when it breaks :)

And in practice, I very rarely see servers down.

Link Mauve, I have a couple MUCs in my poezio where I drop out 1-2 times per week.

zayd, the bigger problem are small friends-only hosted on public, less reliable instances.

because then nobody in the friend group has control over the uptime and you're left powerless when something bad happens to the instance.

> and what Link Mauve says ... oftentimes, the friends-only servers will be those with the best uptime. small user group = low load, dogfooding = high incentive to get it up again when it breaks :) Or more often, just switch to something that doesn't break as often, which usually means proprietary platforms, unfortunately. ↺

or paid platforms.

In my experience, paying or being proprietary doesn’t necessarily guarantee better availability.

It's best, for users, when outages cause direct reduction in server operator's revenue. Incentives...

Or maybe an uptime leaderboard for servers. Is there one?

When was the last time you had issues with a server being down or shutting down? They all seem to be doing pretty well to me, so is this even a real problem?

pulkomandy, see above ("jonas’> Link Mauve, I have a couple MUCs in my poezio where I drop out 1-2 times per week.")

pulkomandy: Some channel servers reboot almost every day, and clients don't auto-reconnect. "Issues" depend on perspective, whether it stopped you from doing something, or if you observed it... Apparently there is some monitoring and data. https://status.conversations.im/historical/

If you monitor a few channels like xmpp ops, and server and client related software channels, you see server issues discussed "often".

> I prefer the XMPP way, where there's a single source of truth for an entire room's state, including message order. Not sure what "truth" is here, but in recent memory, I've received a day or so old message, and the client later resorted messages so it no longer was displayed in order received. ↺

opinionplatform_org_3, everything you mention sounds like client issues, not reconnecting properly, not sorting messages like you want, etc.

Rebooting daily is not a client issue, but sure. Also, "unable to reach" in linked status.conversations... data _could be_ network issues.

> Rebooting daily is not a client issue, but sure. Rebooting daily is not an issue at all. Only if this causes trouble it's an issue.

>> Rebooting daily is not a client issue, but sure. > Rebooting daily is not an issue at all. Only if this causes trouble it's an issue. It certainly causes downtime and inability to send messages, if someone wants to. LOL ↺

Everyone knows "a problem ignored (or not observed) is a problem solved". :)

Your client should reconnect once the server is back after a few minutes and send the message. If your not able that's a client issue. > LOL No need to be passive aggressive. *plonk*

Martin: plonk back. 🤣

> Is there any way for XMPP to do decentralized MUCs (or even better, MIXes) without having them become a complete mess like on Matrix? It looks like this has been tried and retracted in XEP-0281, probably due to it not working out. Maybe it could work by having the room host only be federated onto a few selected hosts by the room owner instead of just doing it the Matrix way and having the mirrors be on every user's server? I also like the concept of more "federation" or decentralization, but can see how distributing mucs may threaten operators' control over their mucs. ↺

> When was the last time you had issues with a server being down or shutting down? They all seem to be doing pretty well to me, so is this even a real problem? This week. ↺

>> Is there any way for XMPP to do decentralized MUCs (or even better, MIXes) without having them become a complete mess like on Matrix? It looks like this has been tried and retracted in XEP-0281, probably due to it not working out. Maybe it could work by having the room host only be federated onto a few selected hosts by the room owner instead of just doing it the Matrix way and having the mirrors be on every user's server? > I also like the concept of more "federation" or decentralization, but can see how distributing mucs may threaten operators' control over their mucs. That'd be a good thing. I don't want idiot admins to e.g. break multidevice. I don't want everything to go down because the idiot admin felt like tinkering with the server ↺

Ultimately I'd prefer more of an almost P2P model with some "buffer" or "cache" servers.

In the last couple weeks I've seen multiple (3-4) public mucs go down/disappear because the server operators did not like something about the mucs. (Too many bots maybe, but something never publicly stated, AFAIK)

I've seen one muc operator announce a small public muc may go away for indeterminate time, because they have to move their residence.

from server issues to client issues to social issues. what's your point? ;)

doge: If you're not happy with an "idiot admin" change server, preverably become your own admin.

Network effect.

> Ultimately I'd prefer more of an almost P2P model with some "buffer" or "cache" servers. This. ↺

Still, if you're not happy with your admin, refrain from calling them idiot but rather become your own admin…

> from server issues to client issues to social issues. what's your point? ;) All are connected. Tech doesn't exist in a vacuum and is only as good as its social impact. ↺

> Still, if you're not happy with your admin, refrain from calling them idiot but rather become your own admin… Network effect. ↺

> from server issues to client issues to social issues. what's your point? ;) Examples why zayd is correct to suggest better muc distribution, for less vulnerability to individual (centralized) server ops issues. ↺

IMHO what xmpp currently has for group chats is just so bad top to bottom, wrong in almost every way. Beginning with even the simplest things, like per device leave-join instead of per account. AFAIK no other chat platform does this because this idea is so bad you almost have to intentionally try to make things wrong to come up with it on your own. <rant/>

doge, IRC does, and that’s why it got designed that way in MUC as well.

I don't think IRC even has the notion of multi-device, so it doesn't really count. Not to mention that it's just unusable, so it doesn't count because of that as well.

doge, not sure against what you are arguing, look up the date when MUC was invented

the kind of problem is, that with all of its shortcomings, its still good enough for most things, so reinventing it is not very attractive.

" Hey, it's not just garbage, it is also old and outdated garbage, so it's alright."

doge, people are working on this problem. ranting helps nobody

it is what it is, you cannot change the past, not sure why you are ranting against something developed 2 decades ago

> " Hey, it's not just garbage, it is also old and outdated garbage, so it's alright." Sent from a device that uses "garbage protocol invented in the 80-90' like TCP/HTTP/IP..." ↺

and as said, it is indeed alright, you are using it just now to chat with me, and i use it everyday to chat to other people, the same as thousands of people use IRC to chat with people

I'm not sure about two decades ago but like 15 years ago it should have already been thrown out of the window for sure because already then (2010) everybody was startint to have multiple devices.

>> " Hey, it's not just garbage, it is also old and outdated garbage, so it's alright." > Sent from a device that uses "garbage protocol invented in the 80-90' like TCP/HTTP/IP..." Well, the minor difference is that they are not garbage like the MUCs... ↺

Oh you didn't looked closer I think ✨

> I'm not sure about two decades ago but like 15 years ago it should have already been thrown out of the window for sure because already then (2010) everybody was startint to have multiple devices. But even then, I don't see how it would have made sense to make join-leave per device, not per account ever at any point in time at all, when XMPP already had support for one account for multiple devices... ↺

you are cocky to no end, talking shit about people invented a protocol that to this day exist and is in use every day

doge I guess it's time to buy a DeLorean and fix that !

but thankfully you arrived now to show the world how its done, we are all waiting

It's time to just throw it out of the window.. always has been tbh

> but thankfully you arrived now to show the world how its done, we are all waiting Look at literally any popular messenger with multidevice... ↺

doge: join/leave per account would be annoying. I like to follow MUCs at my computer that I don't want to follow from my mobile when I'm on the road.

why

definitely not what most people expect. i don't know if C for example even lets you untick autojoin, or at least doesn't make it obvious

Per account room affiliation exists. Register an entity as a member, and you're well on your way.

With that, it mostly is an implementation/presentation challenge. Converse.js went down that road, if I remember correctly.

> why Because on the road I don't have time and need to follow every busy development muc. So for me it's a feature to be able to join/leave on a device base.

> IMHO what xmpp currently has for group chats is just so bad top to bottom, wrong in almost every way. Beginning with even the simplest things, like per device leave-join instead of per account. AFAIK no other chat platform does this because this idea is so bad you almost have to intentionally try to make things wrong to come up with it on your own. > <rant/> This per device leave join instead of per account is a myth. We have per account leave join as well as presence indication. This is the same as eg discord ↺

>> why > Because on the road I don't have time and need to follow every busy development muc. So for me it's a feature to be able to join/leave on a device base. do you have notifications on for every chatroom? otherwise how is this a problem ↺

>> IMHO what xmpp currently has for group chats is just so bad top to bottom, wrong in almost every way. Beginning with even the simplest things, like per device leave-join instead of per account. AFAIK no other chat platform does this because this idea is so bad you almost have to intentionally try to make things wrong to come up with it on your own. >> <rant/> > This per device leave join instead of per account is a myth. We have per account leave join as well as presence indication. This is the same as eg discord And how people end up with different nicknames per device? Sometimes you can't even join from a second device with the same nickname... ↺

doge: 0045 allows multiple presence, and allows that to be with unrelated nicks too

a default nick can be specified per account and per MUC (as part of bookmarks)

You can definitely join from as many device as you want with the same nickname if it's all the same account

yep

That has failed for me and a friend. One day it randomly stopped letting him join from the other device so he had to change his nick on that device. So now we have "koba" and "koba_" in the same chat.... And for me, it fails with a particular groupchat. I'm pretty sure that's the fault of that groupchat's server software being particularly outdated and dumb, but then again this problem couldn't exist if join/leave weren't per device

What's the point of type="headline" in <message>s? I get that in pubsub messages from my server, yet I don't see that in the pubsub spec. So can't rely on it being there? Is it completely superfluous?

Hadn't seen this section before, https://xmpp.org/extensions/xep-0060.html#impl-offline

> That has failed for me and a friend. One day it randomly stopped letting him join from the other device so he had to change his nick on that device. So now we have "koba" and "koba_" in the same chat.... > And for me, it fails with a particular groupchat. I'm pretty sure that's the fault of that groupchat's server software being particularly outdated and dumb, but then again this problem couldn't exist if join/leave weren't per device Has nothing to do with mythical join/leave per device it's just a bug if true ↺

doge: type=headline means don't deliver offline

> IMHO what xmpp currently has for group chats is just so bad top to bottom, wrong in almost every way. Beginning with even the simplest things, like per device leave-join instead of per account. AFAIK no other chat platform does this because this idea is so bad you almost have to intentionally try to make things wrong to come up with it on your own. > <rant/> 👍 ↺

> IMHO what xmpp currently has for group chats is just so bad top to bottom, wrong in almost every way. Beginning with even the simplest things, like per device leave-join instead of per account. AFAIK no other chat platform does this because this idea is so bad you almost have to intentionally try to make things wrong to come up with it on your own. > <rant/> Is anyone currently working on MIX? I've heard there's scalability issues with it. But yes, MUC is a pain in the ass ↺

Probably the worst thing about it is people duplicating when they attempt to change their nick

zayd: kaidan has MIX, so use that if you want (and be unable to talk to people in MUCs)

wgreenhouse, Kaidan got MIX already? That actually works best for me, I was going to be writing a client in QXmpp, the same library it uses

but do any mobile clients support the MIX thing

When is there going to be a Prosody module for it though?

kaidan exists as a mobile client

I think it wasn't particularly usable when I tried it

yeah I was about to say, Qt Quick can be used to target mobile to varying degrees of usability

my understanding is no explicit server support is needed since it's "just" pubsub

MIX started out as a good idea but the final spec is so far from that I don't see the point

wgreenhouse: unfortunately it stopped being just pubsub a long time ago

Just pubsub I could probably get behind

I don't think incompatibility with every existing client is ever a good idea, for chestertons-fence reasons

I honestly just really like MUC it's well designed and battle tested. But I did like the idea of pubsub only until it wasn't that

> Your client should reconnect once the server is back after a few minutes and send the message. If your not able that's a client issue. >> LOL > No need to be passive aggressive. *plonk* Dino and conversations (and forks) have this issue though so it is an issue sadly ↺

TBF it's partly a server issue if the server kicks everyone out on restart (especially if it doesn't tell them!). But I agree some apps need to be better about rejoining. ✏

not telling them is the default crashing behavior that needs to be handled most, the divestos muc runs ejabberd and reboots daily and that's the only I notice clients never rejoin automatically