Support, Co-editing Interest, and Suggestions for the did:cel Specification

I am writing to you following my review of the "The did:cel Method v0.3"
draft specification published on 07 December 2025. I wish to express my
strong support for the direction of this work.

As someone involved with the Sirraya DID method, which shares the
foundational philosophy of moving beyond heavy blockchain dependencies for
decentralized identity, I find the witness-based architecture of did:cel to
be a compelling and necessary evolution. Your focus on minimal
infrastructure, near-zero cost, and censorship resistance directly
addresses critical barriers to global adoption that blockchain-based
methods inevitably face.

I believe this approach represents a more scalable and pragmatic path
forward for mainstream decentralized identity. The concept of "oblivious
witnessing" is particularly elegant for balancing verifiability with
privacy.

I am keen to contribute more directly to this effort and would like to
formally express my interest in joining as a co-editor of the
specification. My experience with Sirraya has given me deep practical
insights into the challenges and solutions in this space, which I believe
would be valuable for the did:cel project.

Furthermore, I have some technical reflections and suggestions that I think
could strengthen the resilience and security model of the method:

   1.

   DAG-based Structure for Enhanced Robustness: The current linear
   hash-linked CEL provides strong integrity. However, I propose exploring a
   shift to a Directed Acyclic Graph (DAG) structure for the event log.
   This could introduce a form of self-authentication and tamper
detection where
   multiple subsequent events can reference prior events. A fork or tampering
   attempt would be immediately apparent as a "conflict" within the DAG, and a
   predefined consensus rule (e.g., based on witness weight or topological
   ordering) could allow the network to converge on the canonical history
   autonomously, without relying solely on storage service policies.
   2.

   Adding Constraints for a More Robust Witness Model: To further mitigate
   risks from witness collusion or coercion (as noted in Sec 6.1), we could
   introduce formal constraints:
   -

      Temporal Diversity Requirement: A policy that witness proofs for an
      event must come from services in operationally distinct time zones or
      regulatory jurisdictions.
      -

      Proof-of-Freshness Challenge: Verifiers could issue a challenge nonce
      that must be incorporated into the event hash witnessed,
preventing replay
      of old witness attestations.
      -

      Witness Set Commitments: The DID document could include a committed
      Merkle root of its active witness set. Changing witnesses would require a
      witnessed event, making sudden, suspicious changes to the trust model
      transparent and auditable.

I am very enthusiastic about the potential of did:cel and am convinced that
a collaborative effort to integrate these kinds of graph-based and
constraint-driven mechanisms could make it exceptionally robust. I would be
happy to discuss these ideas further, elaborate on their technical
implementation, or draft text for the specification.

Thank you for your pioneering work on this. I look forward to the
possibility of collaborating.

Best regards,

Amir Hameed

Founder, Sirraya Labs