XSF Discussion - 2024-01-05

moparisthebest: I looked at that hostmeta spec and I don’t really have an opinion. Dave Cridland is probably right that this is about the best we can do.

stpeter: thanks! Do you have an opinion as to whether it should be a new XEP or rewrite '156 ?

rewrite/addition to

singpolyma: it's a rewrite, not an addition to, it says basically "you might see xep156 formats in the wild, support only them for now, but ignore all the rest when this new thing applies"

It's also nearing 20 years since RFC 3920 was published

MattJ, ralphm, singpolyma, emus, stpeter, Alex, I apologize for not participating in yesterday’s board meeting. It was impossible for me. I took note of the minutes. See you in Bruxelles!

nicola: no worries. Cya there!

emus: if you want to set up an account on Bluesky, let's also involve the iteam to make sure our handle becomes @xmpp.org. This is mostly trivial but requires a DNS TXT record.

If you need an invitation to Bluesky I am available

Should we drop 4.6 from XEP-0133? Retrieving plain-text passwords is... meh. https://xmpp.org/extensions/xep-0133.html#get-user-password

Heh, yes

Sounds like the type of call nobody would (and hopefully could) actively implement anymore anyways.

Does anyone know if there is any current project to regularly or continuously test the performance of public xmpp servers and publish the results? ✏

I've raised https://github.com/xsf/xeps/pull/1314 and asked for a review of stpeter, as the original author.

fjklp, the closest that comes to mind is https://compliance.conversations.im/

that's not 'performance' though, but 'features'

yeah, I specifically meant performance

Performance is very much a moving target. It wildly depends on the exact usage patterns, network setup, hardware used, etc, etc.

When people ask about performance of Openfire, I typically can't answer them. I've seen instances process five-digit number of concurrent users with ease, and others that struggle with less than 100.

Same here

People vastly underestimate the number of factors in running a high-performance deployment (the definition of which is also variable)

my motivation is that I've noticed poor performance on multiple servers and recognized that this is actually more of a relevant factor to me than the sort of stuff on https://compliance.conversations.im/

What kind of poor performance?

It would be nice if there were objective measures that one could use when selecting which server to use. It might also assist people in fixing their servers if they care.

Messages taking a long time to post in a muc, for example

fjklp: if you have a specific way to reproduce that poor performance, then I'd be interested in learning about them. Maybe we can improve things.

There could be so many factors involved in that, though (including your network connectivity)

I don't have evidence but I suspect a major factor might be people hosting servers on over-worked VPS serers

> There could be so many factors involved in that, though (including your network connectivity) yeah, I agree

A tool that would continuously test for this will only _add_ to that problem of course :)

I can live with that

The people hosting the service might disagree :D

if a server can't handle the load I would give it, it's not fit for service

(but it's probably something that can easily be tuned to acceptable standards)

I'm talking light loads

Sure, but there are fine lines between what _you_ define as 'fit for service' and what others do - or what administrators can spend on resources, etc. I'm not saying it's an absolute no-no, but I'd be careful.

I'm primarily interested in latency of message delivery, so it's not really about putting a heavy load on it as much as just sending a single byte message to a bunch of mucs or something ✏

Well, go for it, I suppose.

as far as I know, it doesn't exist - so if you're interested in having this, then your best bet is to start building this yourself (or have someone build it for you, if you're not a software developer yourself).

I wanted to ask first in case it exists. I know there are a few tools that might be fit for this, but don't know much about them. I see https://github.com/processone/tsung and there are xmpp plugins for Apache Jmeter such as https://github.com/Blazemeter/jmeter-bzm-plugins/blob/master/xmpp/XMPPSampler.md

fjklp as you mentioned you are interested in latency of message delivery, that will vary from the endpoint from which you will run your tests. I’ve seen issues with powerful servers with fast networking and very high latency due to network connectivity bottleneck (that was a connection from client/server in EU to a server in USA)

so even if you post to the MUC room on a different server, the latency between servers may matter as well as latency between your client to „your” server (the server on which you have account)

I get that there are a bunch of variables but real world testing is probably the best testing. Maybe the test could be run from multiple servers in different regions to get more insightful results.

yes, I mentioned those issues, as the only solution for them is actually testing from multiple endpoints (different regions) and that could help getting more reliable results ✏

Andrzej, Holger, Andriy Utkin, and others who signed up past the previous attendee capacity: we've negotiated a new limit of 35 attendees with the hotel, so there is certainly room for everyone currently signed up on the wiki, and any more who come along

Thanks for the update. I'm glad it was possible to find a bigger room.

> ralphm: > 2024-01-05 08:38 (GMT+01:00) > emus: if you want to set up an account on Bluesky, let's also involve the iteam to make sure our handle becomes @xmpp.org. This is mostly trivial but requires a DNS TXT record. Thanks, we are not yet sure to do it