---
title: >-
  SERVICES.TXT
date: 2012-11-02 11:54
modified: 2012-11-02 11:54
lang: en
authors: rysiek
tags:
 - ancient
status: published
pinned: false
---

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](http://en.wikipedia.org/wiki/MX_record) or [SRV](http://en.wikipedia.org/wiki/SRV_record) records to the [DNS](http://en.wikipedia.org/wiki/Domain_Name_System) zone if they are being run under a different IP, and you're done. Hosting [XMPP](http://en.wikipedia.org/wiki/XMPP), [SMTP](http://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol), [POP](http://en.wikipedia.org/wiki/Post_Office_Protocol), [IMAP](http://en.wikipedia.org/wiki/Internet_Message_Access_Protocol), [SSH](http://en.wikipedia.org/wiki/Secure_Shell), [HTTP](http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol) on the same domain was trivial, because they all by default use different [ports](http://en.wikipedia.org/wiki/TCP_and_UDP_port).

Thanks to web-2.0-isation of the Internet, however, everything now seems to be hell-bent on using HTTP/[HTTPS](http://en.wikipedia.org/wiki/HTTPS) as the transport layer. This means, basically, that you cannot (for example) have [StatusNet](http://en.wikipedia.org/wiki/StatusNet) and [Diaspora](http://en.wikipedia.org/wiki/Diaspora_%28software%29) on the same server -- simply because they both use port 80 (or with SSL/TLS, port 443) and have similar [API](http://en.wikipedia.org/wiki/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`](http://en.wikipedia.org/wiki/Robots.txt) and [`humans.txt`](http://en.wikipedia.org/wiki/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) 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](http://en.wikipedia.org/wiki/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.