Cite prior art

[msporny]

The specification needs to cite 30+ years of prior art around time stamping services, cryptographically signing a transaction log, blockchains and decentralized ledgers, WebLedger, Tahoe LAFS, IPFS, AtProto, KERI, and other technologies that provide something akin to what the Cryptographic Event Log specification defines. We probably need to have a section highlighting all the prior art in the space and what sets this specification apart. Readers of this specification are urged to provide citations to prior art that they feel apply. This issue exists to track the prior art in the space.

[bnewbold]

I think there are some strong similarities in DID PLC: https://web.plc.directory/

The data model (dual JSON/CBOR) seems very similar to IPLD, a set of specifications from the IPFS ecosystem, which atproto builds upon as well. There have been some efforts to re-frame a minimal subset of IPLD as "DASL".

• https://ipld.io/
• https://atproto.com/specs/data-model
• https://dasl.ing/

[msporny]

I think there are some strong similarities in DID PLC: https://web.plc.directory/

I got to the did:plc spec through the link above, we'll make sure to cite that too. I had read a separate write up of did:plc, and tried to capture most of the base features you need in the CEL spec. In an ideal world, we'd all converge, but there might be things that make it so we can't.

• https://ipld.io/

This we know about fairly well...

• https://atproto.com/specs/data-model

This I hadn't seen before, took a quick read through. Yes, there are a number of similarities there as well. We'll make sure to cite it as well.

• https://dasl.ing/

This was new to me... and done by Robin and Juan -- we know those extremely good looking and well mannered gentlemen well. /cc @darobin @bumblefudge -- I'll take a look at those specs, as we try to re-use a number of things from the IPFS community in the W3C CCG, VC WG, and DID WGs.

Thanks for the links @bnewbold! If there are particular features that you feel should be a MUST HAVE for the CEL spec, please do let us know. Ideally, you'd be able to use it at BlueSky, and there is interest from you, we'd need guidance from you on what we could do to converge.

[bumblefudge]

This kinda feels like a meta-spec or translation/convergence document so far, with how much of the state machine properties it leaves open to being decided on the "app level". Is it rude to compare this to the Sidetree pattern of a meta-method that just specifies the requirements and mental models for mutually-translatable did method specifications to be written within?

It's also worth mentioning if there's to be an exhaustive prior art section that there are a whole family tree of DID Methods that try to provide equivalent properties (specifically the"certificate-transparency"/microledger architecture) to KERI, without the "bare-metal"/greenfield/thoroughly-trustless approach. Among these I would mention in particular:

• ownyourdata.eu 's did:oyd, which has been extensively workshopped and iterated in the DIF I&D WG
• Dave Grantham (née Huseby)'s work on VLADs and Provenance Logs, which has some degree of cross-influence with the libp2p project and the multiformats low-level tooling world
• Dmitri Z and I briefly kicked around a draft we never finished for something kinda halfway between did:tdw and did:webplus; TLDR here. Other than the olive-branch of "JCS-or-Data-Integrity" for proof objects, Webhash might perhaps have been just a different "state machine" without being fundamentally a different data model, which is why i'm so interested in the idea of CEL as a convergence/metaspec rather than a competitor to all these opinionated state machines with a mostly-overlapping set of properties 😄

[darobin]

A couple quick notes:

• I can confirm that @bumblefudge and I are indeed hot; it's nice to see it recognised. You're not too bad-looking yourself, Manu.
• DASL is pretty new, so it shouldn't be a surprise that you haven't heard about it. It's designed to address the kitchen sink nature of IPFS CIDs & IPLD. It supports extensibility but without all the optionality, and it only brings in what people seem to use in real-world use. DASL CIDs have only one version, one multibase, two codecs (raw bytes and structured data), one hash function. The IPLD equivalent is basically dCBOR with tag 42 (CIDs) and that's it. No JSON, no COSMOS, no HAMT or other pluggable data layouts.
• I would say DASL's dCBOR42 is a pretty good choice here seeing as you get deterministic, verifiable payloads and the ability to link to other deterministic, verifiable payloads!

[msporny]

@darobin wrote:

I can confirm that @bumblefudge and I are indeed hot; it's nice to see it recognised. You're not too bad-looking yourself, Manu.

The crowd that has gathered, easily in the many single digits including numerous stray cats and dogs, nod in concurrence

Good, I'm glad we have consensus on at least that point.

[msporny]

@bumblefudge wrote:

i'm so interested in the idea of CEL as a convergence/metaspec rather than a competitor to all these opinionated state machines with a mostly-overlapping set of properties

Yes, I think that's what we are trying to achieve here -- standardize the cryptographic log mechanism / format and let the applications define the details of the state machine.

ownyourdata.eu 's did:oyd

Interesting, and yes, YACLF -- yet another DID + cryptographic log format

Dave Grantham (née Huseby)'s work on VLADs and Provenance Logs

Yep, same general idea, and leans in heavily to a VM/op based approach.

something kinda halfway between did:tdw and did:webplus; TLDR here.

Webhash might perhaps have been just a different "state machine" without being fundamentally a different data model

Yeah, exactly; we're testing that hypothesis with the CEL spec.

If you look across many of these DID Method / event log variations, the fundamental cryptographic log data structure seems to be common if you squint at it just right. Many of the solutions (sadly) combine the cryptographic log with the state machine processing and thus make the whole thing non-reusable. The CEL spec tries to separate the two into different layers where the lower layer is the cryptographic log and the upper layer is the application state machine. IOW, you can have a totally valid cryptographic log (verify all of it before processing the state machine, which might be costly).

We don't want to say the CEL spec is ONLY for DIDs, or ONLY for Social Web discussion threads. The proposition is that we can use the same base data format for at least both of those things. I will also note that the blind witnessing mechanisms is a critical feature, IMHO, because it establishes "truth" outside of just the controller of the data object that's being logged. It's optional, but critical for DIDs and Social Web, IMHO.

[msporny]

@darobin wrote:

DASL is pretty new, so it shouldn't be a surprise that you haven't heard about it.

I read all of the specs last night, which were great -- simple, concrete choices, no optionality, has extensibility, etc.

I would say DASL's dCBOR42 is a pretty good choice here seeing as you get deterministic, verifiable payloads and the ability to link to other deterministic, verifiable payloads!

Yes, the whole CBOR vs. JSON (or both!) thing has already come up among multiple communities. There are some that are like: "We don't want to use CBOR, none of our devs/community use it!", and others that are like "dCBOR is the only thing that makes sense for my constrained environment". So, we're already struggling w/ the notion that if we pick only CBOR or only JSON that we'll lose an important community we're trying to standardize this stuff for.

Like, you'll see JSON Lines being argued for strongly here: #3

... and, of course, there is almost inevitably going to be some future community that's like: JSON sucks for our use case, we need maximum compression/minimum memory/CPU load.

At present, we're toying around w/ the idea of applications being able to choose:

• log serialization format (e.g., JSON or CBOR)
• log entry canonicalization algorithm (e.g., none, JCS, or dCBOR42)
• securing mechanism (e.g., JWT, CWT, or DI)

We can make choices for each serialization, like: (JSON / JCS / DI) and (CBOR, dCBOR42, CWT)

... and, of course, if we make all that variable, then people will complain that we "didn't make choices", and if we make choices, we run the high risk of losing communities. All of which is just run of the mill "standards making" as we all know.

In any case, the people that show up, have opinions, and do implementations will guide where this spec goes... and if we're lucky, we'll retain most of the communities that are doing cryptographic logs and build a common implementation base for at least that part of the stack -- leaving the application-specific stuff to the applications.