XSF Discussion - 2024-05-30

> Muc isn't anything like pubsub at all, that's kind of the problem with it, from each client you join a room, but can never know if you are still in the room without constantly asking 💀 will this be fixed with MUX?

or maybe its a big departure from how it currently works and its just the self-ping thing atm

So Pubsub is not prone to silent misses (why? how can the client be _sure_ that they are being published to, any more than the client could be sure that they get messages delivered to?), does have MUC something which pubsub doesn't have (I assumed that the many-to-many communication inherent to MUC can't be provided by pubsub, being 1-to-many)? I take it from Daniel's response there isn't?

manday: generic pubsub does not care about your online status like MUC does

I think the problem is exaggerated, and there are better solutions than "constantly asking" the MUC if you are still in it. You are always still in it, if everything is functioning correctly. The problem is that in some cases (server crashes or network failures) it's possible for the client to think it is still joined or for the server to think the client is still joined. By properly handling and detecting such edge cases, the problem can be resolved.

Pubsub/MIX have similar edge cases too, but because they are used a lot less then people don't fret about it as much yet 🙂

hmm. so the work is basically offloaded to the server to make sure that the group chat is up ?

and the client doesnt have to care as a result

that its up and that you are connected that is

That is my preference, yes

It's much more efficient

Prosody and Conversations almost achieve a full solution, but AFAIK Conversations does not automatically rejoin, it just let's you know you are no longer in

sure. i am just interested how it all works :D

So you have to tap a rejoin button or something ✏

so i am guessing that is the "hard fork" part of MUC and MIX

or one of them at least

gajim transparently rejoins in my experience

so it works nicely in this way

At the surface people think so, but MIX (as currently defined) does not handle s2s failure at all, and is prone to message loss and ghost participants

When I mention this, people tell me how easy it is to solve, but I say the same thing about MUC issues that people complain about 🙂

> At the surface people think so, but MIX (as currently defined) does not handle s2s failure at all, and is prone to message loss and ghost participants why? is it because it just offloads to pubsub while MUC has mechanisms for it?

handling these things would be very desirable to me as i am the server :D

the ghost participants makes sense tho.especially in bigger rooms that would become a problem really fast

MUC stores messages in the room archive, so no matter what happens you can rejoin and resync to get the real state of things. MIX (again, as currently specified) chooses to broadcast to participants and the messages are stored in each user's archive instead.

ah ok. makes sense

That's fine, until there are s2s issues and some messages don't make it to your archive

yeah

There is no sync or redelivery mechanism defined between your archive and the MIX channel

damn :/

The whole problem space is related to https://en.m.wikipedia.org/wiki/Two_Generals'_Problem

And you can make various protocol choices and shift the edge cases around, but you can never completely solve it, you just have to solve it to the level where it doesn't affect users

The client can never be 100% sure whether it is in the room (even if it pings successfully, the room could become unreachable 1 millisecond later)

like the delivered reciept yeah

Unless you make other choices which result in the server never being 100% certain the client is reachable

my thinking was that pinging all the time in various places sounds ineficient. in a p2p context at least

that is why i was thinking of a variant of multicast also

to bring network traffic down

but if MIX doesnt handle reliability well :/

Yeah, pinging is not a great solution and does not really achieve anything you can't achieve in other ways with smart protocol design ✏

i think there were some xeps around that were changing muc to a more "persistent" member lists

so maybe that is a way forward away from the constant pings

Overlapping problem, not entirely the same one. We already have persistent member lists, almost since the beginning.

They aren't used for delivery purposes though, delivery in MUC is to individual clients still

ah right. you need to make the messages as in the muc service itself a "subscription" service

> They aren't used for delivery purposes though, delivery in MUC is to individual clients still yeah i remember there is a xep to deliver to jid instead of devices thus eliminating the carbons "hack"

I think that you're referring to PMs, and yeah, my "MUX" draft takes that approach

MUX doesn't currently change how the group chat messages are delivered

I think with MAM allowing for resync and implementations handling disconnection issues more consistently, that's fine

E.g. if you restart some servers, they just come back up with an empty MUC, while all the remote clients think they are still "in" and receiving live messages. Prosody preserves remote clients across restarts now, and has done for some years. So it would be good to make that mandatory in the spec, etc.

Or at least come up with some other solution that doesn't cause silent breakage (there are other ways)

> I think that you're referring to PMs, and yeah, my "MUX" draft takes that approach i was referring to https://xmpp.org/extensions/xep-0409.html > XEP-0409: IM Routing-NG

Ah, yeah. That's outside of the context of group chats, but you're totally right that when we have that in place we could take advantage of it.

>> I think that you're referring to PMs, and yeah, my "MUX" draft takes that approach > i was referring to https://xmpp.org/extensions/xep-0409.html >> XEP-0409: IM Routing-NG Why is that deferred? 😶

probably no change for like 6 months so its automatically added to deferred

yeah list change was 6 years ago

-> https://xmpp.org/extensions/xep-0409.html#appendix-revs

"we havent adressed the issue in 6 years, therefore lets put the proposed solution on hold" 🙄

its in the suggested xeps to implement to be "future" compatible with xmpp in the compliance suite

then again MIX is there too

manday: > Every time you change your XEP, you’ll provide the new version to the XMPP Editor, who’ll update the version on the website and send out an announcement to the list. If this isn’t done for more than 12 months, then the XEP will be moved off Experimental to Deferred - if this happens, another update will put it back onto Experimental. https://xmpp.org/about/standards-process/

Nothing says 'on hold' ;)

> past tense: deferred; past participle: deferred > > put off (an action or event) to a later time; postpone

if std tracks doesn't explicitly redefine that word to mean something else then i'd say it implies just that

if not, why call it that in the first place..,

the logic is also specified here https://xmpp.org/extensions/xep-0001.html#states

(not saying that this process could not be improved.)

manday: deferred is a reactive status. Deferred is not the cause of people not working on it, people not working on it is the cause of Deferred.

People are free to work on it at any time

But if every unfinished thing is treated equally then we would be drowning in unfinished ideas

These specs that fix problems we all already fixed are always scary because they only simplify for new implementations and probably introduce new edge cases

singpolyma: while i dont know enough to make a judgement i think id be fair to say that its trying to address the issue at the foundation because the curremt 'fix' looks like a workaround, no?

Maybe. But the current fix is working and widely deployed and we know it works (or at least we know any ways it doesn't). New stuff we're starting over and have to find out

you re right ofc, i understand

And for IMNG it was discussed at the summit, folks promised to try implementing and report back.

One Of These Decades We Will Get Around To That

👴

> One Of These Decades We Will Get Around To That Indeed. It's not like I've been able to find time to do it yet.