Modern XMPP project discussion - 2024-09-28

Would the disappearing messages/pictures/videos feature require a new XEP?

> ajeremias: you can, I guess it might be a wrong permission on the omemo pep node of some client there. > If you use gajim to join that room you can look at the xmpp stanzas on what exactly is the error., like who is responsible what a mess. can i fill a bug in conversations? would u help? ↺

> Would the disappearing messages/pictures/videos feature require a new XEP? already exists :) https://xmpp.org/extensions/xep-0466.html

as usual needs implementations :/

> https://pad.nixnet.services/WJm97HA9SJaURGhxNqGOcA was reading this and at least for now my two main questions that also make me lean to MIX is: - is there a plan for authenticated access to change the configuration in the group chat? My thinking goes mostly so that servers can't change configuration freely and it you actually need a token or something to change things. - the other questions I have is Supposed I want to do something else instead of ACLs is that possible to be added on top? as a seperate XEP of course. I see Hats are added so it would be easy for me to add new roles so that is covered. For context this usecase is about temporary tokens that allow a person in a room to take an "escalated" action, like blocking or deleting things for example - The other thing that concerns me is that MIX is pretty easy conceptually to be made to work in a Distributed context with no "main server". In the sense that people just have permission to post on the PubSub node and that is it. Is there any plan or easy way to make this work on MUC or am I out of luck? - I assume some kind of cryptographically assured membership is out of scope and would need to be a different XEP? - I also assume that making the MUC/GC3 service not deliver messages but keep them in an Inbox until they are explicitly requested is also another XEP? these are some of the questions that at least have come up from me reading MIX and MUC. if its not relevant to this room I can move this elsewhere of course ^^

I understand most of the requirements in your list, I think. But I'm not sure I see how MIX improves many (any?) of them

For example, why can a server change a MUC config but not a MIX config?

And why is posting to a pubsub node less centralised than posting to a MUC?

If anything, it's the opposite. We already have specs (implemented, even) which can distribute a MUC across multiple servers. I don't want to say it definitely doesn't exist, but I can't recall any such spec for pubsub.

oh wow, where is that implemented?

interesting!

raucao: the only implementation I know is closed-source (M-Link), though I think Guus was looking at implementing it in Openfire at some point, and I'd certainly be interested in it in Prosody (it just never rose to the top of my priority list) ✏

ah ok, thx

what's the XEP? search brings up two without numbers

It has a weird name, because "distributed MUC" was already taken: https://xmpp.org/extensions/xep-0289.html

thanks. also found https://www.isode.com/whitepaper/federated-multi-user-chat/ which is for that XEP

Basically there was a point where there was lots of interest in this topic. Three approaches were written down, and that one was the most successful

In that it was successfully implemented and deployed, and it's the one most people preferred conceptually compared to the others

it would definitely be fantastic for resilience of communities

if a server or domain goes offline for any reason

no matter the reasons

> I understand most of the requirements in your list, I think. But I'm not sure I see how MIX improves many (any?) of them regarding the config and the membership both of them are pubsub for example. which means its very easy to make a xep that puts access control to that. which i already know which ACL scheme I want. > For example, why can a server change a MUC config but not a MIX config? because of the pubsub thing. afaik MUC is just a stanza on the server. which is also why the XEP you sent says: > This allows an FMUC node to proxy for another JID, so should only be deployed in scenarios where either the FMUC nodes are trusted, or it is known that the users of an FMUC node are in the same security domain as the FMUC node itself. and I started to have doubts. to put it simply I may want a room mirrored but not give full control of the room. Just broadcast capabilities. > And why is posting to a pubsub node less centralised than posting to a MUC? my thinking for that goes that pubsub is just hosting a node that streams the messages. which also have the nice side effect of making it almost a push not pull architecture. MUC reading the XEP it seems to be just stanzas somewhere. there is no node to subscribe to. which is why the XEP you linked works how it does. In a sense mirroring the whole room as is and acting as the room essentially. The ACL alternative, the cryptographic membership and the Inbox thing are not Defined in MIX yeah. I was just interested if they can be added at some point ✏

