XSF Discussion - 2022-08-17

> Hashes don't really solve the problem, Why do you think that

Good morning. Is there a way to mirror MUCs in a way that if one goes offline you may use the others? Another use could be the opportunity to send messages into the MUC nearest to your position. When conversations.im was offline some MUCs I've subscribed were unreachable, with mirroring we'd had still used it. Don't know if this is offtopic. If it is, excuse me in advance. ✏

Mario Sabatino, there's bots that can bridge mucs

eg. forward all messages from one muc to another

or both directions

Mario Sabatino, there are various solutions to that. Many XMPP server implementations already support clustering, which allows the provider to mirror the service across multiple machines. Then there is XEP-0289 ( https://xmpp.org/extensions/xep-0289.html ) which allows linking separate MUCs together in case one of them goes down. And finally, in Prosody a long time ago I implemented a transparent mirror that would allow local users to communicate in a MUC even if the primary one was down. That required no protocol changes.

XEP-0289 sounds interesting, is that actually implemented in servers though?

couldn't find anything about it on ejabberd, neither prosody ✏

> WARNING: This document has been automatically Deferred after 12 months of inactivity in its previous Experimental state.

Sheev Palpatine: it's implemented in M-Link (not open-source) and I know an Openfire dev was looking into it a while ago

I'd be interested in adding it to Prosody, but it's not on my immediate list of priorities

Openfire has experimental support for FMUC

M-Link also has support for it to, but we never did interop testing, and it's implementation is likely ahead of the specs.

> It is possible, although not required, for an implementation and deployment to use JID Escaping (XEP-0106) to make naming schemes easy to manage e.g., a user would join conversations\40conference.siacs.eu@fmuc.theirserver.example?

mjk, potentially, but not necessarily

e.g. a client might automatically discover that, or a server might internally rewrite it, or such. The *user* doesn't necessarily need to be aware of what JID to use.

> Mario Sabatino, there are various solutions to that. Many XMPP server implementations already support clustering, which allows the provider to mirror the service across multiple machines. Then there is XEP-0289 ( https://xmpp.org/extensions/xep-0289.html ) which allows linking separate MUCs together in case one of them goes down. And finally, in Prosody a long time ago I implemented a transparent mirror that would allow local users to communicate in a MUC even if the primary one was down. That required no protocol changes. THX . How to use it? If it is actually usable now. On Snikket or Prosody i.e. . Can you share links with documentation? 😀

Mario Sabatino, it was just a prototype, I didn't publish it anywhere

OK. Thx

> a client might automatically discover that right, I figured as much. Just wanted to make sure I'm on the same page with authors there

I think it's mostly a case of "FMUC hasn't been deployed outside of closed environments yet, so nobody needed to solve addressing yet"

The reality is that although other networks have this built in and make a lot of noise about that, it's not like it's anywhere near the top of most people's feature wishlist

Except very occasionally when a popular service goes down for a bit. Then people care briefly, and forget all about it until next time.

If the network really was so unreliable, people would obviously care more

Also this model brings more complexity to deal with

it's also noteworthy that we really messed up this time and have no plans to mess up like this again

"if you fail to plan, plan to fail" :))

but yeah, people in general tend to care about failures only for a short while after they happen

wurstsalat, `fortune` recently gave me that, not sure if there was any attribution

wurstsalat: told you Monday 😉

mjk: But if you plan to fail, then you haven't failed to plan

^^

> mjk: But if you plan to fail, then you haven't failed to plan Thus, you have succeeded in your plan. Foolproof really.

jcbrand, I thought about that too!.. without much success

thinking is hard

Hey folks, mid of month, best time to add you commits and contribution to the Newsletter: https://github.com/xsf/xmpp.org/pull/1163 https://yopad.eu/p/xmpp-newsletter-365days We call for support, even for the smallest task. Continuous help or one-time support is really appreciated! Tasks we do on a regular basis: - gathering news in the XMPP universe - *short* summaries of news and events - summary of the monthly communication on extensions (XEPs) - review of the newsletter draft - preparation of media images - translations Cheers, XSF CommTeam!