XMPP Service Operators - 2026-03-10

Is there something special abou the member.fsf.org domain? For some reason, my domain has trouble federating with them. I don't quite understand why.

You mean their server? What would the domain have to do with that?

Probably an outdated server?

> Is there something special abou the member.fsf.org domain? For some reason, my domain has trouble federating with them. I don't quite understand why. Let me try... ↺

I think I know one of the people who runs it

> Is there something special abou the member.fsf.org domain? For some reason, my domain has trouble federating with them. I don't quite understand why. can't either, an Openfire issue maybe... ↺

Using https://connect.xmpp.net/ I can see Direct TLS fails

but StartTLS does work :/

Kris, I was referring to the _XMPP_ domain (which can sometimes be more than one server)

I'm not sure if connect.xmpp.net can be trusted. It gives me weird results occasionally.

I'm wondering too if it's an Openfire issue - but it could also be something on their end.

> Kris, I was referring to the _XMPP_ domain (which can sometimes be more than one server) Domain as in DNS? I don't really get it. Ok maybe there is something misconfigured with their xmpp SRV records or so? ↺

if it helps i dont seem to be able to connect either on prosody

though gajim could just be being weird

Kris, I'm just using the word 'domain' where you are used to using the word 'server'. Maybe the middle ground is 'service' or something. Don't worry about it.

Ok 🤷

> I'm not sure if connect.xmpp.net can be trusted. It gives me weird results occasionally. yeah usually you run it like 5-10 times and take the average 🤣 ↺

> yeah usually you run it like 5-10 times and take the average 🤣 top 10 signs of reliability ↺

> I'm wondering too if it's an Openfire issue - but it could also be something on their end. I have reached out to someone I know has been part of fsf XMPP, maybe the might have more info. ↺

Kris, you run prosody don't you? Could you s2s test, me and Guus are Openfire-based

> though gajim could just be being weird tested, pretty sure its not gajim weirdness, seems i cannot connect on prosody ↺

My private server is ejabberd

Kris, still different, could you try federating with members.fsf.org please?

Guus: you have a public channel JID on that server to test s2s connection?

> Guus: you have a public channel JID on that server to test s2s connection? Doesn ↺

oops didnt mean to send

> Guus: you have a public channel JID on that server to test s2s connection? Doesn't ejabberd have a cli to s2s test? ↺

I am not at my pc right now, but I could at least try to connect via my mobile client.

ah right.

I don't have a target JID on that server, no.

neither do I :/

> no it doesn't, the bug only existed in ejabberd, all other servers had done it the right way for decades i'm necroposting but what bug is this? ↺

> tested, pretty sure its not gajim weirdness, seems i cannot connect on prosody Apologies I seem to have missed this. Okay then its not an Openfire issue Guus ↺

I will wait for the response from someone I know, and see if they have any more info about the server.

Ok thanks

The server doesn't seem to respond on 5269, just times out (firewall?)

https://connect.xmpp.net/?members.fsf.org does not succeed for me either

It did for me earlier today 🤷

oh, it is member, not members

> oh, it is member, not members 🤦‍♂️ ↺

lol

I assume all of us were using the correct domain name apart from Matt. I do have problems federating with the singular form of that domain name.

i have member.fsf.org on my clipboard history

That makes more sense. member.fsf.org works okay for me.

# prosodyctl shell xmpp ping matthewwild.co.uk member.fsf.org Session s2sout56167cf76e10 (matthewwild.co.uk-->member.fsf.org) connected (0.618963s) Session s2sout56167cf76e10 (matthewwild.co.uk-->member.fsf.org) authenticated (1.08416s) Session s2sout56167cf76e10 (matthewwild.co.uk-->member.fsf.org) established (1.15565s) Session s2sin56167e6f5440 connected (1.61625s) Session s2sin56167e6f5440 (matthewwild.co.uk<--member.fsf.org) authenticated (2.01221s) Session s2sin56167e6f5440 (matthewwild.co.uk<--member.fsf.org) established (2.01242s) OK: pong from member.fsf.org on s2sin56167e6f5440 in 2.15244s

will try running that on my vps to eliminate gajim bugs

``` joseph@snapshot-115842185-debian-2gb-hil-1 ~ [1]> sudo prosodyctl shell xmpp ping pain.agency member.fsf.org [sudo] password for joseph: Error: error<cancel:remote-server-not-found:Server-to-server connection failed: wrong version number> joseph@snapshot-115842185-debian-2gb-hil-1 ~ [1]> ``` 🤨

That looks like it could be a TLS error

My server seems to negotiate TLS 1.3 with them

