About distributed[C]

(This post is about distributed[C], an experimental decentralized publishing platform Haad and myself were running through 2021-2022. It’s currently inactive.)

distributed[C] came about originally as a design experiment, thinking that a completely peer-to-peer Tumblr would be a great testbed for swarm-based design (more on that later).

The key actions would be:

1. Making a post
2. Subscribing to someone else’s posts
3. Updating a post
4. Deleting a post
5. Reblogging someone else’s stuff and adding your own content

Actions 1-4 are easily done with something like ActivityPub. Action 5 is a bit different. When you reblog something, you:

• Duplicate the original content and embed it into yours,
• Add your own content right after (could be empty, or just tags)

You don’t just reference the original content, which could disappear after you duplicate it. This means that any changes the creator makes are not relevant to your reblog. We are talking about duplication vs. dereferencing.

This should allow content creation and remixing, taking a life of its own as the swarm interacts with it.

No, this is not Git

There are several ways in which this is not “git for content”:

• There is an expectation on Git that the repository will converge into a canonical version, but there is no such expectation for this;
• There is no need for merging or conflict resolution;
• You are “forking” a particular piece of content, not the creator’s entire post history.

Why is this a good test bed?

It will require decentralized identity:

• We need to identify creators so that we can reference where the original post came from;
• Every user needs to be able to edit only their own content;
• We may want to have a private setting where only allowed users can follow someone.

It will require decentralized storage, since every user may want to store their information on their own domain.

If it is a protocol, instead of a domain like Tumblr, it may enable interactions that we cannot expect.

It highlights that “ownership” is merely the illusion of control - once you put content out there, it takes on a life of its own.

But at the same time, it has some constraints which make development easier:

• There is no availability expectation, because we are not dereferencing the original piece of content - if user A’s blog went away after user B had already reblogged then, the reblogged content still lives on;
• We are pushing the responsibility for deciding which content is valuable onto the users - content people care about will live on as it is reblogged, or as long as the original creator keeps their blog up.
• Composability is strictly linear;
• We do not worry about conflicts;
• Every user is responsible for how much data they want to keep around.

This is not the thing

This may be monetizable by hosting and backups and content replication, but that is not the point.

The point is that this allows us to build infrastructure for empowered, but temporary communities, which will then tell us what they want to do with the technology.

The nature of the thing is what people use it for.

And (parroting Halt and Catch Fire) this application is not the thing - it’s the thing that gets us to the thing.

Go to the homepage, name your account, export your keys. Join us. Let’s figure this thing out together.

Published: 2021-09-10