Modern XMPP project discussion - 2024-10-31

MattJ, it's to matrix.

that room in particular on matrix side seems to have couple of telegram bots and is few k users (on matrix side). so prosody keeps sending presence stanzas to bifrost (the matrix bridge) and to all other bridges in the room too (few telegram, irc and maybe some more).

could be that cuses prosody to get unresponsive? Looks like server is doing well for few hours and then suddenly eats ton of RAM, 100%CPU and only restart of prosody brings it back.

muppeth: and when you say the MUC is "bridged" - how exactly is it bridged?

It's bridged with bifrost. https://github.com/matrix-org/matrix-bifrost

So it's not actually a Prosody MUC

So who is sending the 5 million stanzas?

it is a prosody MUC. the bridge works in a way you have a muc on xmpp side and room on matrix side. There is a bot (bifrost) that does message relay and puppeting so users on each side apears to the client as native users.

interesting thing is that now that room (osm-in@chat.disroot.org) has 15 users (some from matrix) while yesterday that same room had over 1k users.

since the bridge runs on Arianet I am checking maranda about it. maybe he has some ideas.

looks like the presence flood is triggered upon restart of the bridge as normally it should just puppet active users, but upon restart it does them all. so that osm-in room that had 15 users at two hours ago, now after maranda restarted bifrost bridge, now has 1.6k and climbing.

this will probably bring the server to it's knees soon. I was wondering if others experience similar issues and if there is any idea on how to combat it on prosody side.

this could potentially happen to any server as someone could bridge number of rooms and endup in similar situation.

mod_muc_limits should be enabled and set to permit a level of traffic that your server can handle, and if you're being bombarded at the network level, mod_limits is the first line of defence

The goal of those is to have a usable server, not necessarily working bridging

To solve the latter, you could consider disabling presence broadcast for non-members (which I assume the bridged users are not)

is that per muc setting or server wide? how to set it?

The latter is per MUC

"Only show participants with roles" in the MUC config form

I've been working on GC3 (MUC successor), including an implementation in Prosody, and it would solve this (small Bifrost changes would be required though)

thanks. am i right to assume muc_limits will not pevent presence stanza flood?

You say that Bifrost doesn't use the presence, but that's not exactly true - I'm assuming it shows Matrix users who is in the XMPP channel

muc_limits will prevent a stanza flood, but it does this by rejecting stanzas when the limit is reached

yes. i meant on matrix side the presence works diffrerently (in the sense that you cant see in realtime if user is online or not)

Yeah, but it's how we communicate to Bifrost which users are in the MUC

What's frustrating is that Bifrost really only needs one copy of this information

> muc_limits will prevent a stanza flood, but it does this by rejecting stanzas when the limit is reached and that would count all the stanzas, right? so in case of the presence flood, it would use up the limit and legit chat would be throttled right? ↺

But because 1000 occupants join, we send 1000 copies of the same information to each occupant

> so in case of the presence flood, it would use up the limit and legit chat would be throttled right? Correct. And bridging will basically fail, because most of the bridged occupants won't be able to join.

Note that room members bypass the limit

So the usual convention in public channels is to make regulars members

Then if you have a join flood, only the untrusted JIDs are affected

Since you said you have 15 people, you would make those members, and they will be unaffected, but bifrost will be

as well as anyone who tries to join while bifrost is flooding you

the thing is that any user can bridge a room, so on my server there are i think 44 bridged rooms.

mod_muc_limits and mod_limits are (for better and worse) global, so you don't need each room owner to set this up

The presence thing is per-room though

I think there is a way to pre set defaults for new channels at least? ✏

Old habits :)

Yeah, you can change the defaults. However this would be a very surprising default :/

In theory it would be possible to just filter stanzas to/from bifrost, e.g. using mod_firewall

But this is getting pretty Prosody-specific, we should probably take it to the Prosody channel

the worst part of this issue is that of those 1k users on the matrix side, probably 700 or so are dead accounts. So the issue it completely stupid and just caused by conflicting design philosophies

Yeah

btw GC3 will be completed this year?

I mean the XEP draft submitted

muppeth, the appservice-irc bridge at least has a setting to prevent these mass-joins on bridge restart. Maybe that is something Maranda could look into?

Kris, depends. My current before-end-of-year priority is OMEMO in snikket-sdk, but GC3 is already in progress and a close second.

