On Federated Services
It’s probably worth pointing out that there’s a certain class of digital service, that doesn’t fit a neat definition of “being located in”. These are typically decentralised and federated services. You may have heard of federated services like mastodonjoinmastodon.org, pixelfedpixelfed.org or matrixmatrix.org, often touted as alternatives to X, instagram or WhatsApp. But you can also think of email as being a federated service.
Probably the most familiar way of thinking about this, is email. For instance if I have barry.example@gmail.com I can send an email to customer.support@retail.shop and know that the two servers can talk to each other. But there are many protocols, and many federated services.
I won’t go into the pros and cons of creating, running, hosting or even using federated services but, for the purposes of our needs it’s important to understand one thing. Every service comes with an implied, sometimes explicit, terms of service. i.e “these are the things that we say we’ll do; the kind of service that you can expect; our expectations of what we do with your data; and how we expect you to behave.”
It is these terms of service which guide our understanding of where a service “is”. Data hosted on a computer in the UK may be treated differently than data hosted on a server in Russia. Legal challenges must be answered under a governing law. Organisational structure can influence the expectation of how money is spent and profits taxed.
This presents a bit of a challenge for us. How do I reflect federated services in the directory? Do I list every UK mastodon server? Maybe, if there’s not too many. Do I create a category for decentralised and federated services? Possibly, but then do I need a category for every protocol? Every implementation of a protocol?
I’m not sure yet, but it is on my mind, and I will do my best to reflect the breadth of Federated services in the UK.