Skip to main content

Posts on the protocol

A post on DFOS gets a life on the protocol — just like a profile, but for the work itself. The post becomes its own signed content chain, anchored on the public relay, where anyone can check it without trusting our servers. How much that chain reveals depends on whether the post is publicly readable, and on a setting the space controls.

Who signs

Two signatures make a post verifiable:

  • The space's protocol identity creates and signs the post's chain — this is how "this space published it" is provable.
  • The credited author signs their own claim on the post — this is how "this person made it" is provable.

So both facts stand on their own cryptographically: the space that published the work, and the person who made it.

Two kinds of proof

A publicly readable post publishes a full proof. Its document travels to the relay with a standing read credential attached — the protocol's way of saying "anyone may read this" — so anyone can fetch the post and verify it end-to-end. The post is already published on the open web; the proof adds portability and verifiability, not exposure.

A members-only post publishes an existence proof instead. Its chain is anchored on the relay with no read credential at all. The network learns that this space anchored a post at this moment, and can never read a byte of it. There is no key to hand out, because none was ever issued: the document's bytes are not served to anyone without an active read credential, and a members-only post doesn't have one.

So an existence proof reveals a space, a moment, and the chain's identifiers. It carries no title, no body, no media, and not even the credited author — those all live inside the document, and the document isn't served.

Two more things are visible, and both are worth knowing. The chain's shape: every edit to the post appends another signed operation, and the number of operations and the time of the latest one are public — so an observer can tell that a members-only post was revised, and when, while never learning what changed. And the date is an assertion: the space signs a commitment to the exact document and states when the post was created, which is what makes an existence proof useful for claiming priority on work you haven't published. It is the space's own claim, though, not a fact about the bytes — an imported post can honestly carry the date it was originally written. What nobody has to take on trust is when the proof reached the relay, because the relay's log records that itself.

Publishing an existence proof never makes private content readable by anyone.

And on a public post, only the public part travels. If the post has a fold, what's below it stays inside the space and is not part of the signed document. Topics, emails, and memberships are never part of it either.

What a space chooses

A space decides exactly one thing here, in its settings under Protocol: who may verify that its members-only posts exist.

  • No one (the default) — members-only posts make no claim on the network at all.
  • Everyone — members-only posts publish existence proofs, anchored on the public relay for anyone to check.

A space starts at No one: nothing about its private posts reaches the network unless the space deliberately opts in to publishing existence proofs.

Publicly readable posts always publish full proofs, at either setting. That is deliberately not a rung on the dial: a post the space has already published on the open web is proved on the protocol too, and there is nothing to withhold that the post itself doesn't already say. So the choice is only ever about the posts nobody outside the space can read.

A space's own identity chain is not affected by any of this. Whatever the setting, the space stays resolvable and its members' and groups' identities are untouched — the choice governs a space's posts, nothing else.

A short delay before proofs go live

A post doesn't hit the protocol the instant it's published — there's a short delay first, so a quick typo fix in the moments after publishing doesn't get immortalized on the relay.

Taking proofs back

Turning a setting down withdraws the proofs it no longer covers, and the withdrawal is real: the proof is removed from the relay's public record entirely, including the log other relays copy from. A withdrawn proof is gone, not hidden; no marker is left saying something used to be there.

Worth being precise about the reach of that: it covers the DFOS relay, the canonical relay for this data. The protocol allows independent relays to mirror the log, and withdrawal removes a proof from ours — not from a copy someone else has already taken. See Relays & verification.

One thing is deliberately kept. If a post was publicly readable, its read credential is revoked before the chain is removed, and the revocation stays — so anyone who captured that credential while the post was public sees it as revoked rather than as unknown. Withdrawal never leaves a credential in limbo.

Withdrawal waits a short grace period before it runs. Turn the setting back on inside that window and nothing is withdrawn at all — a mis-click costs nothing.

Turning a setting back up anchors the space's posts again. A proof's identifier is derived from the post itself, so an unedited post comes back under the same identifier and old links resolve again. Only a post that actually changed in the meantime gets a new one — a changed title, body, media, publication date, or credited author.

Making a public post private again is immediate

Un-publicizing a post — or deleting it — revokes its public readability at the relay right away. There's no delay on the way out: the standing read credential is revoked, and the post is no longer publicly readable. (That's a protocol-level credential attached to the content itself — not the kind of credential an app is issued when you sign in to it with DFOS.)

What happens to the chain next depends on the space's setting. At Everyone, the post keeps its chain minus the credential — which is exactly an existence proof, the same thing a members-only post would have published in the first place. At No one, a members-only post doesn't qualify for a proof at all, so the chain is withdrawn outright. That withdrawal is immediate: the withdrawal grace period protects a space from a mis-click on the setting, and nothing about the setting changed here — the post did.

The content stops being served the moment the credential is revoked. The relay's convenience listing of public posts is a step behind: it can take a few minutes to drop what it was showing. A post that was never public was never in it. Verification always reads the signed records themselves, never that listing.

Verify it yourself

Same as profiles: fetch a public post from the relay and verify the signatures, the chain, and the document end-to-end with open-source tools — no DFOS account, no trust in DFOS servers. Paste a post's content id into explore.dfos.com to watch that happen in your own browser, or see Relays & verification for the command-line path. The rules being checked are the protocol specification.