I wonder if we could provision a non-priviledged jabber account for compliance testing? The following tool graphs changes in support for various specifications over time, and is used by a number of other tools to determine servers to recommend:
I’d love it if Mayfirst were one of the listed services, but we’d want a separate account that’s possibly restricted from sending federated messages in case their database of passwords is ever leaked.
I’d be happy to help with this as I have a good deal of experience in the XMPP community and managing Prosody and Ejabberd servers. I’ve been struggling to figure out how to get involved, so anything I can do to help please let me know! Thanks!
Hi, can you tell us a little more about what you mean by unprivileged account? Any user created in our control panel can connect to our Prosody XMPP (jabber) server but you could create a new user under your membership specifically for testing with.
I was thinking a user that can’t create chat rooms or send federated messages (to prevent it from being used for spam if the password was ever leaked), but I didn’t realize I could create multiple accounts so that might work perfectly if so. It’s not as if there aren’t tons of open servers anyways, so one account isn’t the kind of low hanging fruit spammers are likely to go after.
I was hoping an administrator could create an account with restricted privileges on the jabber server, but if you’d prefer I just create an account on my membership that’s fine too.
Actually, even if I create a new user under my account if I try to login using the instructions (how-to_jabber | May First Documentation Wiki) it claims the password is wrong; I’m not sure how to create a new jabber account it seems.
I think I’ve finally got a handle on the control panel and I figured out how to make a new account, so I submitted one on a separate (otherwise empty/no quota) hosting order so that mayfirst could show up in the compliance tester! You can view our results here:
I’d love to help out with maintaining the XMPP server in general as I have some expertise in this area. If anyone knows who I should talk to, or if they even need any additional hands, I’d love to chat with them.
Thanks, and sorry to keep bumping this old thread! I’ve been struggling to figure out the tech side of things or how to get involved here, but I’m hopeful that I at least have somewhat of a handle on things now.
Oh - sorry I missed your other questions! And thanks for posting the compliance testing results - it looks like we could do much better. I spent an hour and only managed to fix one - the tls SRV record (now we are at 85%). I added the contact info - but it doesn’t seem to be working. Similarly, many of the other failures are actually configured in our prosody service. We are running an old version of prosody (maybe that’s why they are failing?), so I’m not sure if it’s worth doing much more until we upgrade (currently running 11.2, we could be running 12.3 if we upgraded our server from buster to bookworm).
I wouldn’t worry too much about the score (the TLS SRV records are great to have though if we have implicit TLS enabled; thanks for doing that!) in general, some of the specs are merely “nice to have” while others make the experience much better.
I’d say XEP-0198: Stream Management in particular would be the biggest requirement of the ones listed right now (this allows session resumption when eg. moving between a wireless access point and cell among other things). Client State Indication in general is nice to have as well, but I’m not sure what optimizations Prosody actually does (if any), so that may be worth waiting on until the upgrade.
Are you able to tell via your use of our service as to whether or not Stream Management and CSI are in fact working? Both are configured and should be working. If CSI means “notify when someone has ready up to this point” - then it is working in my experience. I am not sure about stream management.
I’m not seeing either enabled from my end; CSI is more or less only used on phones and is them telling the server that they are “active” or “inactive” (ie. screen is off or app is in the background, etc. at their discretion). It’s then up to the server to do some nebulous hand-wavey thing to save battery (eg. not send presence information until the client becomes active again is a common optimization)