XSF Discussion - 2022-05-01

I think MIX/MUC would not be the first pair of protocols I'd think of in this regard but they certainly fall into that category (if you ignore the fact that there are ~20 years between them). But it shows that its perfectly fine to continue working on the two protocols: we have some people who believe that MUC can and should be graduately improved to meet the requirements of our "modern" times. and some people saw a need for a build-from scratch architecture of a groupchat protocol. which is certainly worth trying and exploring

And we actually have the option to run two paths of "features"

but without clear terminology, it's confusing for users. one should not have to learn protocol acronyms just to join a chat room. someone not using the easier, centralized platforms is already a lot to ask in the first place, and then not being able to join a room, for example, causes a bad experience which then get memorized as "xmpp bad/fussy"

raucao right, but :)) they are so afraid of saying something wrong that they prefer to send only an icon. And just for a icon a day any centralized platform im does the job.

I don't think users have to know acronyms. My family is using xmpp and they don't know about xmpp, muc, mam, csi etc.. ✏

Of course not. But then we have a bigger problem. How do we replace them with simple words?

Do you need to? Do endusers need to know about technical details of the protocol?

raucao, that is, I believe, one idea of modernxmpp.org: to abstract the technical protocol terms with a more or less standardized terms for end-users

Do WhatsApp users talk about funXMPP or people browsing the web know about https, TLS etc.?

Toxi, ↑

You know i am german, my english is bad, but i try to answer you. In the 50s we decided that everyone had to learn to read and write. Was that wrong? Why should people today remain informationally illiterate? Why shouldn't we demand a little?

Because every little hurdle cuts your userbase in half and is simply unnecessary

The fact that we call it userbase shows a lot about how everything has gone wrong in the tech community imo

I was specifically replying to using MUC and MIX side by side

yes, something simpler like referring to MUC as "classic" and MIX as "modern" could help somewhat, but still makes it more confusing, and also needs at least the most popular client app UIs to adopt the terms consistently

imho

I'd love to hear good ideas for the service I run to adopt MIX while keeping the existing MUC channels intact

and without users being confused

raucao, it is possible to have MIX channels being accessed by MUC-only capable clients, so they could even be migrated to MIX as long as they would be accessible and usable with MUC

exactly, users do not need to care about MIX vs MUC

although, reaching this state requires a lot of effort

so I can do that right now with ejabberd or prosody for example? I didn't know that

a seamless migration would be perfect of course

Let not Masto and Pleroma steal the term "fediverse" from diverse federated universes which started with SMTP.

I think it is to late

To be fair.... actually I never heard fediverse in email and xmpp context, before I heard this name/word with the rise of Mastodon 🤔 "Federated" or "Federation", yes, i knew that from the beginning. But also I only started really being seriously interested in xmpp in 2015 and Mastodon in 2018... So I don't consider myself an expert.

Never heard it before mastodon either, tbh

that is true

I think those activitypub things just wanted a more fancy term than federated network.

ye

raucao, it is (proably) possible does not mean that it is implemented

that's the "reaching this state requires a lot of effort" part

flow, MIX-MUC integration depends on the implementation of MIX which you use. I worked on one and I think it works ok, so it is implemented.

Andrzej, but this is not an implemention for prosody nor ejabberd, right?

yes, but it exists

Andrzej, would be sure nice to have a writeup with the lessons learned about this (assuming there are any)

Andrzej, well, I never said that such an implementation does *not* exist :)

Andrzej: great! which one is it?

it is part of Tigase XMPP Server

> Andrzej, would be sure nice to have a writeup with the lessons learned about this (assuming there are any) yeah, that would be nice indeed!

cool, so I could test it on a different domain with tigase then, right?

lessons learned over 2 years ago...

does it include migration?

I.e. switching existing rooms?

> lessons learned over 2 years ago... Still valuable if nobody else implemented it since then

yes, you could test it. no, it supports just creation of MIX channels (using MIX protocol) but accessible then by anyone with MIX or MUC compatible client

cool, thanks

I'm wondering if we need an XEP for generic channel migration

also useful when you just want to switch providers

and could then solve that problem also

however, keeping existing chat domains is probably important for many

I do think that the best would be to migrate from MUC to MIX using the same provider as it would be optimized for storage used

right

then it would just migrate data on the existing jids

Andrzej: so after having implemented it 2 years ago, would you recommend everyone implement it these days?

Andrzej: can you give a rough estimation of the amount of effort involved in your implementation?

Mix still requires support on the server of the account joining right?

Like if this was a mix channel my server would also need support?

That alone makes it utterly useless, just deploy a muc bouncer on your server and all problems solved without mix?

Biboumi but for muc

Test

I love Xmpp, but I don't use Linux. Is it a problem if I don't use Linux and like Xmpp?

bung: no.

bung: no why would it be? I dont use linux either :)

Oh good :)

I mean it's a problem but it's unrelated to XMPP >:)

Might just be a bit of a problem if you don't use Android and like XMPP 😜

I like privacy

But some programs dont support very well on the Linux

But maybe i use other laptop

No problem?

Guus, effort was medium to large as I was building it on a full PubSub component. If I would implement only necessary parts that would be a lot simpler as I could simplify permissions checking, etc. Adding just MUC to MIX was very simple and easy

raucao, I would still suggest implementing it as it has better experience on iOS (ususally offline devices) than MUC

moparisthebest, MIX can be used without support on your local server - only for push notifications you might get a better experience if support for MIX is on your server

our clients Siskin & Beagle can work with MIX with or without support on used server for MIX

Andrzej, so what is the role of PAM nowadays?

Are clients still encouraged to include MIX channels in the user’s roster?

I haven’t played with this spec in so long…

PAM is useful for faster message sync and for sync of channels between clients

but MIX can work without it

Ah, that’s quite a lot already. ^^

Especially the latter, people get confused when they join a MUC on one client and it doesn’t appear immediately in their other clients.

that is why I prefer MIX over MUC

With XEP-0402 we have that nowadays in MUC too.

Link Mauve, but we still do not have push notifications for offline users in MUC as there are no offline users in MUC AFAIR

but yes, MUC is "getting there"

I think I saw some development towards that, but you would know better than me as I don’t follow iOS stuff closely.

Can anyone recommend any reading material on XMPP? I'm really looking for high-level overview of the philosophy behind it and stuff like that, more than how to use libraries and whatnot.

kinetik: have you read the rfc?

No, is that a good place to start?

Yes

It's certainly not a bad place to start

kinetik, perhaps this page? https://xmpp.org/about/technology-overview/

Thanks, Link Mauve, I see that page has links to the RFCs as well

btw: https://xmpp.org/rfcs/