Start here
Overview
DeDi Node is a self-hostable, open-source server for the Decentralized Directory protocol, with an append-only Merkle log underneath so anyone can check that what it serves was published and never rewritten.
What DeDi is
In the standard's own words, DeDi is "an open protocol for publishing public
directories — public key directories, revocation and sanctions lists,
membership rolls, professional and company registers — so that any party can
discover them and verify what they say." Data is organised as namespaces
(an organisation, usually a domain), registries (lists of records with a
schema) and records. The standard is maintained by LF Decentralized Trust:
decentralized-directory-protocol,
which this node is measured against at commit 52e120d.
It defines two things: a read API (lookup, query, versions) and a way to publish directories as signed files. It does not define how records get written, and it does not keep history tamper-evident. This node adds both.
What this node implements
The standard
- All 8 read endpoints of the DeDi API (API, conformance).
- Signed DeDi files and the
/.well-known/dedi.index.jsonmanifest (file publication). - A crawler that verifies and serves other publishers' files (crawler and mirror).
- The five reference registry schemas, built in (reference schemas).
Extensions
- A signed write plane. 13
/adminroutes; every write is Ed25519-signed by a publisher key scoped to one namespace; namespace, registry and record writes also carry a mandatory precondition so a replay or a race fails instead of overwriting (operator console). - A Merkle log. Every version is a leaf of an RFC 6962 tree; the node signs C2SP checkpoints, and any lookup can carry an inclusion proof. Consistency proofs show the log only ever grew (architecture).
- Witnessing. Any node can check another's log is append-only and publish the verdict (witnessing).
- Raft replication for availability (replication).
- Child-namespace delegation to a node someone else runs, witnessed by the parent (delegation).
- Webhooks: signed push when a record changes (push).
- DNS domain binding: prove a namespace's domain with a TXT record.
- Discovery: who serves a domain (discovery).
- CORD anchoring of checkpoints, optional (deployment modes).
- Pages: an overview at
/, a directory browser at/browse, the witness ring at/network, signing history at/status, record and proof checkers at/checkand/verify, the operator console at/admin, and these docs.
It is a Merkle log, not a blockchain. There is one writer per log, no consensus among strangers and no token. What stops an operator rewriting history is that the rewrite cannot be made consistent with a checkpoint someone else already holds, and witnesses are the someone else.
Five roles
One binary, configured by environment variables, plays any of these. A node can also witness another whatever its role.
| Role | What it is |
|---|---|
| standalone | a directory of its own: its own key, its own log. What a first node is. |
| mirror | serves what it crawled from other publishers; accepts no writes. |
| witness | checks another node's log is append-only and records verdicts. |
| replica | one member of a Raft set sharing one identity. Uptime, not trust. |
| child | holds one namespace delegated by a parent node, under its own key. |
Deployment modes explains how roles and trust levels combine; the console's Add a node tab renders the configuration for each.
Where to go next
- Run one: quickstart, then configuration.
- Use one: API.
- Understand why: why, architecture.
- See it used: a Beckn network, CREST.
- A public node to try: https://dedi.beckn.try-dough.com.
- The conformance suite, runnable against any DeDi server: theflywheel/dedi-conformance.