When you share a Google Doc, you keep the keys. The URL stays the same. You edit; the recipient sees your edits. The document is a shared object with one canonical state, and you are its caretaker. When you share a reWritable, it's a different story.
You upload your .html file to the share service. It returns a URL. You send it. The recipient opens it and sees your document. So far, this looks like sharing.
But on the way in, the server did something quiet and decisive: it stamped a new identity onto the document. The published copy has a different DOC_UUID than the file sitting on your disk. Different per-container IndexedDB namespace. Different undo history. No edit log between them. The publish is not a hosted view of your document. It is a sibling — born at the moment of publication, related to you only by appearance.
There is no PUT endpoint, no owner token, no path that says "this share is mine, here's the update." The document the recipient receives is the document you uploaded — immutable from the moment of publication, regardless of how long the URL keeps resolving.
What sharing actually is
I think most sharing UIs conflate two things: distributing documents and maintaining a canonical reference. Cloud productivity tools collapsed them — the URL is both how the document gets to you and where the document lives. Edit the document and the URL still works; the document behind it changes.
That works because the URL is the document. The bytes on your screen are a rendered view of state on a server. You don't have the document; you have a window into it.
reWritable starts from a different commitment. The document is the file. The .html you hold on disk is not a view of something; it is the thing. Open it twice, you get the same document. Send it to someone, they have it — fully, durably, without dependency on you or on a server.
A sharing model that let the publisher keep editing the shared document would break this. The recipient, opening the URL on Tuesday, would see one document; the same URL on Wednesday would show a different one. Their copy — if they downloaded it — would diverge from "the share" the moment the publisher updated. Were they reading v1 or v2? Were the bytes they ⌘S'd "the document" or just one of its passing states?
The fork-on-share model avoids the question by turning the URL conceptually into a courier, not an address. What it delivers is a file, fully self-contained, owned by whoever opens it from the moment it arrives.
The read/write web, the whole way
This design approach connects to a much older line of thought. The first web browser, WorldWideWeb, built by Tim Berners-Lee in 1990 on a NeXT computer, was a browser-editor. You could open a page, mark text, link to another open document, and save the result. The web was conceived as a read/write medium — every reader also an author, every page editable in place. Berners-Lee has been clear, looking back, that the original intent was for anyone using the web to have a space where they could write, and that the first browser was built as an editor precisely so they could.
What arrived instead was a read-mostly distribution medium, with authorship pushed to specialists and platforms. Cloud productivity later recovered some of the writeability — Google Docs, Notion, Figma — but on different terms. The document moved off your machine and into someone else's database. The URL replaced the file. Sharing became "granting access to a record I control." Editing became something that happened on a server, conditional on the server's continued cooperation.
One detail from the original WorldWideWeb editor is telling in this regard. Edit-and-save, in the 1990 browser, wrote back to the local filesystem. HTTP PUT — the protocol to write edited files back to a remote server — was added years later, in HTTP/1.1. The very earliest read/write web was a local-file editing model: you authored your file locally, you served it from a machine you controlled, others fetched and read it. The author held the bytes.
That's the substrate the cloud era traded away. Google Docs kept "everyone can author" and gave up "the file is yours." Solid, Berners-Lee's more recent project, keeps "the file is yours" but at a URL on a personal server — preserving the URL-as-canonical-identity assumption that came in later.
A reWritable different. The file is the document. The editor is in the file. Distribution means handing over the file. Fork-on-share is what sharing has to mean once you commit to all three.
This is not the only path through Berners-Lee's diagnosis — Solid is a different one, and a coherent one. But it may be the path most faithful to what the 1990 browser actually was: bytes on a machine you control, edited locally, shared by being given.
Seeding, not syncing
There's a practical reason to like fork-on-share that the philosophical framing has been understating. Writing edits back to a server, in the general case, is hard. The hard parts aren't the network calls — those are trivial. The hard parts are the questions the network calls raise. Who is allowed to write, and how do they prove it? What does "the current version" mean when ten people have made changes? When two writers edit the same paragraph in the same hour, whose change wins, and can we keep both?
We have systems that take these questions seriously. Git is the most famous one — three decades of design effort dedicated to letting many people write to a shared history of a shared artifact, with merge tooling, branch policies, code-review workflows, and a whole sociology of how projects manage all of it. Git is brilliant; git is also, by anyone's standards, complicated. Most documents are not worth that machinery. Most people will not learn it. Most workflows fall over at the first merge conflict.
It's worth noticing what's hard about git specifically. The distribution model — clone gives you a full copy, your local operations are local, you own your tree — is the easy part. The hard part is everything downstream of write-back: push, pull, merge, rebase, conflict resolution, history rewriting. These exist because git tries to maintain coherent shared history across forks. Take away that goal, and the difficulty goes with it.
The cloud productivity suites took a different route: they made the questions go away by making "the document" a thing that lives on a server and that the server arbitrates. There's no merge because nobody has a copy to merge from — everyone is editing the same record. There's no permission question between users because the server enforces it centrally. There's no versioning question because the server keeps an audit log. This works. It also requires the server to exist forever, to remain trustworthy, to not be acquired by someone whose plans for your document differ from yours.
reWritables don't write edits back, reWritables are the seed.
When you publish a re-writeable, what you're doing is putting a fresh seed into the world — a stable, self-contained, fully-formed artifact that someone else can plant. The original you keep is yours; the seed you released is theirs the moment they pick it up. There's no permission to negotiate, because nothing flows back. There's no versioning conflict, because each seed is its own thing, dated to the moment it was planted. There's no conflict resolution, because no two people are writing to the same record.
When the recipient modifies their copy and publishes their version, they are seeding again. The chain of lineage might be visible in what the documents are about — you might recognize "oh, this is descended from that retrospective template I made" — but it isn't enforced anywhere. There's no parent pointer in the file, no diff to the original, no merge waiting in the future. Each published document is a fresh artifact, related to whatever came before only by resemblance.
This is closer to how ideas actually travel. You publish a recipe; a friend modifies it; she publishes hers; her friend modifies it further; six months later a version is circulating that nobody is trying to call "the canonical recipe" because nobody needs to. The recipe is alive in the world as a population of artifacts, each one fully owned by whoever is cooking from it tonight.
Fork-on-share names what happens at the moment of publication. Seeding names the larger pattern that emerges over time. The hard problems of write-back — permissions, versioning, conflict — don't get solved. They get refused, by choosing a model in which they don't arise.
Where fork-on-share earns its keep
Abstract design commitments are only as good as the situations where they pay off. I think for Templates, starters, and playbooks the seed model is at its most natural: here's a starter, customize it. A weekly-retrospective template, an incident-report form, a workout plan, a project kickoff doc. Recipients receive their own copy and evolve it independently. The original keeps changing without their copies drifting underneath them — compare to a Notion template, where publisher edits can propagate in ways that "duplicates" don't always know what to do with. Fork-on-share makes the relationship explicit at the moment of distribution: here's a snapshot; what you do with it is yours. Combined with ⌘K, the recipient doesn't need to understand the template's structure to adapt it. They say what they want; the document rewrites itself.
What this gives up
The fork model gives up things that are worth mentioning:
No collaboration in the Google Docs sense. Two people editing the same share each get their own private fork the moment they touch ⌘K. There is no merge, no sync, no conflict resolution baked into the share. If you want two people to converge on a single document, the workflow is email-with-attachments: A edits, A publishes, B downloads B's copy, B edits, B publishes back, A downloads. Not "everyone in the same document at once."
No mutable canonical URL. You can have stable URLs — permanent share links serving frozen documents — but you cannot have a single URL that serves "the latest." Update means republish, which means a new URL. Distributing the new URL is itself a publisher act. The closest analogy is Git commit hashes rather than branch pointers: every reference points at specific bytes, never at a moving target.
No recall. Sent something you regret? Anyone who pressed ⌘S has the document forever, because that's what it means for a file to be a file. reWritable shares have email semantics, not Slack-edit-and-delete semantics. Once distributed, always out there.
But what about control?
A reader formed by two decades of cloud productivity will reasonably ask: why would you accept this? You're generating unconnected versions of a document that live god knows where, on disks you can't see, in states you can't track. Aren't you're giving up control you might need?
Most of that control is theoretical. The vast majority of shared documents are never updated after sharing, never revoked, and never actively tracked by their publishers. "I can take it back" and "I can see who opened it" are reassurances, not regular practices. What you give up in fork-on-share is mostly the option, not the use. What the recipient gains — durability, ownership, independence from your continued cooperation — they actually use, every time they open the file.
The control you keep in the cloud model is rented. The platform can change terms, deprecate the format, revoke access to your own document, get acquired by an actor whose plans diverge from yours. The "control" of your shared Google Doc is delegated to Google, exercised on your behalf at their discretion. You haven't kept control; you've kept a service-level relationship with a custodian. Fork-on-share trades the custodial relationship for actual property: bytes on disks owned by the people who hold them.
The proliferation worry is largely a cloud-era artifact. Files have been proliferating without central tracking since computing existed — every email attachment, every downloaded PDF, every photo on a friend's phone. We lived with this state for decades without treating it as a fundamental problem with the file. The anxiety about "different versions floating around" is specifically a feature of the brief historical anomaly in which documents lived in central databases, and that location felt like the document's home. File-level distribution isn't a regression; it is the default state of computing returning after a detour.
Some of what gets called "control" is closer to surveillance. "I want to know who's reading my document" is sometimes a legitimate need, but more often it's analytics dressed as governance. Cloud sharing has telemetry baked into the reader's side — when they opened it, how long they spent, what they highlighted, whether they shared it onward. Fork-on-share refuses that asymmetry. Once the file is delivered, what the reader does with it is theirs.
And the cases where central control genuinely matters are different cases. Live financial records, shared inventories, regulatory documents that must show a single canonical version — these need a server arbitrating, and reWritable isn't trying to be the tool for them. Some artifacts should be files; some should be records. The cloud era confused the two by routing everything through the same productivity suites. Fork-on-share is the model for the file side of the line, not for everything that has ever been put in a Google Doc.
None of this makes the trade-off disappear. You really do give up the publisher's ongoing relationship with the shared bytes. But the trade buys something specific: a recipient who actually owns what they hold, an artifact that doesn't depend on you to keep existing, a distribution model that doesn't require a custodian who can change its mind. For the documents that should be files, that's the trade you want.
Fork is the floor, not the ceiling
Fork-on-share is a statement about what publication does: it produces a sovereign copy in the recipient's hands. It is not a statement that the publisher's and the recipient's copies must remain forever unrelated. Two re-writeables, each fully owned, could in principle agree to converge — last-write-wins, CRDT-style merge, patch-based reconciliation, something else entirely. That kind of synchronisation would be an opt-in handshake between two sovereign documents, negotiated by them, walkable-away-from at any time. Not a server pushing updates to recipients. Not a single canonical record everyone else views.
The mechanisms for this don't exist in reWritable today. But fork-on-share is the prerequisite for being able to add them cleanly. The current model already supports voluntary composition on the local disk: containers on the same machine choosing to publish into a shared bus, namespaced, opt-in. Cross-machine sync between sovereign re-writeables would be the same pattern at a different scale — convergence by mutual agreement, not by deference to a central record.
Fork is the architectural floor. What forks then do with each other is open.
Postscript
Fork-on-share is one approach among several — Solid, Google Docs, and git are other examples. None of them is universally right. The argument above is the strongest version I can make for this one; it isn't a proof. It's an experiment, in the plain sense: I build things to see whether they make sense once other people try them out. That's the part I find fun. If you try it and find a use, I'd like to hear about it. If you find the limits, I'd like to hear about that too.
Unlock the Future of Business with AI
Dive into our immersive workshops and equip your team with the tools and knowledge to lead in the AI era.