XSF Discussion - 2022-05-02

> Link Mauve, but we still do not have push notifications for offline users in MUC as there are no offline users in MUC AFAIR Users can be allowed to register themselves with a MUC, which gives them permanent membership and offline status when they're away.

this topic could be a task to fund via fiscal hosting to improve the situation

Thanks Andrzej

jcbrand, is there a XEP for that? as I do not recall. I do not like the idea of MUC sending pushes to push component - those in my opinion should be generated by my xmpp server to have more control of what and when is pushed

Andrzej: XEP-0045 lets users register themselves (although there is some ambiguity around registered nicks as Guus has uncovered). Sending pushes to offline users is not documented though. There's also XEP-437, which is kinda related, but something else: https://xmpp.org/extensions/xep-0437.html

> I do not like the idea of MUC sending pushes to push component - those in my opinion should be generated by my xmpp server to have more control of what and when is pushed Sounds like an implementation detail to me.

Andrzej: The whole approach of registering yourself in a MUC isn't well known and not all XMPP servers support it, but IMO it holds promise as it allows the possibility to be "permanently" in a MUC, even if you're currently offline

I'm more in the "evolve MUC" camp

https://xmpp.org/extensions/xep-0045.html#register

but if MIX can be backwards-compatible, then why not spend effort on that instead? could you explain the core argument of the "evolve MUC camp" perhaps? or maybe someone did on the web somewhere, for people to catch up on?

I know this feature and I'm using it as a "workaround" to get functional MUC for iOS devices

nice! does that mean siskin already does it when available for a domain/room?

raucao, yes and no. We are using registration to get notifications from MUC when we have a compatible MUC version and your server supports that. AFAIR, our way is now supported by Tigase and Prosody

Thats my thoughts too. It seems like the MUC camp takes more time to standardize more XEPs around MUCs. All for bringing it up to par with MIX. Why not just go with MIX though? Of course it needs dev time and stuff. But MUC extensions need too. Plus the whole thing of getting more things standardized and voted for

MIX is not exactly the graal either. It's just another set of trade-offs, that may correspond more to current use-cases. I'm not sure MUC is "being brought up to par with MIX", as in MIX isn't a goal per-se

Why throw away a decade or two of funcioning code?

who says you have to throw it away? that's the point of backwards compatibility, no?

For me it's more a question of "do we want to get rid of everything and redo the world every n years or do we want to be able to change"

> It's just another set of trade-offs, that may correspond more to current use-cases so we don't want to cover both older and current use cases by way of supporting both?

> For me it's more a question of "do we want to get rid of everything and redo the world every n years or do we want to be able to change" clearly, there have been more chat protocols in the meantime than one can count, to learn from for a standard that should last for a very long time

anyway, would be great if there were a page that explains why MIX isn't the one we want

raucao, any compatibility between two different protocols will be sub-par, since there are differences anyway.

pep, if we would decide to create a standarized and documented way for persistent joining as MUC occupant that could be OK for me

but as users expect to join the same rooms on all devices, using presence to join is problematic at best

mod_minimix? :)

Andrzej, XEP-0402 does a lot of that way.

It’s still based on presence, but clients will know exactly when to join or to leave a MUC.

(fwiw I don't expect this ^, but it's ok, I guess WhatsApp users have only one device anyway so they probably would) ✏

i just want to implement modern slack-like groupchat, and whatever works for that is fine. offline membership is important for that. however, every time someone mentions MIX somewhere, there are non-specific answers as to why people don't want to implement it, so documenting the reasons properly would help app developers like me a lot

pep, XEP-0402 only let clients know where it should join once it is connected and running, but does not solve PUSH notifications for offline devices, etc.

so, yes, another XEP which solves one of the list of issues I have with MUC

raucao, you have a lot of that in the standards@ mailing list archives.

It’s archived for a reason. :)

We could do a better job at sorting that though

telling me to wade through a mailing list is not exactly helpful. i don't want to read conversation threads, but just two paragraphs mentioning the main reasons

if they are that clear, then it should be easy to document, no?

I don’t think someone did the work of summarising the threads yet.

You could do it if you feel like it, I personally don’t.

Personally I'd say people don't see obvious benefits, combined with MUC isn't that far off, and we already lack developer time.

> if we would decide to create a standarized and documented way for persistent joining as MUC occupant that could be OK for me same for me as a client dev

for me MIX is cleaner and easier to understand than MUC, but that is my opinion. MIX requires time to implement while MUC parts are usually ready to use ✏

for my client, i'm happy to spend time on implementing MIX, but it's useless if our room server doesn't support backwards-compatible MIX

a bit of a chicken-and-egg problem

that is why I worked on MIX on the server side and in the clients

Andrzej: how do you solve the issue of sync after s2s failure with a remote MIX service?

I.e. messages were exchanged which may not be in the user's MAM

well, for 2 years I'm waiting on Kev who promised to write up his proposal to send within MIX message the id of the previous message send from the MIX component..

but, MIX can work even without support for local MAM storage for MIX messages, that "solves" this issue

It can, but does it in practice? Implementation choices matter. Like JC earlier wrote that whether pushes go via the user account or direct to the push service is an "implementation detail". It does matter that we solve these things consistently across implementations.

MattJ, in Siskin IM and Beagle IM it works without local MAM storage just fine

and I agree that solution for MUC issues consistent across implementation would be good

