Re: [PROPOSED WORK ITEM] CEL DID Method (did:cel)

Indeed -- thanks Melvin for putting this together.  Interesting stuff.

There one key misunderstanding of did:webvh in the table (and in Manu's
response to my email) that I'd like to address.

The root of trust in did:webvh is the DID Log -- it is not DNS. The
verifiability comes from the DID (with its SCID) and the cryptographically
linked entries in the DID Log. A did:webvh DID's *discoverability* comes
from DNS -- where the log can be found.  However, a did:webvh log can be
found from other sources (watchers -- official or not, passed from peers,
caches, etc.) and the verifiability can be checked. That the (significant)
difference between did:web and did:webvh. I would also argue that something
like did:cel also needs to be published somewhere, and resolvers need to
find out where that is. Perhaps they will be stored at HTTP URLs...

Two other quick notes about the table:

   - Neither did:webvh nor did:web need domain control access. DIDs of
   either method can be stored at any HTTP addressable location -- GitHub, any
   platform that allows a filename in the URL.  They can be published for a
   domain, but do not require domain control.
   - I would argue that the did:webvh spec is stable, and with the benefit
   of useful versioning mechanism to allow evolution.

Hope that helps.

On Sun, Jan 4, 2026 at 7:46 AM Amir Hameed <amsaalegal@gmail.com> wrote:

