Port numbers

Packaging
#1

We should ensure that AP URLs can contain port numbers. I believe this is the single most helpful thing that we can provide to people experimenting with server software.

At present, some clients restrict port numbers to 443, sometimes trying 80 first. A person can install any package they like, but to test it they need both root access and a separate publicly-visible hostname and IP address which isn’t already running a web service. This can be a tall order.

This may be the case for some servers too— I don’t know. But I think everyone should check their code, client or server, to ensure that port numbers work.

This also applies to custom protocols such as Mastodon!

(Possible #hackathon topic?)

2 Likes
#2

Friendica should have handled this. But this is mostly untested.

1 Like
#3

Pleroma should loosely support it federation-wise (it need tests but stuff like WebFinger is a limitation, see https://git.pleroma.social/pleroma/pleroma/-/issues/1881 ), but it definitely does for just offline/LAN testing (the dev server uses 4000 by default, which is changeable in the config).
And pleroma never runs as root, 80/433 is done with a reverse proxy like nginx/varnish/OpenBSD-relayd that forward to 4000 or any other port chosen, so root access isn’t really needed.
For non-restricted ports it could be directly pleroma but I would still recommend using a reverse proxy to get some separation from the outside and avoid having TLS keys readable by pleroma.

1 Like
#4

Why wouldn’t webfinger work? The RFC requires the request to use HTTPS, but it doesn’t say anything about what port it should use. Obviously in the general case you use 443, but if someone’s running an AP service on a custom port it’s reasonable to assume the webfinger service will be provided there as well.

#5

(FTAOD I wasn’t talking about production use of a server, where something like nginx would be used, but about informal testing to see whether the software is appropriate for someone’s needs.)

1 Like