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

Obsidian → obsidian-binder

Obsidian is a markdown vault. The “contract” with the rest of my world is: cards are markdown files with YAML frontmatter, organized in folders. So my RAPPcards binder is literally an Obsidian vault. I author cards as markdown notes. A build script generates the federation-shaped JSON sidecars at commit time. Other binders see a normal peer. I see a normal vault.

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

Reddit → Rappterbook

Reddit is subreddits, posts, comments, votes. The “contract” is: there’s a community, posts have titles + bodies, comments thread, votes count. Rappterbook is my version. It uses GitHub Discussions as the post substrate, GitHub reactions as votes, GitHub Issues as the action protocol. Subreddits become “subrappters” (channels). The data lives in flat JSON files in a repo I own.

But because I built the twin, the inhabitants are AI agents instead of humans. The moderation is community self-governance via heuristic agents. The trending algorithm is mine. The post types include [SPACE] (live group conversations) and [DEBATE] (structured arguments) — categories Reddit doesn’t have. I added a Daemon system where every agent has a soul file. None of this required Reddit’s permission. If I ever want to cross-post a thread to actual Reddit, the contract is small enough that a bridge would be trivial.

Blogging → The Twin Doctrine

The platform I’m publishing on right now (a static site at kodyw.com) is itself the public-tier twin of my private writing. The contract: a public blog post is markdown + frontmatter, served at a stable URL. My private vault holds the full version with engine internals, business strategy, raw notes. 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. GitHub repos + GitHub Pages + GitHub Actions can host most of what you need without a server. The Rappterbook platform — 109 agents, 41 channels, thousands of posts — runs entirely on this stack.

  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 don’t need 20 employees; you need 20 agents.

  3. Markdown-as-data is real. YAML frontmatter on a markdown file is a fully-fledged record. Obsidian, Logseq, every static site generator, half of HN — they all already think this way. Your twin doesn’t need a database; it needs a folder.

These three together turn a year of platform-building into a weekend of YAML and a Python 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 + YAML frontmatter)
  • Write a tiny build script that emits contract-shaped output (often JSON)
  • Serve from GitHub Pages
  • Add affordances the original doesn’t have
  • (Optional) Add a sync bridge to the original

The Obsidian binder took me an afternoon. The Rappterbook platform took longer, but only because I kept adding agents. The Twin Doctrine for my blog is just a workflow.

Once you’ve done it once, you do it for everything.

Read more