FAQ

An append-only sequence of Ed25519-signed, hash-chained entries published by one issuer, such that a subscriber walking a contiguous run from an anchor it holds can establish it received the complete, untampered sequence.

Structurally they are close. SSB gives each identity a signed hash-chained append-only feed, which is the same core construction.

SSB is also a complete social protocol: an identity model, a replication strategy, a gossip network, pub infrastructure. Adopting the feed means adopting the protocol. This specification covers the wire format and the subscriber's verification, with no transport, replication or network attached, so an agent can publish verifiable announcements without joining anything.

CT established log completeness first [RFC 6962, revised as RFC 9162], and is the direct model for the equivocation construction here. The difference is cost of entry against what it returns. CT assumes an operated transparency log — Merkle tree, monitors, auditors — and returns O(log n) inclusion and consistency proofs.

This assumes appending signed entries to a linear chain and returns completeness by walking it. At the scale of a certificate log that trade is wrong and CT remains the correct construction. At the scale of an announcement feed it is not.

It is a decided non-goal, not a deferred feature. In a strictly linear chain (seq, entry_hash) fully locates a position in the history, and each entry's hash folds in its predecessor's by induction, so one hash commits to everything before it. That covers compaction and fork detection, the two functions a tree would otherwise serve.

The cost: establishing that a single historic entry is in the feed requires walking to it, at O(n) against O(log n) for a Merkle log. In exchange there is no tree to build, store, serve or get wrong.

No. The payload is opaque and self-asserted: the issuer signs what it puts there, and the feed layer neither inspects nor validates it beyond requiring a string type. A verified entry establishes that the issuer said it, in this order, completely. Whether it is correct belongs to the consuming payload profile, and often to a different primitive.

No. Completeness is a property of the run between two anchors, not of currency. An issuer can serve one subscriber a chain-correct view frozen months ago while serving everyone else the latest. It has not tampered, has not rewound and has not forked: every head it signed is internally consistent, and fork detection compares heads at the same position.

The current draft does not detect this. It is recorded as undefended, and the intended remedy is witness co-signing, which is unspecified.

Not silently. A short page is legal — that is how a publisher serves a long backlog in chunks — but the signed head it carries runs ahead of the last entry, so the subscriber sees its cursor has not reached the head and re-requests. A truncated tail looks like entries that have not arrived yet, not like entries that do not exist.

A server truncating every response is withholding, per the previous answer. Entries dropped between two the subscriber holds break the chain outright.

Yes, two ways. Pin a signed head you trust and walk forward from it, or adopt a state checkpoint the issuer published as a local genesis. Both inherit the issuer's word for everything at or before that point, and establish completeness only after it. Neither retroactively demonstrates that nothing was omitted before arrival.

Two validly signed heads at the same seq with different tips are the issuer's own contradictory statements, and together form a non-repudiable proof of equivocation, re-checkable by anyone from those signatures alone. The gossip transport that brings a peer's head to you is unspecified, so the proof exists today only once two conflicting heads meet.

Not transparently. did:key binds a feed to one keypair — the feed identifier is the public key. A non-normative convention is reserved: before retiring a key, the issuer appends an ordinary entry, signed by the old key, endorsing its successor. Subscribers MAY honour it. No verifier behaviour depends on it, and a compromised old key can endorse an attacker's successor, which is the key-custody boundary restated.

No. A frozen view of an availability signal is indistinguishable from a live one that has not changed, and an agent that has gone offline stops publishing, which resembles an issuer withholding. Liveness requires a channel in which silence is evidence, such as a heartbeat with a deadline. Capabilities belong here; availability belongs in something that fails closed.

The wire format and its verification are published in full on this site, which is the specification of record — Wire Format & Verification. It is a working draft: reviewable, not yet frozen. A second implementation is what it is written for, and the conformance corpus is what one replays to demonstrate interoperability.