> Yes it does , and more importantly it will solve some of the worst
> problems we face , it will enable scalability with no mining needed,
> verification and storage together , dependency and causality, the DAG
> structure is very robust and versatile. I am waiting for the discussion to
> settle down post which I will be sharing a detailed document here and the
> full architecture blueprint which would help us to reverse that into a
> specification, and the best part is the more users join the stronger the
> network gets and it becomes self sustainable by users it’s and no external
> miners are needed, the users of the method and network will maintain the
> whole network by just participating and supporting it with their own node
> compute, it would be like to if I want to use the network before my
> verification gets confirmed I must verify two previous unverified logs
> taken from a common pool of logs
>
>
>
> On Sun, 4 Jan 2026 at 9:06 PM, Melvin Carvalho <melvincarvalho@gmail.com>
> wrote:
>
>>
>>
>> ne 4. 1. 2026 v 15:39 odesílatel Amir Hameed <amsaalegal@gmail.com>
>> napsal:
>>
>>> Hi Melvin
>>>
>>> Thank you for coming up with this first draft I think it’s a good start
>>> and we can host it under version control as you deem appropriate and then
>>> include that to the main work item, I am in full support of it as this is
>>> going to be very helpful
>>>
>>> Hi Manh
>>>
>>> I would answer the DAG part based on my technical insight , DAG here
>>> would be useful if we can implement a mechanism like IOTA does for M2M
>>> transactions, necessitating the users of the network to first verify two
>>> prior logs and then only their log can be verified considering the security
>>> scenario
>>>
>>
>> Thanks Amir, the DAG discussion is fascinating. I've used linear logs
>> (simpler to implement), but DAG seems better suited for multi-stakeholder
>> scenarios where parallel updates are needed. Systems like RGB use DAG
>> structures, and have gained popularity. Does that match your thinking?
>>
>>
>>>
>>> Regards
>>>
>>>
>>> On Sun, 4 Jan 2026 at 7:59 PM, Manh Thanh Le <vnlemanhthanh@gmail.com>
>>> wrote:
>>>
>>>> Hi Melvin,
>>>>
>>>> Thank you for the comparison framework — this is exactly
>>>> what the discussion needs.
>>>>
>>>> On Question #1 (DAG vs Heartbeat):
>>>> Yes. A refs-based DAG provides cryptographic temporal proof
>>>> without requiring periodic entries. Each reference is itself
>>>> a witness.
>>>>
>>>> On universal anchoring (potential addition to comparison):
>>>> Any hash-based method could anchor to SHA-256("") — a
>>>> mathematical constant derivable by anyone. No central log
>>>> required: the DAG structure itself is the log.
>>>>
>>>> Possible table row:
>>>> | Method     | Can Anchor to GLR? | Notes
>>>>         |
>>>> | did:key      | N/A                            | Ephemeral
>>>>                   |
>>>> | did:cel       | Yes                            | Could reduce
>>>> heartbeat need |
>>>> | did:webvh | Yes                            | Via refs extension
>>>>              |
>>>>
>>>>
>>>> Best regards,
>>>> Manh Thanh Le
>>>> ---
>>>> Related exploration:
>>>> github.com/glogos-org/glogos/blob/main/GENESIS.md#appendix-z-cross-network-interoperability
>>>>
>>>> On Sun, Jan 4, 2026 at 3:51 PM Melvin Carvalho <
>>>> melvincarvalho@gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> ne 4. 1. 2026 v 7:58 odesílatel Amir Hameed <amsaalegal@gmail.com>
>>>>> napsal:
>>>>>
>>>>>> Hey All, it’s very hard to follow the whole thread and especially the
>>>>>> priors methods which I am sure must be taken into account before we go into
>>>>>> full discussion, I would suggest if we can create a tabular data document
>>>>>> where all existing methods their strengths, weakness and infrastructure can
>>>>>> be compared so that once we move ahead with CEL we have the whole context
>>>>>> of how DID evolved since its inception. That would help us have better
>>>>>> clarity.
>>>>>>
>>>>>> Regards
>>>>>> Amir Hameed
>>>>>>
>>>>>
>>>>> Hi Amir, all,
>>>>>
>>>>> I agree with Amir’s suggestion that a comparative document would be
>>>>> very helpful. Having followed DID method evolution since the early
>>>>> blockchain-based approaches, I think a structured comparison could give the
>>>>> group shared context and reduce repeated re-litigation as we discuss
>>>>> did:cel.
>>>>>
>>>>> Below is a *draft comparison framework*, intended as a starting
>>>>> point. Corrections and additions are very welcome.
>>>>> ------------------------------
>>>>> DID Methods – Draft Comparison Infrastructure & Cost
>>>>> Method Infrastructure Required Estimated Cost DNS Dependency
>>>>> did:key None Zero No
>>>>> did:web Domain + HTTPS server ~$10–50/year Yes
>>>>> did:webvh Domain + HTTPS + version log ~$10–50/year Yes
>>>>> did:cel File storage + 3+ witnesses Near-zero No
>>>>> did:nostr Public Nostr relays Near-zero Optional
>>>>> did:ion Bitcoin node + IPFS (or provider) Variable (BTC fees) No
>>>>> did:indy Permissioned ledger membership Network-dependent No
>>>>> Security Properties
>>>>> Method Key Rotation History Verifiable Censorship Resistance Fork
>>>>> Protection
>>>>> did:key No (new DID required) N/A N/A N/A
>>>>> did:web Manual replacement No Low None
>>>>> did:webvh Yes (logged) Yes Medium Pre-rotation
>>>>> did:cel Yes Yes High Heartbeats
>>>>> did:nostr Via events Via relays High Relay consensus
>>>>> did:ion Yes (Sidetree) Yes (blockchain) High Bitcoin finality
>>>>> did:indy Yes Yes (ledger) Medium Ledger consensus
>>>>> Privacy Considerations
>>>>> Method Resolution Tracking Witness Visibility Correlation Risk
>>>>> did:key None N/A High
>>>>> did:web Server logs N/A High
>>>>> did:webvh Server logs Witnesses see content Medium–High
>>>>> did:cel Storage logs Oblivious (hash only) Medium
>>>>> did:nostr Relay logs Relays see events Medium
>>>>> did:ion IPFS / node logs N/A Medium
>>>>> did:indy Ledger queries logged N/A Low (ZKP)
>>>>> Operational Characteristics
>>>>> Method Offline Create Offline Resolve Implementation Complexity Spec
>>>>> Maturity
>>>>> did:key Yes Yes Very low Stable
>>>>> did:web No No Low Stable
>>>>> did:webvh No No Medium Draft
>>>>> did:cel Yes No (cacheable) Medium Draft
>>>>> did:nostr Yes (basic) Yes (basic) Low–Medium Draft
>>>>> did:ion No No High Stable
>>>>> did:indy No No High Stable
>>>>> ------------------------------
>>>>> Key Trade-offs (Brief)
>>>>>
>>>>>    -
>>>>>
>>>>>    *DNS vs non-DNS:* did:web and did:webvh leverage DNS trust but
>>>>>    inherit its failure modes; did:cel and did:nostr avoid DNS entirely but
>>>>>    raise discovery and UX questions.
>>>>>    -
>>>>>
>>>>>    *Optionality:* did:webvh supports many optional features,
>>>>>    increasing flexibility but also the security analysis surface; did:cel aims
>>>>>    to reduce optionality to simplify guarantees.
>>>>>    -
>>>>>
>>>>>    *Witness models:* visible witnesses vs oblivious witnesses vs
>>>>>    blockchains present different privacy and trust trade-offs.
>>>>>    -
>>>>>
>>>>>    *History guarantees:* both did:webvh and did:cel provide
>>>>>    verifiable history, but via different mechanisms and threat assumptions.
>>>>>
>>>>> ------------------------------
>>>>> Questions for the Group
>>>>>
>>>>>    1.
>>>>>
>>>>>    Would a DAG structure materially improve fork detection over
>>>>>    linear history plus heartbeats?
>>>>>    2.
>>>>>
>>>>>    What long-term incentive models make sense for witnesses?
>>>>>    3.
>>>>>
>>>>>    How should migration from did:web to did:webvh or did:cel be
>>>>>    handled?
>>>>>    4.
>>>>>
>>>>>    Should the CCG define a shared DID-method comparison and test
>>>>>    suite?
>>>>>    5.
>>>>>
>>>>>    Given overlapping goals, should did:nostr be compared more
>>>>>    formally alongside did:cel?
>>>>>
>>>>> ------------------------------
>>>>> Suggested Next Steps
>>>>>
>>>>>    -
>>>>>
>>>>>    Create a living comparison document (HackMD or GitHub).
>>>>>    -
>>>>>
>>>>>    Invite method authors to review and correct entries.
>>>>>    -
>>>>>
>>>>>    Add implementation status, deployments, and failure-mode analysis.
>>>>>
>>>>> I’m happy to help maintain or contribute to such a document if there’s
>>>>> interest.
>>>>>
>>>>> Best regards,
>>>>> *Melvin*
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> On Sun, 4 Jan 2026 at 12:05 AM, Manu Sporny <
>>>>>> msporny@digitalbazaar.com> wrote:
>>>>>>
>>>>>>> Hey folks,
>>>>>>>
>>>>>>> Given the discussion over the past several weeks around did:cel,
>>>>>>> here's the work item adoption tracker issue:
>>>>>>>
>>>>>>> https://github.com/w3c-ccg/community/issues/255
>>>>>>>
>>>>>>> Please provide additional support in that issue if you haven't
>>>>>>> already
>>>>>>> done so via the mailing list.
>>>>>>>
>>>>>>> Thanks to everyone that has commented with suggestions on how we can
>>>>>>> potentially further align work happening in this area. I'll try to
>>>>>>> follow up on some of the comments that came in over the holidays to
>>>>>>> provide some more thoughts on alignment.
>>>>>>>
>>>>>>> -- manu
>>>>>>>
>>>>>>> --
>>>>>>> Manu Sporny - https://www.linkedin.com/in/manusporny/
>>>>>>> Founder/CEO - Digital Bazaar, Inc.
>>>>>>> https://www.digitalbazaar.com/
>>>>>>>
>>>>>>>

-- 

Stephen Curran
Principal, Cloud Compass Computing, Inc.