docs / walkthrough · updated 2026-08-01
Discovery and trust
BlobArchive discovery is a chain of separately authenticated statements:
DNS TXT
_dnslink.<name> = dnslink=/ipns/<ipns-name>
|
v
signed IPNS record -> /ipfs/<publication-document-cid>
|
v
exact publication bytes
|
v
Ed25519 document signature + local durable floors
No single layer is asked to prove everything.
For a plain-language explanation of the network components beneath this trust chain, start with how BlobArchive uses IPFS.
Publishing does not require permission
There is no writer registry in the protocol. Any operator can:
- run a writer and derive heads from Ethereum;
- sign a publication document and IPNS record, then relay both through a read-only public edge;
- set DNSLink under a domain it controls; and
- distribute a follow profile naming that DNSLink and signer.
A follower operator authorizes that writer by deliberately selecting the
profile. The writer does not need a blobarchive.net record or inclusion in
the built-in catalog.
The project-controlled namespace and shipped profiles are curated defaults. Adding a writer there is human-reviewed because it associates the project with that exact identity and policy. It does not make the writer more valid at the protocol layer, and omission does not make an independently published writer less functional. An L2 without a project-hosted default can publish and follow its own writer immediately.
DNSLink chooses an IPNS authority
DNSLink is one TXT lookup. Its value names an IPNS key; it does not point directly at an archive root or a server.
The record’s TTL is a cache lifetime, not an expiry. Deleting or revoking the credential that edited the record does not delete the record. DNS authority is therefore production trust infrastructure and must have an explicit rotation and removal procedure.
The default resolver does not itself authenticate DNSSEC. The shipped profiles limit the consequence by independently pinning the publication signer.
IPNS authenticates an exact document CID
The IPNS record is signed by its own key and sequence-numbered. It points to the CID of the exact publication document bytes. A higher IPNS sequence is a newer transport statement, not permission to regress the archive claim inside it.
The private writer constructs and signs both the publication document and its IPNS record. A separate public edge verifies their signer, network, archive, head policy, sequence, revision, document CID, and advertised edge identity. It then provides the exact document CID before putting the signed IPNS record into the DHT. The edge has no publication signing key and read-only access to immutable archive blocks, so compromising it cannot mint a replacement claim or mutate the archive.
The writer operator periodically sends unchanged signed state through that edge to refresh validity and can send a new revision immediately after a head update. Provider records and IPNS records have finite lifetimes, so a sleeping writer or edge can disappear from discovery while the durable archive remains intact.
The publication document identifies the archive state
One signed document describes the archive’s network, logical archive ID, revision, public-edge libp2p addresses, and every physical head. A head entry includes its root and coverage. Filtered finalized heads may also carry the CID of their append-only source manifest.
The document is signed with Ed25519 over canonical JSON. The signature authenticates that writer operator’s statement. It does not make an omitted blob appear or establish that the writer operator’s source schedule was complete.
Writer acquisition remains a trust boundary
A writer must first obtain complete blob bytes. Post-Fusaka, a healthy ordinary consensus node may custody too few data columns to reconstruct them, and a node configured for future retention may still lack history it never acquired. A writer operator therefore measures its actual serving frontier and anchors every accepted blob against Ethereum’s commitments instead of trusting an HTTP status or an “archive” label.
This is also a common-mode boundary between writers. Two independently signed heads do not provide independent completeness evidence if both writers copy the same first writer or depend on the same incomplete upstream. A meaningful cross-check re-derives the head from Ethereum inputs and independently verifies the acquisition path. Exact roots at equal coverage are then strong evidence of agreement; they are not a substitute for that independence.
Decentralization does not remove trust
Running more followers and replicas distributes storage, serving capacity, and failure domains. Any connected peer holding a requested CID can supply the same authenticated bytes, and an L2 operator can keep its primary blob endpoint local instead of depending on one hosted service.
That is availability decentralization. It does not independently check the writer’s decision about what belongs in a filtered head. One hundred replicas of one writer still inherit that writer’s source schedule and acquisition assumptions.
Completeness assurance becomes more decentralized only when another writer independently derives the head from Ethereum inputs, uses an independently verified acquisition path, and publishes under its own signer. Equal roots at equal coverage then corroborate the result; disagreement becomes visible instead of being copied through the replica fleet.
Trust has not vanished. It has become explicit, scoped, replaceable, and locally enforced:
- a writer is trusted only for claims under its own signer;
- a follower operator chooses which writer authorities to accept;
- a DHT peer can supply bytes without gaining publication authority;
blobarchive.netand built-in profiles are curated recommendations, not network membership; and- another operator can publish and distribute a competing profile without project approval.
The shipped default pins the signer
Follow profiles support two trust modes:
dnslink-delegatedlets the DNSLink/IPNS path authorize signer rotation. Control of the DNS zone is enough to move followers to a new publication signer.dnslink+signer-pinalso pins the 32-byte Ed25519 public key. A DNS or IPNS compromise can cause unavailability or replay attempts, but it cannot authorize a different signer.
Production profiles ship in dnslink+signer-pin mode. The initial signer
fingerprint is:
6698f6c8767529ffb725ce5201a86602106cc87ed7c9129a649428ca0ea6d7b5
Signer changes therefore require a new reviewed and versioned follow profile. Changing DNS alone is insufficient.
Durable floors make rollback local
A follower/replica operator’s node persists the facts it has already accepted. Among them are:
- IPNS sequence;
- publication revision and same-revision digest;
- signer and logical archive identity;
- finalized root and coverage;
- manifest ancestry;
- mutable-generation proof; and
- selected follow-profile name, version, and digest.
A valid old document is still old. Restarting the process, restoring DNS, or changing transport does not lower these floors. An equal revision with different bytes is equivocation; an unexpected signer, manifest predecessor, coverage regression, or incompatible root is refused rather than hidden.
updated_at is diagnostic for revisioned publications. It changes after a
successful poll even when a followed head does not move, so whole-response byte
identity is not a valid continuity test across a successful poll.
Discovery is not availability
A DHT provider result, relay reservation, DNS response, or signed IPNS record can locate a peer without proving a usable data path. Every fetched byte still has to pass the content, signature, replay, and coverage checks.
The field tests observed exactly this boundary: cellular observers repeatedly resolved signed records while direct archive transfer remained unavailable. The follower/replica operator should monitor and report discovery separately from reachability and fetch success.
For the exact wire rules, read specification §8 and the versioned follow-profile contract.