Hacker News Reader

Comment by zenmac | Hacker News Reader

One potential issue with XMPP is the default port is commonly blocked on public wifi.

There is an nginx-xmpp to proxy it, but it is archived. https://github.com/robn/nginx-xmpp

For that reason http based protocol just seems much easier on the network or something that can be easily reverse proxied without extensions will be easier to self-host and have wilder internet connection accessibility.

View on HN

At least Prosody implements BOSH (xmpp over http) and communication over Websocket.

https://prosody.im/doc/setting_up_bosh

https://prosody.im/doc/modules/mod_websocket

But I never tried it myself and from a quick search the popular non-browser XMPP apps/clients don't seem to use it.

with chat control on the horizon, they should probably consider implementing it

I actually enabled BOSH on my Prosody setup.

For reference: https://www.someodd.zip/phlog-mirror/xmpp-server.gopher

BOSH still has some interesting trade-offs even today. It can help with some NAT headaches and rides over plain HTTPS. I like this old post:

https://metajack.im/2008/07/02/xmpp-is-better-with-bosh/

Curious who here uses BOSH in production and/or WebSocket (RFC 7395) these days.

Not for 13ish years but we built the chat feature in a social networking platform with BOSH. Looked just like FB Messenger, really. The thing never took off, so I don't remember any talks about outside federation, I think it was not on by default.

The default ports are often blocked on such networks (public wifi, corporate firewalls, etc.), but also often open. 5222 is used by e.g. WhatsApp, 5223 is used by e.g. Apple push notifications. So it's not as bad as it could be.

But it's also totally possible to run XMPP over 443, and this is a feature of many popular XMPP deployments. If you're self-hosting, there are some guides for different deployment approaches here: https://wiki.xmpp.org/web/Tech_pages/XEP-0368

> 5222 is used by e.g. WhatsApp

I left in 2019, but when I was there, WhatsApp used port 5222, but the client would try port 443 if port 5222 didn't work. After it had tried those enough, it would try on port 80 with HTTP wrappers.

Really, the right model for a public service is what AOL did for AIM. Listen on all the ports. Clients should try on the 'proper' port, then 443, then 80, then random permutation. Skip certain ports because nobody likes it if you probe on smtp, smb, or chargen (etc)

Yeah. I'd be surprised if Apple didn't use similar logic. XMPP can do multiple ports (a deployment can specify the recommended order in DNS). I've not heard of an all-ports deployment, but it does sound like an interesting experiment :)

Apple has a bit of an easier time, because they can (and do) lean on cellular carriers that restrict access to their push servers. And they have 17.0.0.0/8

But they say port 5223 and 2197 with fallback to 443 [1]. Google says 5228-5230 and 443, with a couple outliers [2].

[1] https://support.apple.com/en-us/102266

[2] https://support.google.com/work/android/answer/10513641?hl=e...

You don't need any third party modules and can proxy based on ALPN (https://wiki.xmpp.org/web/Tech_pages/XEP-0368#nginx) thus running everything on port 443. Note that ALPN is not encrypted AFAIK but public wifi services don't care.

Reply on news.ycombinator.com