and not only for MUC but also for backward compatibility MUC support in MIX if needed

I don't mean just MUC, but also that there are non-obvious gaps in MIX that need solving

In any case, MIX pushes would go to the user account, and I think MUC should do the same

yes, that would be the best. That is why I'm not against improving MUC, but I focus on MIX

MattJ, in Prosody you even do that 😉

Exactly

Andrzej I just Googled and found a XEP that I myself wrote which documents the approach of registering for a room and then getting mention notifications: https://xmpp.org/extensions/xep-0452.html#sect-idm44866352584016

(completely slipped my mind, I don't always remember which XEP ideas I actually wrote, and which ones I only thought about one day writing)

this one could work as well as what we already have, just a different field and different payload in the notification

I agree it would be nice to have an informational XEP which collects all the ways to make MUCs "modern". * XEP-0452: MUC Mention Notifications https://xmpp.org/extensions/xep-0452.html * XEP-0425 Message Moderation https://xmpp.org/extensions/xep-0425.html * XEP-0436 MUC Presence versioning https://xmpp.org/extensions/xep-0436.xml * XEP-0437 Room activity indicators https://xmpp.org/extensions/xep-0437.html

Also XEP-0402 PEP native bookmarks: https://xmpp.org/extensions/xep-0402.html

What else am I missing?

> Link Mauve escribió: > raucao, you have a lot of that in the standards@ mailing list archives. > It’s archived for a reason. :) > pep. escribió: > We could do a better job at sorting that though planned :-)

https://xmpp.org/extensions/xep-0463.html MUC Affiliations Versioning ? :-°

Yes, that's a good one as well

> jcbrand escribió: > I agree it would be nice to have an informational XEP which collects all the ways to make MUCs "modern". > * XEP-0452: MUC Mention Notifications https://xmpp.org/extensions/xep-0452.html > * XEP-0425 Message Moderation https://xmpp.org/extensions/xep-0425.html > * XEP-0436 MUC Presence versioning https://xmpp.org/extensions/xep-0436.xml > * XEP-0437 Room activity indicators https://xmpp.org/extensions/xep-0437.html +1

Feels like we have most of the pieces of the puzzle, but they're scattered across XEPs (what else is new?) and we might just need to bring everything into a coherent whole

XEP-XXX: Modern MUC 😃

Gonna bikeshed the name, this word is so empty of meaning :x

Yeah, I'm not 100% serious

:)

jcbrand: send a PR for Compliance Suite 2023?

Unless you all like it, then it was totally my idea

Ge0rG, that's ortogonal?

Ge0rG: Yeah might be something to handle with compliance suites, probably better so that things can evolve over time

pep.: the CS document has a section of notable mentions that could well use something like this

BTW, I don't have anything against MIX per se, but I have a strong bias towards already existing and running code as opposed to the siren call of the complete rewrite that fixes everything. I've been burned by Second System Syndrome before.

Especially when developer resources are tight

pep. XEP-XXX Nicer MUCs 😉

heh

> but I have a strong bias towards already existing and running code as opposed to the siren call of the complete rewrite that fixes everything. Particularly because in my work as XMPP or IM consultant/contractor, I've never met a client who's like "Yeah, please go ahead and spend months writing something from scratch" They are choosing XMPP because they believe there already exists good libraries, servers and clients.

I agree, you can write a client that publish a message to a MUC in a few days

You can spend years of finding a way to fix your MUC implementation properly

Pareto principle. You can get 80% of the functionality in the first 20% of the time. The next 80% of your time is spent implementing the remaining 20% of the functionality

I don't think that's specific to MUC tbh. It's just intensified because MUC is big

I am a user, and i listened carefully the discussion. The big question we first have to answer is : "do we really want offline notifications?". Me for my part answers "no". I would turn them off.

That's irrelevant, of course you can turn them off if you choose

But most people like to know they received something

So we need to support that extremely common requirement

Obvious answer to MUC vs. MIX is "invent a third solution".

MAX

MUCTRIX

> MUCTRIX 4: Maybe this one will be good

Hmm sounds oddly familiar and somehow I'm prematurely disappointed... 🤔

MUCTRIX 4 is pretty Meta indeed, that's why

> Hmm sounds oddly familiar and somehow I'm prematurely disappointed... 🤔 Same

> <Holger> Obvious answer to MUC vs. MIX is "invent a third solution". another..?

in essence go back to MEP?

and dump all notifications burden in there ™️? 😱

Hey, it's XMPP Day (at least in the States): 5.2.22 ;-)

Right... almost forgot 😬

I missed the European day back on February 5.

Was it European or "World minus US" xmpp day 🤔😁 Actually i don't really know which countries beside the US use mm/dd/yy 🤔

I think Canada does.

Well, it's complicated: https://en.wikipedia.org/wiki/Date_format_by_country

s/3601/8601/

I think - when reading the wiki article - Canada is one of the few or the only one doing it correctly 😁 https://en.m.wikipedia.org/wiki/Date_and_time_notation_in_Canada > The Government of Canada recommends that all-numeric dates in both English and French use the YYYY-MM-DD format codified in ISO 8601

What the government recommends is not always what people do. ;-)

> Well, it's complicated: https://en.wikipedia.org/wiki/Date_format_by_country Ahh that's a good one 👍

happy american xmpp day to you too stpeter

Cheers!