Hosting multiple different services on the same server and under the same domain name used to be simple. Set-up the services, optionally add MX or SRV records to the DNS zone if they are being run under a different IP, and you’re done. Hosting XMPP, SMTP, POP, IMAP, SSH, HTTP on the same domain was trivial, because they all by default use different ports.

Thanks to web-2.0-isation of the Internet, however, everything now seems to be hell-bent on using HTTP/HTTPS as the transport layer. This means, basically, that you cannot (for example) have StatusNet and Diaspora on the same server – simply because they both use port 80 (or with SSL/TLS, port 443) and have similar API paths. In other words, there is no way do distinguish between an API request to one or the other if they are both set up under the same domain name.

Thus, in this glorious 21st century we have made a huge step backwards – we now can’t really host multiple services under the same domain anymore.

Let’s fix it!¶

Introducing services.txt. Just like robots.txt and humans.txt, this human-readable file sits in the root directory of the webserver under a given domain, and informs any and all interested parties (including other instances of a given service, and that’s the crux!), that when they are looking for service X under this domain, they should use a given path.

Proposed syntax (but hey, let’s talk about it!):

servicename/apiname:version:path

• servicename/apiname: a name of the service or api a given entry describes; in our example it would be ostatus (StatusNet implements the OStatus protocol) or diaspora,
• version: either a version number (i.e. 1.0), or an asterisk to denote that any version will do,
• path: this can either be a local path (i.e. /servicename), or a full URL if the service resides on a different server and/or port.

All lines starting with a hash (#) are considered comments and ignored.

So, if I had a StatusNet (ver.1.0) instance and a Diaspora instance running under this domain name, with the former running under /statusnet and the latter actually running under a subdomain dias.rys.io and accessible only via HTTPS on non-standard port 9443, my status.txt file would look thus:

# example services.txt file
# for rys.io
ostatus:1.0:/statusnet
diaspora:*:https://diasp.rys.io:9443

Of course having a service entry in services.txt would be optional – that is, if another instance of a given service wants to try to contact my instance and can’t find the entry for it (or, indeed, there is no services.txt file available), it just proceeds in a default manner for a given service.