Dave Huseby
Dave Huseby
@msporny we went back and forth on this for a long time but we think we came to a well-reasoned conclusion. We decided that all of the files must be...
This is an interesting idea. I had assumed that the `` part would be the hash of the contributor's public key stored inside of the `.did` file. I'm worried that...
FYI, I updated the spec to say that the `` part is the Base58(SHA256(public key bytes)).
The reason I went that way is because the author string in commits will be the DID string for the contributor and I want that to include the key ID...
OK, so I can see the value of going either way, but now I'm going to change my mind : ) If the contributor DID document is named the encoded...
So now we have to revisit the procedure for bootstrapping the regime in a repo. If a contributor ID is the commit ID of when their DID document is added...
It is important to point out that the commit validation script/rules must be stored in the repo itself so that the provenance of the rules is also tracked and defended...
@twshelton I am almost certain that git commit hooks can do this. But since this operation is supposed to go through `git did update ` we own the context completely....
@twshelton as I was catching up on the discussion this morning I started to rethink the on-disk organization of the files. Instead of trying to hide everything in a `.did/`...
Thanks! This is very helpful. I've already seen some tricks in your code that we may borrow. We won't be lifting any code though. I'm already implementing the new signing...