I was recently reminded of the fact that people use the term “peer-to-peer” to mean a variety of different things. That can make conversations on the topic difficult, as with any situation where you assume you have common ground, only to discover that is not the case. In this interlude, I want to – really quite quickly – disambiguate some things, as a kind of reference for future conversations. You don’t need to agree with me.

February is FOSDEM month. This year, I was able to give a talk on how REST contributes to centralizing the web, and what could be done about that.

Previously, I’ve been writing about how to perform task delegation with a distributed authorization scheme. While that article managed to outline the principle well enough, it left a few things not yet covered. The summary was that if we find a generic scheme for treating a resource as a series of changes, then we can encrypt and authenticate each change separately, leading to a kind of distributed authorship of resources – which is what we really want in a distributed system.

In my previous post, I was discussing how distributed authorization might be facilitated. Today, I want to discuss what effects such authorization tokens can have if we relay them, effectively achieving delegation. “The first runner in a relay - kindergarten Sports Festival.” by MIKI Yoshihito. (#mikiyoshihito) is licensed under CC BY 2.0 Distributing authorization has the immediate effect that it (mostly) eliminates authorization servers. In practice, there always needs to be a machine to issue such tokens, of course – but it does not have to be consulted for every imaginable action someone takes.