specifically also FMUC assumes all the rooms are "equal" which is not really what I am thinking personally. In the sense that "rooms" and participants will not always have a full view of all rooms and participants that are in the room. like a multicast architecture. where you have: node 1 that connects to node 2 and node 3 that are also in the room. and node 2 may relay messages to node 4 and 5. but these nodes dont have to necesserily know or cant know that node 3 exists. other than seeing their messages that are relayed from node 1 that is.

raucao, https://wiki.xmpp.org/web/MUC_Extensions#Federation_/_Decentralization longer list

I do think federated MUCs are moot fwiw.

its the only way in a p2p context /shurg

> I do think federated MUCs are moot fwiw. moot how? ↺

MSavoritias (fae,ve), when you say inbox, do you mean MAM?

raucao: What use case is there for it exactly?

i already explained it

it keeps chatrooms alive when servers or domain go down

And I mean practical, not theoretical.

that is a very practical thing

You can just move to another host ✏

If a server or domain goes offline for any reason, I'd just create another channel. ✏

you can't just move all the members automatically

Is there a need for that?

i'm not interested in defending something that is clearly not a thing

If "all you need" is configuration import/export then that's a different use-case. you don't need to sync live messages / live changes ✏

pep., exactly. My thinking is that the MUC/MIX is delivering messages to MAM always. and then if there is a connection open they are delivered, if not they are NOT sent. They are just left to MAM to be requested by the reciever when they come online. ie. a Pull not Push architecture.

then I also benefit from MAM ids for sorting ;)

pep: how is that all you need? please can we be serious

raucao, just making assumptions based on what you say here. I don't know what you need

i explained it twice now

you can disagree, but willful ignorance is not constructive

We are. Distributed channels (outside of pure p2p usecases) are a overcomplicated bondogle with very little practical use.

"you can just do x" when it's not even close to the feature we're talking about is not a solution, and it's honestly just a waste of time and attention

Kris: just because you yourself don't consider resilience important doesn't mean that everyone else does

as i already said, both servers and domains can go down for many different reasons

What resilience exactly?

You still need another host if one goes down.

you would already have the other host before it goes down, yes

At best it is a nice to have convenience feature ✏

the way XMPP currently works that would require both hosts to be completely trusting with one another which I think is one of the deal breakers.

that depends on the hosts involved

if config and membership can become completely authenticated then that would make more sense imo

why don't you ask the authors of that paper and implementation

(which I also would like to see of course)

don't make assumptions about how someone wants to use xmpp

> the way XMPP currently works that would require both hosts to be completely trusting with one another which I think is one of the deal breakers. i don't think you need complete trust even ↺

but anyway, i think this convo is a waste of time

ttyl

raucao: I can't speak for others but I suspect the point they are trying to make (badly) is that your requirement is underspecified and that the problem space in general is complex enough that there is no quick and easy solution for it

raucao, maybe you actually want clustering for high availability? Some servers like Ejabberd do support that, you run multiple nodes on different servers and your users will failover when one is down. This obviously comes with its own downsides, but I don’t exactly know them as I’ve always felt like one node is more than enough for all of my usecases.

yes, already using clustering, thanks

rom1dep: yes, i think you're right. however, i'm not interested in even discussing my reasons for wanting it

(I too believe that clustering is the pragmatic "best" solution for XMPP at the moment)

it also has issues

Sure, but what doesn't ?

If you take Matrix, whose sole reason to exist is federated rooms..; it doesn't have federated identities, so if the server providing yours is down, you are out of luck

i wouldn't consider federated MUCs beneficial only for high availability ✏

And (I'm arguably not an expert there), solving that would require another, wholly different, protocol to be implemented

matrix is hilarious

Something probably closer to P2P

And XMPP has a XEP for XMPP over RELOAD : https://xmpp.org/extensions/xep-0415.html

But no implementation as far as I am aware