XMPP Service Operators - 2024-05-04

Hi, has anyone experienced that items on the https://xmpp.org/blog/index.xml RSS feed show up as unread once in a while? In particular it seems to happen to the XMPP Summit posts

I added some tags to those posts recently. Maybe that way they got updated in your feed

How recently? It's been happening about once a day for a couple weeks now. I guess I can try to delete the cache and see if it helps

Not-so-recently

test

test 2

we're so back

https://downloadable.pain.agency/file_share/8ZNXzq97aZCLIJfQcJpl4Oin/67ED29EB-36F0-43E1-A0C7-62DDF3D545AA.jpg

Joinjabber.org sends Server sent policy-violation: No stream features to offer

Menel, I suspect they may be aware, given that one of the admins dropped out of the MUC.

Menel, though I still seem to be joined in chat@joinjabber.org, so I mentioned it there, thanks.

Posting my manifesto here one more time: https://codeberg.org/divested/safeguarding-xmpp-2025 Any feedback would be appreciated. It is a serious proposal to push the ecosystem forward despite the jokes here about it in the past.

for reference the last xmpp manifesto regarding security is 11 years old

https://github.com/stpeter/manifesto/blob/master/manifesto.txt

> It is a serious proposal to push the ecosystem forward despite the jokes here about it in the past. Shouldn't you be writing a XEP then?

and posting it for the council to vote on?

Tavi, why different size limits for c2s and s2s?

Polarian, not everything related to the XMPP ecosystem needs to be a XEP, and it's also not uncommon to gather some feedback before submitting a XEP, especially for first-time authors.

> Polarian, not everything related to the XMPP ecosystem needs to be a XEP, and it's also not uncommon to gather some feedback before submitting a XEP, especially for first-time authors. ah ok ↺

jonas’: both prosody and ejabberd recommend different sizes

For both c2s and s2s

Prosody's however are 3x higher

4*

fascinating!

I wasn't aware of that

Does it matter what the limits are set to?

Tavi, do you happen to know why?

Polarian, yeah, your avatar can be at most roughly 75% of that size.

> Polarian, yeah, your avatar can be at most roughly 75% of that size. lol ↺

but security wise?

does the limit make any improvement to security?

Polarian: Mopar found it could be used for dos

Polarian, yes, stanza parsing needs memory.

bigger stanzas = more memory use

If its a memory thing, then surely it differs based on platform?

s/platform/server/

Polarian, indeed, however, the XMPP network doesn't really work well if stanza size limits differ too much between servers. So recommending a specific limit is a good idea.

(imagine your server allowing 2MB, you upload a 1.5 MB avatar, but remote servers only accept 1MB stanzas. Then whenever someone requests your avatar, the s2s link will break down.)

(which is ... not great.)

then surely an avatar size limit should be set too!!!

~I haven't read the XEP, there might already be one~

Tavi, when talking about IP blocking, you should probably specify what exactly that means for IPv4 and IPv6 (common approaches block /64 or even larger for IPv6 to prevent the blocklist itself from becoming a resource DoS vector)

> then surely an avatar size limit should be set too!!! this is a good idea though, no? ↺

Polarian, it's implied by the stanza size limit.

but stanzas can contain anything

Tavi, as it stands, I wouldn't sign that. It contains a bunch of unmotivated recommendations which are IMO too extreme (such as encrypted memory, requiring dedicated boxes for different services, SELinux, etc.). And yes, those are SHOULDs, buuuut SHOULDs are "do this unless you really really know why not", and I think that's too strong.

explicitly ensuring avatars don't sprawl have other benefits... such as reducing the storage size on clients...

> Tavi, as it stands, I wouldn't sign that. It contains a bunch of unmotivated recommendations which are IMO too extreme (such as encrypted memory, requiring dedicated boxes for different services, SELinux, etc.). And yes, those are SHOULDs, buuuut SHOULDs are "do this unless you really really know why not", and I think that's too strong. I pointed this one out in his own channel, should physical security come into the securing XMPP? ↺

Where do you draw the line? Should you include what cloud providers to use or not to use? and how to configure them?

very good point

Then thats an entire can of worms... some people self host their own servers...

should they CCTV their house for example?

As I know there is an avatar-sizelimit of 72kB to keep stanzas below 100kB

ejabberd recommends 65536 for c2s and 131072 for s2s prosody recommends 262144 for c2s and 524288 for s2s (bytes)

ejabberd however notably does not actually set that as a default afaik

Once upon a time we talked about standard sizes and prosody did then deploy what ejabberd did (as I understsnd that time) but the docs say ejabberd actually uses infinity, and recommends something smaller. That's stramge. I remember prosody did set what ejabberd did at that time.

(was the release after the eatxmpp time)

https://prosody.im/security/advisory_20210512/ > Our recommendation (and the default in 0.11.9) is to adopt the same default size limits that are already enforced by ejabberd, one of the other major XMPP servers on the network.

they at least used to but iirc it was the default in their config but not code or so