Re: did:cel - a cryptographic event log-based DID Method

Hi Manu,

Quick follow-up on the technical details:

On Traversal (Map vs. Territory):
You don't need to "jump from log to log" (HTTP hops).
Glogos uses Content-Addressable Storage (CAS). The DAG is a map of hashes.

* Bounded Verification: A verifier only fetches the attestations in the
"direct causal history" of the DID they care about (Pruning).
* Efficiency: You can fetch that entire pruned branch from a single peer
(or a local cache) in one go. You aren't traversing the web; you're
traversing a directed graph structure that can live in one flat file.

On Attack Surface:
The attack surface is bounded by the "Verifier's Interest Graph".
If I only care about DID:A, I only fetch the history of DID:A (and its
parents). I never touch the millions of other attestations in the "mesh"
unless they are direct ancestors.

Concrete Example (The wrapper you asked for):
Here is how a did:cel event becomes a Glogos attestation.

// 1. The Payload (did:cel event) - The "Letter"
{
  "operation": {
    "type": "update",
    "data": { "authentication": [...] }
  },
  "proof": { ... }
}
// (This payload is hashed -> "hash(payload)")

// 2. The Wrapper (Glogos Attestation) - The "Envelope"
{
  "zone": "hash(controller_pubkey)",                       // Who: The DID
Controller
  "subject": "hash(payload)",                                   // What:
The CEL Event
  "canon": "hash('opt:did:cel:1.0')",                          // How:
Interpret subject as CEL
  "time": 1767225600,                                             // When:
Timestamp
  "refs": ["hash(parent_1)", "hash(parent_2)"],        // Context: Causal
Ordering (DAG Merge)
  "proof": "ed25519_signature"                                //
Authenticity: Controller's Sig
}

Result:
1. Ordering: "refs" proves Event 1 happened before Event 2.
2. Witnessing: If "hash(parent_1)" or "hash(parent_2)" is widely
distributed (e.g., in a public archive, bridged to Bitcoin, or even printed
in a newspaper), Event 1 is pinned in history.
3. No Heartbeat: Verifier checks "proof" + "refs" chain. No need to query a
"liveness server".

Glogos is the envelope. CEL is the letter.
Glogos handles the "physics" (Time/Space). CEL handles the "semantics" (DID
Operations).

Does this distinction (Envelope vs Letter) make sense for the architecture
you envision?

Best regards,
Manh Thanh Le

On Sun, Jan 4, 2026 at 10:32 PM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> On Sat, Jan 3, 2026 at 2:02 PM Manh Thanh Le <vnlemanhthanh@gmail.com>
> wrote:
> > No Central Log: In Glogos, there is no single "big file" to download.
> Instead, the DAG itself is the log. When a zone creates an attestation, it
> references (refs) previous IDs. This builds a Causal History that is
> globally traversable.
>
> How is it traversed? What I'm hoping to hear is: You just download
> some log from somewhere. What would create a problem is: You jump from
> log to log until you get back to the GLR. I am clearly missing a huge
> part of how you reconstruct the graph back to the GLR and I'll have to
> read about it in depth to get up to speed.
>
> > Addressing Forking/Heartbeat: Because every attestation traces back to
> GLR, any attempt to "fork" a DID history becomes globally visible. The DAG
> provides implicit witnessing: if I reference your attestation, I am
> effectively "timestamping" your past with my present.
>
> Yes, but how does a verifier get to that reference from a did:cel log?
> It sounds like they'd have to know of at least two logs (and possibly
> an unbounded set of N logs) -- the did:cel log /and/ whatever other
> log references an event in the did:cel log... and if the system is
> truly decentralized, we're back to a discoverability problem and a
> larger attack surface, right?
>
> So, we'd be trading off heartbeat bloat (bounded attack surface) in
> the did:cel log for network-based graph traversal (unbounded attack
> surface). We could mitigate the unbounded nature of the Glogos graph
> traversal by fixing the number of external graphs that could be
> fetched to one, which would mean you'd effectively store the
> heartbeats in the external log and you could make that more efficient
> via Merkle tree of some kind, at which point we're effectively back to
> a blockchain (with all the extra complexity entailed). :)
>
> I think the trade-off that did:cel is making here is implementation
> simplicity and attack surface reduction. As a verifier, you need to
> set the witnesses you trust and then you read the log. There are no
> other external resources you care about or need to go off and fetch.
> The cost paid for that is a larger log file due to the heartbeats. You
> could mitigate that by moving the heartbeats to a globally shared
> Merkle tree of some kind (aka blockchain), but you'd need to
> effectively download that huge thing to validate the history of a
> single DID and that could be a waste at scale if all you want to do is
> just interact with the DIDs that are used to authenticate with your
> system.
>
> I probably have all of this all wrong wrt. Glogos and need to spend
> some time carefully understanding how did:cel would use the Glogos log
> format.
>
> > Infrastructure-free: Unlike a blockchain, Glogos doesn't need miners or
> consensus. It only needs the mathematical invariant that "B cannot exist
> before A if B references A".
>
> Yes, sure, but we need more than that for did:cel -- we need
> heartbeats of some kind and we need to store those heartbeats
> somewhere. To put it another way, and IIUC, if we use Glogos and the
> history is an "optimized and tightly weaved mesh", then we can share
> heartbeats among the network. However, if we do that, we end up
> needing to download the entire mesh with gives us information that we
> do not need for the task at hand.
>
> This is an optimization problem with a tipping point where it does not
> make sense to use Glogos on one side of the tipping point, and where
> it makes sense to use Glogos on the other side of the tipping point. I
> don't have enough data to understand where that tipping point would
> be.
>
> > I’d love to show you how a CEL entry can be wrapped in a Glogos
> attestation to inherit this "Universal Root" without adding any blockchain
> weight.
>
> Yes, please, an example from you at this point would be very welcome
> so I can at least understand the fundamentals of Glogos.
>
> -- manu
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> https://www.digitalbazaar.com/
>