Possible citation for DIF/Sidetree?

[csuwildcat]

Hey folks, I noticed the way DIDs are generated/represented via use of the unique output of the initial DID Document and how delta-based CRDT op convergence was approached seem to be inspired by the way Sidetree does these things (a GH Issue in the Peer DID work even references Sidetree for the former). Do you think it would be OK to get a citation in the spec? Not a huge deal, just a nice-to-have if you all are amenable to it.

[kdenhartog]

I'm in favor of citing the sidetree work. I suspect given the overlap of the community working on this there's a few points we could cite given the similarities in work. @dhh1128 what's your thoughts on adding citations in?

[dhh1128]

You bet. Glad to have citations. @csuwildcat, please raise a PR with one or more citations, and we'll gladly include them. (@kdenhartog, I'm still counting on you to raise a PR or two, also, so I can get you on the author list... :-)

BTW, @csuwildcat , if you'd like to be listed as an author, let me know. I'm including people who've read the spec and provided substantive feedback and/or PRs.

[dhh1128]

One place to add a reference would be in this paragraph:

In many ways, peer DIDs are to public, blockchain-based DIDs what Ethereum Plasma or state channels are to on-chain smart contracts— or what Bitcoin's Lightning Network is to on-chain cryptopayments. They move the bulk of interactions off-chain, but offer options to connect back to a chain-based ecosystem as needed.

Please submit a PR...

[dhh1128]

@csuwildcat : I still prefer to have you submit a PR and making you an author. What do you think about that?

If you don't want to submit a PR, do you mind if I write up one, credit you as the author with me only as submitter, and run it past you for approval before merging?

[csuwildcat]

Thank you for the offer of an authorship co-credit. Let me look into this at work, because I've never been added to a spec in this way while an employee of MSFT (it was pretty trivial at Mozilla, but I just don't know if there's a different process at MSFT).

[coder5876]

@dhh1128 @csuwildcat I'm very interested in diving deeper into the similarities of the peer DID spec and the sidetree spec on the topic of deltas. It seems to me that a sidetree-based DID method is simply the peer DID method but with the deltas stored in the sidetree data structure. It would be really cool if the sidetree spec was completely compatible with the peer DID spec in this way. Do any of you see any reason why this wouldn't be possible?

[dhh1128]

I agree that this is an intriguing possibility that we need to investigate. I give us maybe 50% chance of pulling it off. I'm not sure that the surface-level similarities remain when you go deeper. But let's see.

[coder5876]

@dhh1128 One pretty significant difference is that the deltas/operations in sidetree are totally ordered with ordering determined by a blockchain, with operations containing hashlinks to previous operations.

The deltas/operations in the peer DID method are not ordered and do not have hashlinks to previous operations.

It might make sense to add at least a partial ordering/graph structure to the peer DID operations. This means that a peer DID delta/operation would contain hashlinks to one or more deltas. If you have links to more than one delta it signifies that we are merging two different DID document updates. This would make the structure of peer DID deltas similar to a Git repository with branches & merges etc.

[dhh1128]

The practical difficulty with that idea is: on what basis would you impose ordering? A consensus algorithm? I don't want to give up the decentralized nature of the method or its core algorithm...

[coder5876]

@dhh1128 I'm proposing a partial ordering instead of a total ordering. When doing an update you would always start from a particular state which you can refer back to with a hashlink.

For instance a git repository is partially ordered in that each commit refers back to previous commits, but you can have two commits at the same level referring back to the same previous commit. Thus these two commits cannot be compared, hence it's a partial ordering rather than a total ordering. For a partial ordering you don't need a consensus algorithm, but for a total ordering you normally do.

I'm also not clear on how much of the above you actually get for free when you are using CRDTs as the underlying data types? Do you have more info on the actual data structures that would be used here, in terms of what's being implemented right now?

Since the sidetree method has a total ordering (utilizing a blockchain consensus algo) it's possible that it could be expressed as a special case of the partial ordering of the peer DID method.

[dhh1128]

Okay, that sounds workable. I think the CRDT mechanism as currently described in the spec would give us enough to achieve a partial ordering. Would we get any new features by representing the deltas as a graph instead of a simple array, other than becoming more similar to Sidetree?

[dhh1128]

Update: I think the question of a graph instead of a simple array is also raised by work being done in IETF on the Braid Protocol. See https://tools.ietf.org/html/draft-toomim-braid-00 -- in particular, section 4.4.1.

[dhh1128]

Closing now that the ticket has moved to its new repo home at decentralized-identity/peer-did-method-spec#14.