Modern XMPP project discussion - 2024-10-03

interestingly, this topic is part of a post on the ejabberd blog that appeared after our convo here:

> What if there were a caching and resynchronization protocol for multi-user chatrooms across different servers? This could enhance the robustness of the federation without the storage burden of full content replication, offering the best of both worlds.

https://www.process-one.net/blog/matrix-and-xmpp-thoughts-on-improving-messaging-protocols-part-1/

it's really mostly a question, but i'm obviously not the only one interested in it ;)

MattJ, for GC-3, any thoughts on including fmuc or similar specs right in the XEP to improve the odds of it being implemented?

might be worth talking to the ejabberd devs if they are also thiking about this right now

also, is there some summary of the UK code sprint?

second to make it easier to make MUC distributed

a good thought out architecture (i would disagree with FMUC) would be nice to see. or at least design so that such an architecture can be done

IMHO I think a puppeteering bridge between two channels that is intentionally setup is quite ok, but if that could somehow be more streamlined or included in prosody as a module, that would be great, as the Cheogram bridge that can do this is not that easy to setup ✏

it depends how much in depth we want to go yeah. making some kind of bridge would be the easiest

> second to make it easier to make MUC distributed I really don't see the practical benefits. Unless identities become federated (and we are going peer to peer), we still depend on our own server to be available, which is largely mitigated, without protocol change, via clustering & al.

you dont have to switch at once. you can prepare pieces slowly to be distributed :) also it could lead to a better architecture with destributed being the side-effect

I agree that it isn't terribly useful and IMHO Matrix is a good example how it causes more issues than it is worth (can't easily deleted rooms and room version upgrades are a nightmare), but if you want to migrate a channel to another server for example, such a bridge could be quite useful. Also if a certain server is blocked in a country for example, a muc-muc bridge would allow easy circumvention of that.

> you dont have to switch at once. you can prepare pieces slowly to be distributed :) > also it could lead to a better architecture with destributed being the side-effect Just like Matrix has been "close to being peer-to-peer" for 6 years (not to mention federated identities, "any week from now"), I don't believe those aspects are trivial and can be rolled-out incrementally without a clearly defined and generally accepted plan beforehand ↺

> I agree that it isn't terribly useful and IMHO Matrix is a good example how it causes more issues than it is worth (can't easily deleted rooms and room version upgrades are a nightmare), but if you want to migrate a channel to another server for example, such a bridge could be quite useful. Also if a certain server is blocked in a country for example, a muc-muc bridge would allow easy circumvention of that. there's a plethora of cases and edge-cases to take into consideration and that vary depending on your threat/censorship model ↺

in the end, network-level and established solutions like VPNs/proxies/tor/… may be better and more reliable bets

I don't see the value in distributed MUC's where we all keep a copy. The main reason one might want something like this is redundancy, geographic concerns or to spread the load. But that should be a opt in server level thing where the owner explicitly configures the alt servers. You can of course do that with DNS but defining how the alt servers sync data and transparently switch back to a 'leader' server would be useful.

The problem the existing XMPP ecosystem has in my opinion is MUC's are hard to find, there needs to be a sorta 'global' index so users can find a MUC to join. It should be easy for me to search/find the 'definitive' muc for python or linux, tvshows, whatever. Same way back in the day 'freenode' was the semi authoritative place to find a opensource project's channel.

> a sorta 'global' index Something like https://search.jabber.network/ ?

exactly. But I can configure my server to have 'muc.jabber.network' and it returns that list.

You can take that a step further and actually join xsf@muc.jabber.network and when my server tries to join that it directs to xsf@muc.xmpp.org - if the xsf channel needs to move to xsf@muc.xmppstandards.org you can update that without user intervention.

You can already search SJN directly from e.g. Conversations and maybe a couple other clients.

That's a nice feature. It would be useful to me to have a sane way of configuring my server to have external_muc.myserver.org and specify 10 channels across 6 different servers so when my users browse the channels that's what shows up.

You can already list arbitrary addresess with some common Prosody configuration, so as long as you don't actually want aliases.

Oh that's nice, i'll have to look into that

`disco_items`, often used to list not automatically listed MUCs or whatever

I just noticed one channel moved servers - last message was the new muc to join - that's the kinda thing that really should be automatic

> Kris> if you want to migrate a channel to another server for example I think client support for <destroy@jid/> and <gone/> is much cheaper for this specific use-case

Yeah, there is a way already, you can point at a new address when destroying a MUC.

Needs client support of course, I went on an issue filing spree a while back.

At the end of the day you can write the best most well thoughtout XEP's but if no one implements (or implements incorrectly) it's not very useful.

Problem: XEP is too long, nobody reads the whole thing. Solution: More, shorter XEPs! New Problem: Too many XEPs! Solution: Merge them into a single specification! New New Problem: See First Problem.

Meanwhile, all the users went elsewhere beacuse lack of Stickers

Not sure who is complaining about XEP's being too long. The bigger problem is a lack of reference implementations. https://xmpp.org/extensions/xep-0491.html sounds cool - what has implemented this, how do I know I actually followed the spec?

> Not sure who is complaining about XEP's being too long. The bigger problem is a lack of reference implementations. https://xmpp.org/extensions/xep-0491.html sounds cool - what has implemented this, how do I know I actually followed the spec? By going to https://xmpp.org/extensions/ and clicking the 'Implementations' button next to the XEP you wonder about. ↺

Did they actually go though a interoperation test or was it just submitted as implemented?

It's declarative. It's up to the projects to say they do implement it

They?

The projects

You do not need any implementation to submit a XEP, the intent is that it would be implemented during the Experimental phase, with feedback going into improving the XEP.

I poked singpolyma, I am pretty sure Cheogram implemented '491 actually.

Sometimes what's done is the people concerned with a standard get together and actually test things interoperate

We do have interop events occationally.

I never noticed that implementers button though that's nice.

qxmpp is really coming along!

> We do have interop events occationally. the berlin sprint is afaik often used to test client interoperability ↺