{
  "$type": "site.standard.document",
  "canonicalUrl": "https://numergent.com/2021-09/About-distributed-C.html",
  "path": "/2021-09/About-distributed-C.html",
  "publishedAt": "2021-09-10T06:56:07.000Z",
  "site": "at://did:plc:cf6futaebyc2k4wgzsr4v42k/site.standard.publication/3mp2ewx43js2g",
  "tags": [
    "distributedC",
    "decentralization",
    "composability"
  ],
  "textContent": "(This post is about distributed[C], an experimental decentralized publishing platform Haad and myself were running through 2021-2022. It's currently inactive.)\n\ndistributed[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). \n\n\n\nThe key actions would be:\n\n1. Making a post\n2. Subscribing to someone else's posts\n3. Updating a post\n4. Deleting a post\n5. Reblogging someone else's stuff and adding your own content\n\nActions 1-4 are easily done with something like ActivityPub. Action 5 is a bit different. When you reblog something, you:\n\n- Duplicate the original content and embed it into yours,\n- Add your own content right after (could be empty, or just tags)\n\nYou 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.\n\nThis should allow content creation and remixing, taking a life of its own as the swarm interacts with it.\n\nNo, this is not Git\n\nThere are several ways in which this is not \"git for content\":\n\n- There is an expectation on Git that the repository will converge into a canonical version, but there is no such expectation for this;\n- There is no need for merging or conflict resolution;\n- You are \"forking\" a particular piece of content, not the creator's entire post history.\n\nWhy is this a good test bed?\n\nIt will require decentralized identity:\n\n- We need to identify creators so that we can reference where the original post came from;\n- Every user needs to be able to edit only their own content;\n- We may want to have a private setting where only allowed users can follow someone.\n\nIt will require decentralized storage, since every user may want to store their information on their own domain.\n\nIf it is a protocol, instead of a domain like Tumblr, it may enable interactions that we cannot expect.\n\nIt highlights that \"ownership\" is merely the illusion of control - once you put content out there, it takes on a life of its own.\n\nBut at the same time,  it has some constraints which make development easier:\n\n- 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;\n- 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.\n- Composability is strictly linear;\n- We do not worry about conflicts;\n- Every user is responsible for how much data they want to keep around.\n\nThis is not the thing\n\nThis may be monetizable by hosting and backups and content replication, but that is not the point.\n\nThe 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. \n\nThe nature of the thing is what people use it for.\n\nAnd (parroting Halt and Catch Fire) this application is not the thing - it's the thing that gets us to the thing.\n\nGo to the homepage, name your account, export your keys. Join us. Let's figure this thing out together.",
  "title": "About distributed[C]"
}