Two different publish models
A sharing tool starts from a human at a browser: choose a file, set who can see it, copy the link. A publish primitive starts from a caller with a document and no browser: one authenticated request, one URL back, and every setting expressible as a parameter. Both end in a link. Only one of them can be a step inside a loop.
Where a sharing tool genuinely wins
When the author is a person, an interface beats an API every time. Uploading arbitrary file types, previewing them without a browser plugin, organising them into folders, handing a colleague something that is not HTML — these are all things a sharing product does that this deliberately does not. This hosts documents that render in a browser, and nothing else.
Where a publish primitive genuinely wins
Everything downstream of "the author is a program". Twelve MCP tools, so the agent publishes the way it writes a file. Replace-in-place, so an artifact revised eight times keeps one URL. Machine-readable engagement, so the loop can tell whether anyone read the thing. And a strict viewer policy applied to bytes the agent generated rather than bytes a human vetted.
Privacy and gating compared
Both put controls on links. The difference is where the control lives: a sharing tool generally attaches permissions to an account and a file, and this attaches them to a link.
| Control | Here |
|---|---|
| Unguessable link | Default. 22 characters of entropy; the link is the credential. |
| Shared passphrase | set_password, or PATCH /sites/:id. |
| Work-email domain | set_email_gate — the recipient verifies, so forwarding does not transfer access. |
| One-time view | Burn after reading: first open 200, second 410. |
| Expiry | On by default, and the purge deletes the object, not just the row. |
| End-to-end encryption | Key stays in the URL fragment; the server stores ciphertext. |
Pricing shape
Sharing products price per seat, because a seat is a person and a person is the customer. An
agent has no seat, which is why metered publish calls became the norm for this category instead.
This deployment does neither: it runs on your own account, so the cost is your infrastructure
bill and the limits are variables in wrangler.toml.
Side by side
| OpenTree | A file-sharing tool | |
|---|---|---|
| Intended author | A program | A person |
| Publish action | One tool call or one HTTP request | Upload in a browser |
| Accepted input | HTML, markdown, SVG, zip | Most file types |
| Same URL after revision | Yes, by design | Usually a new upload |
| Access control | Per link | Per account and file |
| Reader feedback | Toolbar, reactions, notes, engagement data | Comments, if offered |
| Where it runs | Your own account | Their service |
Who each is for
If you are a person with a folder of mixed files to hand to a colleague, use a sharing tool.
If the sentence starts with "my agent produced" and ends with "and it needs to be private", this
is the shape that fits, and the exit is cheap either way — GET /sites/:id/content hands
back the exact bytes.
Is this a drop-in replacement for a file-sharing tool?
No, and it should not be. It takes documents that render in a browser. A PDF, a spreadsheet or a video belongs somewhere built for those.
Can a human use this without an agent?
Yes — the homepage has a paste box that publishes anonymously, and one curl with an API
key does the same thing. The agent path is the design centre, not a gate.
What happens to my pages if I stop using this?
They are your bytes on your own storage. GET /sites/:idOrSlug/content returns each
document exactly as served, and /raw/:token returns the text.
Do viewers need an account?
Never, unless you turn on the email gate — and then they verify an address rather than create an account here.