at the very least it doesnt seem to be an openfire specific bug, probably an issue on their side

_xmpps-server._tcp.member.fsf.org. 180 IN SRV 0 0 5269 jabber.member.fsf.org.

this is probably not good, unless they're really doing some kind of multiplexing

(and if they are, that multiplexing is probably going wrong, as per "connection failed: wrong version number", which is exactly what you'd get when talking TLS to a plaintext port)

Oh right, I forgot to check SRV for that domain

ah, with randomization kicking in to sometimes have plaintext over TLS connections, and sometimes not. That could explain the flaky behavior.

Yeah

Thanks Jonas’ that makes sense

it feels good to be useful :D

here, usefulness-a-plenty!

NOOOOOOOOOOOoooooooooooooooooooooooooooooooooo

or rather:

https://github.com/hedgewars/hw/raw/refs/heads/master/share/hedgewars/Data/Sounds/voices/Default/Nooo.ogg

> https://github.com/hedgewars/hw/raw/refs/heads/master/share/hedgewars/Data/Sounds/voices/Default/Nooo.ogg nothing could have prepared me for this ↺

Ok my cat reacted to that :D

jonas, did you notice my last pm on aioxmpp?

codeberg was down at the time

iirc the last merge broke a test

Guus, yeah I did.

and then I became quite frustrated

I'll look into it eventually...

(you can pin to the commit before the merge right?)

jjj333_p [pain.agency], except playing more hedgewars!

ok no worries. I've simply disabled that test.

also good

> jjj333_p [pain.agency], except playing more hedgewars! perhaps ive got to look into that ↺

jonas’: aren't you running the tests in your pipeline, btw? I think that mechanism was why I picked up using aioxmpp in the first place. Maybe you did that only when it was hosted on Github?

Guus, the pipeline died with the move to codeberg.

(and due to what's written in the README, I'm not much inclined to fix that)

Understandable

jonas’ if you want, I can have a stab at it. I've got an interest in keeping the devel branch tests bugfree :) - I have a bit of experience writing Forgejo Actions. As your GitHub workflow mostly uses shell scripting, there's a chance it translates well (with the exception of the code coverage plugin, probably). One prerequisite is tyat you filing a ticket with Codeberg to have 'actions' enabled for your repository - I don't think that's something I can do for you.

Guus, I'd appreciate it actually.

the coverage thing can be dropped.

I can look into enabling actions.

so that I don't forget, can you file an issue for that please?

Sure

https://codeberg.org/jssfr/aioxmpp/issues/421

>> no it doesn't, the bug only existed in ejabberd, all other servers had done it the right way for decades > > i'm necroposting but what bug is this? stratself: https://blog.prosody.im/2026-letsencrypt-changes/ ↺

thanks mopar. I didnt know server-only certificates has, in general xmpp history, always been supported

Are client certs still supported? ✏

Also are there any other certificate authorities that still issue the correct style of certificate regardless of what google says?

certs valid only for server are good (except on old buggy ejabberd)

certs valid for client and server are good everywhere

> Also are there any other certificate authorities that still issue the correct style of certificate regardless of what google says? no, because google would remove them from the trusted CA root bundle ↺

Mozilla is supposed to be managing the bundle

Not google

I do not trust google ✏

technically it's mozilla and google, in practice obviously google does what they want

I mean it's 99.9% market share vs nothing right?

If 99% of people told you to go jump off a cliff would you?

I don't think that's applicable here mom

In fact, as long as % market share numbers I pulled from nowhere apply here, let's stop using xmpp and switch to Facebook messenger

This is a pointless tangent

It's true, the majority of CAs want to be trusted by browsers, and therefore have to follow both Mozilla and Google

that CA bundle is just what the entire TLS ecosystem including XMPP uses to authenticate servers, it has a lot of advantages it would be very hard and costly to replicate

The trust store used in most open OSes is based on Mozilla's, but for most CAs, only being in Mozilla's trust store isn't much use

https://nerdcert.eu/ is a relevant link related to the original question

I think cacert is also still going

this particular change isn't a big deal, it's only noticeable at all because ejabberd had a regression

we just have to pray they don't alter the deal further

I don't have much faith in prayer in this case, but we'll see. The upcoming dns-persist challenge is a positive for XMPP, so that's something.

pray & continue trying to bully people into dropping their .im domains that'll never support dnssec/dane? 😁

who's first? conversations.im or prosody.im ?

I keep meaning to poke some people about that

https://www.moparisthebest.com/images/dane-vs-cab.jpg

it is the time for "the operators channel is having silly arguments" again? /s

I didn't see any arguments no, only questions and answers