Content addressing. Every blob is named by the hash of its bytes, a CID. When a blob arrives with a CID attached, whether over the daemon's store RPC, over POST /ipfs/<cid>, or through Bitswap, the daemon recomputes the hash and refuses a mismatch. So a link to a CID is a link to exactly one sequence of bytes, forever, on any node. This makes the end of broken links possible.

Authorship. Every structural blob (Change, Ref, Comment, Capability, Contact, Profile) carries the signer's public key and a signature, Ed25519 or ECDSA P-256 depending on the key, over its canonical DAG-CBOR encoding with the signature field zeroed. The daemon verifies the signature before interpreting the blob. A blob with a bad signature is at most stored as opaque bytes, and is never indexed. So you can re-check "signed by z6Mk…" anywhere, without asking a server. See Blobs for the exact signing rule.

History. A document version is a set of Change CIDs. Each Change links its dependencies and its genesis by CID, so a version pins its entire history as a Merkle DAG. Changing anything in the past changes every CID after it. Replay rejects changes whose declared depth or time runs backwards relative to their dependencies. It also rejects a Ref whose Changes do not share a genesis. See Documents.

Write authority. The daemon indexes only Refs signed by the space owner or by a key holding a matching owner-signed capability. Refs and capabilities are both signed and content-addressed. So a third party can re-verify the whole chain offline: this Ref, this capability, this owner. The rule is in Permissions.

Together, these let a reader who holds a version's CIDs verify three things with no network and no trusted party: who wrote each change, in what order, and that the person who published this version was allowed to.

Timestamps are self-declared. Nothing checks a blob's ts against real time when it is ingested. Ordering inside a document is causal (dependencies). But last-writer-wins resolution of metadata, comment ordering, and generation numbers all read declared times, so a legitimate signer can back-date or forward-date. A capability issued after a Ref authorizes it retroactively. If you need a trustworthy time, anchor the CID externally. The team has discussed OpenTimestamps, but nothing is built.

Nothing checks authorization on Changes and comments. The daemon stores any key's Change. The Change becomes part of a document only through an authorized Ref. Any key can attach a public comment to any document. No layer checks it: not the index, not the API. Moderation is left to clients and sites.

Capabilities never expire and cannot be revoked. A grant is valid on every node that has it, forever. See Permissions for the mitigation: grant narrowly, to keys you control.

Peer identity is separate from account identity. A peer proves it holds an account only when it wants private data, with a signed ephemeral capability fresh within one minute. Public data needs no peer-level trust, because public blobs verify themselves.

Site trust is DNS and HTTPS trust. The peer that https://<siteUrl>/hm/api/config reports is granted the space's private blobs, because the home document says that host is the site. Whoever controls the domain and its certificate controls that trust. A space owner who points siteUrl at a hostile host hands that host their private content.

The local daemon API has no authentication. The gRPC port and the HTTP port accept any caller who can reach them, with CORS open to every origin. Any such caller can list keys, sign with any stored key, export keys, store blobs, create Refs and capabilities with any registered key, or force a reindex. Write RPCs check whether the key may write. They never check the caller. The daemon is designed to be reached only from localhost or behind a firewall. Hosted sites run with -public-only, which hides private content from unauthenticated HTTP requests but does not disable writes.

Bearer tokens are symmetric and daemon-local. A token is sealed with a random per-daemon secret and lasts thirty days. The only way to invalidate it is to rotate that secret. Its only tie to state is that the daemon must still know the principal. It widens reads on public-only nodes and never authorizes a write.

Two CIDs for the same bytes. The daemon hashes with BLAKE2b by default and the SDK hashes with SHA-256. Both are valid CIDs of the same content. The daemon deduplicates by multihash, so a Ref naming the SHA-256 head and another naming the BLAKE2b head of identical bytes are two different documents. Always pass explicit CIDs for blobs that other blobs reference. See Blobs.

Federated social protocols such as ActivityPub verify a message at the transport. The receiving server checks an HTTP signature from the sending server, then stores the content as its own copy under its own authority. If that server goes away or changes its mind, the content and its provenance go with it. Hypermedia puts the signature on the content. Every blob carries its author's signature and its own hash. Any copy, on any node, years later, still proves who wrote it and that nothing changed. Servers are replicas with no authority over the content. The longer argument, and the trade-offs, are in Why signed content.

In the Seed app

CLI

seed-cli blob get <cid>                 # fetch the raw signed blob
seed-cli blob verify <cid>              # check the signature of a stored blob
seed-cli document changes hm://…        # the change DAG with signers and times
seed-cli document cid hm://…            # the CIDs behind a version

SDK

Web API

Agents