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

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/

Received on Sunday, 4 January 2026 15:32:48 UTC