jdev - 2024-10-20

> citrons: yes source? afaik they do not ↺

seil: they use whatever server the carrier you're in uses. Which as mentioned is basically always Google

> seil: they use whatever server the carrier you're in uses. Which as mentioned is basically always Google ohhhh ↺

Quick question, how do different clients connect so seamlessly to a server (enter only domain) without more details? I have barely set up mine and all clients i have tried so far have been able to connect using only my domain name

I'm currently trying to do the same (using xmpp resolve library) but only get xmpp/xmpps protocol returned

SRV records in dns

but how come gajim, conversations and converse all can connect without srv records?

they're actually using xmpp/xmpps

interesting

not, as I derive from external context, websockets or bosh

those require a pile more for discovery to work

https://xmpp.org/extensions/xep-0156.html

Oh yeah I assume if you say XMPP you mean xmpp not websockets

seil, most servers default to offering service on 5222 and 5223, so all a client needs is the A record from your domain

5223 hasn't really ever been a thing though, the default ports are 5222 for starttls and 443 for directtls and quic

(unofficially but in practice)

you are incorrect. 5223 is the standard now. source: https://codeberg.org/iNPUTmice/Conversations/commit/d06ff45783642edd233a060059431670783d45aa

Yikes, that's gross

disgusting, I will bug him to make that 443 immediately

Allowing 5222 on A for historical reasons because the standard says so is fine. Otherwise it's SRV only

> disgusting, I will bug him to make that 443 immediately No that would be just as bad ↺

5223 and 5270 are actually mentioned way back in rfc3920, so there's some historical precedence

Worse even. I've had stuff completely feel to connect at all because it tried 443 found a website and got confused

Personally I wish we'd gone the other way and require explicit SRV records, but it seems too late now.

> 5223 and 5270 are actually mentioned way back in rfc3920, so there's some historical precedence Oh are they? Then maaaaybe it's ok.... ↺

> Personally I wish we'd gone the other way and require explicit SRV records, but it seems too late now. Yes I think so. Explicit SRV is the way ↺

Further complicated by 5223 being registered to something else now: https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5223

> Worse even. I've had stuff completely feel to connect at all because it tried 443 found a website and got confused And that is bad code that needs fixed ↺

Not papered around by trying to avoid it

Tell all the web tooling to stop trying to http on our xmpp-only 443 ports then :)

redirecting you to different ports with a valid cert is something an on-path attacker can do, you can't get confused and stop, you must try to connect all the other ways hoping he isn't on all the paths

> Not papered around by trying to avoid it Requiring that you follow the spec and use the SRV records isn't papering around ↺

I tried to make a xmpp-only ALPN port but web browsers and curl crammed http at you anyway

singpolyma: see above

> Further complicated by 5223 being registered to something else now: https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5223 lol. It was in our RFC but someone else registered it? How did that even happen? ↺

It's ok no one uses legacy port numbers nowadays anyway, and we have our own alpn

> D.1. Channel Encryption > > It was common practice in the Jabber community to use SSL for channel > encryption on ports other than 5222 and 5269 (the convention is to > use ports 5223 and 5270). XMPP uses TLS over the IANA-registered > ports for channel encryption, as defined under Use of TLS (Section 5) > herein. Mentioned, as old legacy pratcice. Not registered or recommended.

Ah ok. So back to don't do that

and 6120 doesn't mention those at all

No SRV basically means it's broken but for historical reasons means use 5222

No SRV may mean your router or ISP blocked it for silly reasons, therefore everyone has to offer service on the default ports and then why even bother with SRV at all? It's a nice thing, clearly it must go away 😭️

This is the world we live in now (for over a decade at least), no one likes it, but it's reality https://www.rfc-editor.org/rfc/rfc7258

That means XMPP DNS records just be looked up over encrypted channels (TLS, https, quic, curve), and only directtls/quic/https connections must be made over port 443 and with ECH, the end

Anything else is legacy and must be phased out as quickly as possible

Even that is legacy, unless your connection is to the edge compute node or CDN proxy your ISP hosts.

Nah everyone should be hosting their own and no one in between should be able to tell XMPP from https from websocket from NFS etc, not even domain name