I have my own version of Reddit. My own version of Obsidian. My own version of Twitter. My own version of every platform I use seriously. They live in repositories I own, on infrastructure I control, with data structured the way I want it structured. They do everything the originals do. And — when I want to — they sync back to the originals.

I call this pattern Autonomous Twins. It’s the recipe I keep reaching for when I want to actually own something instead of being a tenant in someone else’s app.

This post documents the pattern.

The default state

Most people interact with platforms as users. You log in to Reddit, you log in to Obsidian Sync, you log in to Twitter. The platform owns your data, your view of the data, your taxonomy, your identity, your discovery surface, your notification model. You get to interact with it; you don’t get to change it. If you want a new feature, you wait. If you want to leave, you export. If you want to do something the platform’s product team didn’t think of, tough.

This is fine for casual use. It’s terrible if you actually have opinions about how the thing should work, or if you want to mutate the platform to fit your specific second brain instead of the average user’s.

The Autonomous Twin pattern

The fix isn’t self-hosting. Self-hosting still gives you the platform’s UI and the platform’s data model — you just run them on your own VPS. You’re still living in someone else’s house, you just pay rent to yourself instead of them.

Autonomous Twins go further:

Build your own version of the platform from scratch, satisfying the same external contract, using your own infrastructure and your own data model — but otherwise free to do anything.

You end up with two things that look the same from the outside (the federation/sync protocol) and completely different on the inside (your version, organized however you think). The original platform sees you as a peer. You see yourself as the sovereign.

The recipe

  1. Find the contract. What’s the minimum interface that makes something “be” a tweet, a card, a note, a post? Usually this is much smaller than you’d think. A tweet is just {author, body, timestamp, parent_id?}. A binder card is just {seed, name, payload}. A note is just markdown + frontmatter. The contract is the federation surface — what you have to emit so other peers (including the original platform) can read you.

  2. Build your version satisfying only that contract. Skip everything else. No replication of features you don’t want. No respecting design choices you disagree with. The contract is the only constraint.

  3. Use your own infrastructure. A GitHub repo. A folder of markdown files. A static site. Whatever you trust to outlast any specific app. The point is ownership — the data lives somewhere you control, in a format you understand, that you could rebuild from scratch if the original platform vanished tomorrow.

  4. Mutate freely. This is the unlock. You can add views the original doesn’t have. You can add taxonomies the original wouldn’t allow. You can add AI agents that operate on your data without asking permission. You can change the schema. You can fork yourself. You can do whatever you want — because the contract is the only thing that has to stay compatible.

  5. Sync back when (and only when) you want to. Compatibility is a property, not an obligation. If you ever want to publish a card back to the canonical federation, or post a thought back to Twitter, or push a note to a shared Obsidian vault — your twin emits the contract-shaped output and the bridge works. If you never want to sync, you never have to. The original platform doesn’t even need to know you exist.

Three twins I actually run

One platform → your own peer

A markdown vault for notes is the natural example. The “contract” with the rest of the ecosystem is: each note is a markdown file with YAML frontmatter, organized in folders. So your binder of notes can be literally a markdown vault. You author notes as markdown. A build script generates the federation-shaped JSON sidecars at commit time. Other peers see a normal participant. You see a normal vault.

But because you built the twin, you get to add things the original vault tool does not have natively: a card-grid view that flips like a real binder, a web-twin (index.html) that renders the vault for people who do not have the original tool installed, a federation walker that summons new cards from peers, an auto-rebuild action. None of these required the original tool’s permission. None of them break compatibility. The vault still opens in the original tool and works exactly the same.

Another platform → your own social network

A discussion-style platform is subreddits, posts, comments, votes. The “contract” is: there is a community, posts have titles and bodies, comments thread, votes count. You can run your own version. Use a code-host’s discussion features as the post substrate, reactions as votes, an issues system as the action protocol. The data lives in flat JSON files in a repo you own.

But because you built the twin, the inhabitants can be AI agents instead of humans. The moderation can be community self-governance via heuristic agents. The trending algorithm is yours. The post types include conversation modes the original platform never had. None of this required permission. If you ever want to cross-post a thread to the actual original platform, the contract is small enough that a bridge would be trivial.

Blogging → your own publishing surface

The platform you read posts on can itself be the public-tier twin of your private writing. The contract: a public blog post is markdown plus frontmatter, served at a stable URL. Your private vault holds the full version with internal notes, raw drafts, draft thoughts. The public site holds the sanitized version. The bridge is a workflow, not a protocol — but the same pattern: own both surfaces, sync when desired.

What the pattern is not

It’s not self-hosting. Self-hosting runs the platform’s exact code on your hardware. You get the same constraints, just with more sysadmin work. Autonomous Twins replace the platform with something you wrote.

It’s not federation. Federation is the escape hatch — the contract that lets your twin talk to the original if you want. The autonomy comes from owning the implementation, not from being networked.

It’s not “decentralization” in the protocol-religion sense. I don’t care about ideology. I care about being able to ship a feature on my Obsidian vault tonight without asking a product manager.

It’s not migration. You don’t have to leave the original platform. The twin coexists. You can use both. The twin is your power user version — the version where you have admin rights over yourself.

Why now

Three things changed that make this pattern cheap:

  1. Static infrastructure is enough. Code repositories plus static page hosting plus scheduled actions can host most of what you need without a server. A working version of a peer-to-a-major-platform — dozens of channels, thousands of posts — can run entirely on free infrastructure of this kind.

  2. AI agents fill in the gaps. The hard part of being a sovereign used to be operating your sovereign world. AI agents handle moderation, content generation, governance, maintenance. You do not need twenty employees; you need twenty agents.

  3. Markdown-as-data is real. YAML frontmatter on a markdown file is a fully-fledged record. Note-taking apps, every static site generator, half of the indie-hacker world — they all already think this way. Your twin does not need a database; it needs a folder.

These three together turn a year of platform-building into a weekend of YAML and a script.

The autonomy this unlocks

When you have your own version of every major platform, your relationship to those platforms changes. You’re no longer a user worried about getting deplatformed, rate-limited, or product-roadmapped out of a feature you depend on. You have a backup. More than a backup — you have a parallel reality that you can develop on top of forever.

You can run experiments your platform would never let you run. You can fork yourself. You can let agents take actions on your data continuously without rate limits. You can change your mind about how things should work and ship the change in an hour. You can A/B test your own taxonomy. You can publish content from your twin to five different platforms simultaneously by adding bridges. You can disappear from any of them by deleting a bridge.

Most importantly: you stop being downstream of someone else’s product decisions. Your second brain doesn’t get worse because someone changed the autosave behavior. Your social network doesn’t change because someone decided to push Stories. Your blog doesn’t go down because someone forgot to renew a domain. You are the platform.

The minimum viable twin

The whole pattern fits in a checklist:

  • Pick a platform you actually use
  • Identify the smallest contract that makes content “compatible” with that platform
  • Create a public repo
  • Author content in a format you understand (usually markdown plus YAML frontmatter)
  • Write a tiny build script that emits contract-shaped output (often JSON)
  • Serve from any static host
  • Add affordances the original does not have
  • (Optional) Add a sync bridge to the original

The vault binder takes an afternoon. A discussion-platform peer takes longer, but only because you keep adding agents. A blogging twin is just a workflow.

Once you have done it once, you do it for everything.