Add prev CID link check to Log::verify()

[dhuseby]

Fixes #4. Good catch @DougAnderson444.

Signed-off-by: Dave Grantham dwh@linuxprogrammer.org

[DougAnderson444]

@dhuseby I think this will work.

Casual Aside: I have to keep reminding myself that this Verify process is all based on the proofs, and that the actual entry bytes aren't even required to verify (which is where my head was originally when I raised this issue). Which is pretty cool if you think about it -- you could have lost the chain of entry bytes, but the system is robust enough to work if you still have the plog.

So, we don't actually need to hash the entry to check that against the CID -- that's already baked into the proof field, right?

If these assumption are spot on, then I think what you've done here -- checking prev against current -- makes sense.

A long while ago I put the comrade version into the rhai branch on this repo, which is what I'm using in my branches. I will make similar changes on the rhai branch and update the other code to ensure it doesn't break anything...

[DougAnderson444]

@dhuseby looks like you just have to update the multikey dep from commit

66eb9259cd6710a570a8d3935021440ea3b18720

to the latest

50830f4f49d5fe6fa5f301f25013307f915fe2a9

(update and commit lockfile)

[DougAnderson444]

Actually, maybe a different approach the the deps would be better. It's a bit of a nightmare right now, especially when I want to push any changes.

For example, deriving the additional Hash bound in multihash has a ripple effect across several repos (five 🖐️‼️), and I need to fork, branch, update until the change is merged, then do it again to reverse it.

I am thinking these deps should just be re-exported, that way when the upstream dep is changed, it trickles down to all the other dependencies without the pasta (both copy and spaghetti kinds).

Because right now it's becoming a nightmare to make even a small change and still use the multi-tude of multi-repos.

[DougAnderson444]

OR... make it a cargo workspace with all the multi- codebases in one repo?
OR... merge these upstream (I'm looking at you, multicid. You already have cid crate, could this not be pushed upstream?)

[DougAnderson444]

After further review, this is what I think would work best:

Combine multi-

• base
• codec
• trait
• util

into a workspace with multisig and multihash.

The workspace can re-export all 6 of these deps, that way any library relying on these is synced.

[DougAnderson444]

I'm swtiching to this workspace clone https://github.com/DougAnderson444/multicrates for the meantime for ease of development (and for great justice).

[dhuseby]

@dhuseby I think this will work.

So, we don't actually need to hash the entry to check that against the CID -- that's already baked into the proof field, right?

Yes, because the lock script typically verifies a signature over the serialized proposed entry. As long as the prev CID is included in that signature--which it is if you're signing the serialized entry--then it is baked into the proof. That's a cryptographic commitment to the previous entry baked into the proof.

[dhuseby]

OR... make it a cargo workspace with all the multi- codebases in one repo? OR... merge these upstream (I'm looking at you, multicid. You already have cid crate, could this not be pushed upstream?)

Maybe eventually. That would bring in a bunch of people with opinions that don't understand what we're doing. I constantly get: "just use DIDs/UCANs". 🤦🏻‍♂️

[dhuseby]

I'm swtiching to this workspace clone https://github.com/DougAnderson444/multicrates for the meantime for ease of development (and for great justice).

Can I just fork this to "upstream it"? I think you should add a multicrates::prelude::* to this crate instead of having to do use multicrates::{multikey, multisig,...}. Since you have features set up to include/exclude parts, then the prelude will only import the parts enabled by features.

[dhuseby]

I like the multicrates and want to add one here.

[DougAnderson444]

Can I just fork this to "upstream it"?

I had to clone them all in order to re-write the deps in the Cargo.tomls. So I'm not sure forking would work... you may have to create a new repo, unless you know some git voodoo to keep all the history and merge multiple gits togther?

I think you should add a multicrates::prelude::* to this crate instead of having to do use multicrates::{multikey, multisig,...}. Since you have features set up to include/exclude parts, then the prelude will only import the parts enabled by features.

Good idea, I pulled this in

[DougAnderson444]

people with opinions that don't understand what we're doing. I constantly get: "just use DIDs/UCANs". 🤦🏻‍♂️

Understandable. Adoption takes time.

You know, it should be pretty easy to make a did:vlad method, just saying.

As for UCAN, I see a PCAN in the future? ;P

Pecan, get it?

Not that you need more ideas or pokers in the fire, I'm just saying it could be done.

[dhuseby]

You know, it should be pretty easy to make a did:vlad method, just saying.

I'm the original author of did:git back in 2018? 2019? something like that. DID's don't solve anything. They are too tightly bound to their context without encoding the identifier for the context. What I mean by that is that DID's only have meaning in a given instance of a system that uses DIDs (e.g. BlueSky). If BlueSky was open source and I stood up my own instance called RedSky, then whenever you got a DID referencing a post, you have a problem. Which instance has the post, BlueSky or RedSky? There's only three solutions to this problem:

1. You build a central "resolver" that indexes all of the DIDs from all instances and maps them from DID to instance so that clients have one place to resolve a post DID into the actual data.
2. Clients just ask every instance if they have a specific post DID.
3. You encode the instance identifier with the DID.

With 1, you're centralizing. Just use URLs. Option 2 is not scalable. Option 3 is just re-inventing URLs.

Also, there is no requirement for DIDs to contain content addresses nor is there a requirement for them to be verifiable (i.e. they contain some authenticity verification data in the DID).

As for UCAN, I see a PCAN in the future? ;P

Maaaaybe. The plog structure does a much better job of fine-grained IAM with revocation. The delegation structure and programmable nature makes it a full replacement for enterprise-grade IAM. UCANs make sense if all you have is DIDs. And as such, they suffer the problems that plague DIDs.

The primary goal is NOT solving how to create an identifier and attach capabilities to them; that has been solved MANY times over and keeps getting re-invented without any meaningful improvement. The primary goal is understanding and implementing three-state links (e.g. valid, invalid, partially-valid/healable) that make a network self healing in a unilateral and secure way.

Individual actors must be able to repair the links unilaterally and in a verifiable and secure way. The web possesses this property when we use URLs+x.509+smart URL routers/search pages. The self-healing mechanism on the web is colloquial, not standard procedure, but it is unilateral and secure. It turns out that there's just enough unilateral self-healing going on to make the web, THE web.

The VLAD+plog design is specifically meant to create a unilateral and secure mechanism for creating self-healing content addressed, and pubkey verified, p2p networks. It is NOT about yet another identifier (because URLs weren't invented here or something). It is an intentional design to provide the pre-conditions necessary to create THE public key infrastructure network.

[dhuseby]

I'll re-base this onto the mono-repo soon. It's in my todo list.