I already have a test server up since the Worcester sprint, with some initial functionality. However there wasn't much time for testing by the time it was ready.

> muppeth, the appservice-irc bridge at least has a setting to prevent these mass-joins on bridge restart. Maybe that is something Maranda could look into? thanks. I relayed it to him ↺

Snikket-SDK will support OMEMO 0.8?

why entering disroot room, i keep getting server timeout try again message. is the disroot xmpp down? is every room hosted on its original server only?

halo, I am also seeing connection issues with Disroot right now, but I think that might be rather an issue with the new ejabberd 24.10 release. What server are you using?

my jid is from movim.eu

Can you send message on disroot room?

hmm, not sure if movim.eu is already updated to 24.10. probably not?

right now I can't, but I think that is rather due to my server and not Disroot

can you join the joinjabber.org channels? because for me I also have an issue there.

despite not having enabled mod_s2s_bidi I can't seem to connect to Prosody hosted MUCs right now

other rooms are ok. only disroot disconnected. so i guess disroot is down

other channels hosted on ejabberd servers yes

> Snikket-SDK will support OMEMO 0.8? At least not initially, no. If there is enough movement in the ecosystem (e.g. Conversations at least) then I'd reconsider that.

the last message in disroot room is ">I love misteries, just not the best timing for 'em right now Muppeth 🤣"

which is 17hours ago

halo, perhaps you should reload the client. this was from yesterday.

That is your message, right?. do.you see.anything after that?

ah movim.eu is also already running on ejabberd 24.10

so it is probably the same issue I have

Kris: did any server update happened after yesterday?

apparently yes. I just checked and movim.eu also runs on ejabberd 24.10 already and that was only release the day before yesterday

How many different server software does xmpp have?

At least 6

so, ejabbered is unstable?

no, but I think there is a newly introduced bug that prevents it from connecting to channels hosted on Prosody servers

most public channels are hosted on Ejabberd, except Disroot pretty much

I'm curious how you define "most" :)

according to my extensive list of channels I am joined :) only Disroot and Joinjabber fails right now and those are the only ones I know for sure are on Prosody

It doesn't matter, but I get the opposite impression, and search.jabber.network suggests it's far from just disroot (from a rough skim, Prosody is roughly half of the front page of results, 2 of those are disroot)

You're joined to this one okay?

apparently...

Maybe just disroot and joinjabber have bidi enabled

so it might also be a specific setting issue with Disroot and Joinjabber

yes maybe, but I explicitly did not enable mod_s2s_bidi when upgrading ejabberd

Yeah, that's weird

Kris: is only the room channel discommunicated, or private 1to1 chat also broken between two types of servers?

if s2s fails then all communication is blocked

but somehow I managed to resolve the issue on my server just now

it's unclear how, but I can access Disroot channels again

> Maybe just disroot and joinjabber have bidi enabled Yes we do. ↺

Kris, I unloaded bidi. could you check if you can join?

I already somehow fixed it before

but I am pretty sure bidi was not the issue in my case as I never enabled the new mod_s2s_bidi in the new ejabberd release

but maybe it helps with movim.eu

Kris I just disabled mod_bidi for now

Has there been any discussion within the XMPP community regarding the implementation of a mention feature in MUCs, similar to the commonly used ‘@’ symbol in other IM applications?

Yes and some clients already do that.

> Yes and some clients already do that. Is it just a simple match with the nickname? ↺

As in they invoke some user selector UI if you type @ and then communicate the mention using some XEP, not by sending @ on the wire.

Gajim will offer that as well in the upcoming 2.0 release

https://xmpp.org/extensions/xep-0372.html#usecase_mention maybe, I'm not sure

I saw that there is an XEP-0224: Attention extension that can alert the other party, but it seems to be unavailable in MUCs.

Attention may be useful for alerting *everyone*, it's not directly usable for individual mentions.

And in 1:1 chats

> Louis2: if you are not paying people you can't assign tasks to them Kris: Guess that means I can't ask my dog to fetch the remote either!

you are paying your dog with accomodation and food

maybe you should try that with xmpp developers... there might be some takers ;)

given rental prices and food inflation these days

Hi I have a client of Moxxy abandoned, don't you know?

Not abandoned

their xmpp server seems to be down since a few days though