Proposal: Always use CIDs in prfs

[Gozala]

I've mentioned it before, but I really wish "prf"s just always referred to CIDs which then could be provided in "fct"s. That would however imply specifying how one were to encode specific fact to arrive to exact same CID (is it just CBOR encoded something more ?)

I think that would also work much better if we were to pursue alternative e.g. CBOR formats and transports as per #16 as those would just end up as IPLD links.

In other words I think it would make sense to have representation that always refers to CIDs (which I think would reduce payloads for signatures) that way contents for the CIDs could be provided with token in "fct"s (or some other field) or omitted when recipient is known to have certain CIDs. Furthermore it makes it possible to adapt amount of data that needs to be moved around depending on who is it for which seems trickier to do when things are inlined as that would affect signatures (unless I'm misunderstanding something)

[expede]

We get the exact opposite feedback from folks in web2 contexts that are adopting UCAN 😛 I think this can become part of the codec discussion #18, but leaving open here in case we want to talk about availability concerns or similar here.

[expede]

Maybe some history: fct initially came out of the desire to refer to data by CID, and later expanded to arbitrary data.

I guess my other question is: why in the fct field? So that we don't need to hash the witnesses at runtime? What if the CID is incorrect in fct?

The way that we do this today is by hashing the prfs as needed. They are encoded as base64 strings, and generating a CID is not an expensive operation. We get certainty about the correct CID value, and don't need to do this extra mapping step when the CID isn't used.

An earlier draft of UCAN 0.8 did use the format prf:bafy123456. This is a bit redundant, since we have static data in an ordered array, so we can save quite a few characters by using the index in that case (e.g. prf:#42)

[Gozala]

I guess my other question is: why in the fct field? So that we don't need to hash the witnesses at runtime? What if the CID is incorrect in fct?

No we'd still have to verify that fcts are correct. I don't really care which field mostly I'm interested in having lookup table that can contain all or the the subset of all CIDs referenced.

Now that I came to think of it, I am not sure what is the payload that is signed when creating a delegating token. My primary motivation had been:

1. Make signatures agnostic of UCAN encoding so that alternative representations are viable. In other words I would like signatures to come out the same regardless if proofs are nested or referenced by CID.
2. When delegating UCAN you need to decide whether to link by CID or nesting, this is unfortunate. Ideally you would create delegated UCAN and during serialization decide what to include / exclude based on your knowledge of the recipient.

Maybe both of my desires are already met and I am simply overlooking things.

[Gozala]

I have looked at the implementation to see what get's signed to either validate or invalidate my assumptions, and based on what I see here
https://github.com/ucan-wg/ts-ucan/blob/118670b3a7940e78230aba1484cece3f89c8998f/src/token.ts#L108-L122
https://github.com/ucan-wg/ts-ucan/blob/118670b3a7940e78230aba1484cece3f89c8998f/src/token.ts#L137-L146

I think my assumptions were both valid (in that structure would affect signatures) and invalid (looks like fcts are still included in payload so refactoring into CIDs not going to help).

[expede]

Now that I came to think of it, I am not sure what is the payload that is signed when creating a delegating token. [...] I have looked at the implementation to see what get's signed to either validate or invalidate my assumptions, and based on what I see here

TL;DR all fields get signed

The header and payload are signed: the entire token (except the signature) is encoded, hashed, and signed. All data in any field in the UCAN is signed together.

(looks like fcts are still included in payload so refactoring into CIDs not going to help).

Yes — but I think there's a solution! This is the sketch that I mentioned in #18, but prompted entirely by this thread. The concept is WIP, but the short version is that we can take a page from CAR files, and introduce a pointer machine as a "collection". Here's a rough sketch:

{
  "_entrypoint": encodedJwt({
    header: {ucv: "0.9.0", typ: "JWT", alg: "EdDSA"},
    payload: { ..., proofs: [ "QmABCDEF", "Qmxyz" ]},
    sig: "jksajdksajkdjsajkla"
  }),
  "QmABCDEF": encodedJWT(... morejwt),
  "Qmxyz": encodedJWT(... anotherjwt),
}

This has a few advantages:

• CID references don't need to depend on a DHT
• You can also omit any deeply nested proofs that you don't need to prove your current capabilities
• Dedup deeply nested common dependencies (e.g. A -> B, A -> C, B -> D, C -> D)
• Can drop any UCANs that we know that the other side has seen before, or has access to via a DHT (though both would need further specification about headers and error states).
• Makes it practical to reference the proof right on each capability (...maybe... would need more thought)

We could use this would replace inlined UCANs completely and actually improve the reliability over the current version, because you can replace the CID resolution as just this collection format which is just "there", inline. Also it frees UCAN from a hard dependency on IPFS.

Downsides:

• Less space efficient: listing the CIDs twice to make the link takes up space 🤷‍♀️

@bgins has brought up that this may be harder for a developer learning about UCAN to follow. It's pretty easy to follow how something would be nested, versus following links. Pointer machines have more things that can go wrong than inlining, but I personally think that the benefits probably outweigh the costs.

[expede]

I'm also curious about adding UCANs as a multiformat, rather than needing the URI-style ucan: (not in the spec today, intentionally left out for now). Is that worth doing do you think?

[Gozala]

I'm also curious about adding UCANs as a multiformat, rather than needing the URI-style ucan: (not in the spec today, intentionally left out for now). Is that worth doing do you think?

Not sure what exactly you mean, but I would guess it would make them less readable

[expede]

Just an idea to add carrier information to an encoded UCAN to say (e.g.) what format it's in if we were to generalize the encoding. It could say "this is a UCAN, version X, encoded as Y"

Less readable than ucan:: less understandable to humans, you mean?

[Gozala]

Less readable than ucan:: less understandable to humans, you mean?

Exactly

[expede]

LOL also converting this to a discussion since I'm apparently writing a lot here 😅

[expede]

@Gozala related to the wire-friendly format discussion in #18, do you happen to know how far along CARv2 is?

[Gozala]

I'm unaware of anyone working on it, that is not to say no one is, but given how much we use CARs I would imagine it would have came up if it was coming along.

[Gozala]

@Gozala related to the wire-friendly format discussion in #18, do you happen to know how far along CARv2 is?

Either way I think it would be best to avoid speechifying exact wire format, it would be much better to have IR representation and make transport domain specific.

[bgins]

Does always using CIDs create a external dependency that would make it difficult for some developers to use UCANs? I'm thinking about developers who are not familiar with CIDs and how to work with them.

Also, maybe there are offline cases where you can't resolve a CID?

[bmann]

This is kind of an interesting question. One can treat a CID like "just" a unique, global identifier. This would be the same as using any other opaque identifier, with the added benefited that if you are online, you can resolve it to get more info.

[Gozala]

Does always using CIDs create a external dependency that would make it difficult for some developers to use UCANs? I'm thinking about developers who are not familiar with CIDs and how to work with them.

Also, maybe there are offline cases where you can't resolve a CID?

I may have not been clear here, what I was suggesting is to switch from nested structure to flat structure keyed by CID. That way things would work the same way in regards to offline etc, UCAN will just have lookup dict of things in 'fct's.

[expede]

@Gozala yeah, I understood that — @bgins and I actually talked this through on our team call earlier today. I personally really like this proposal! It's also getting mainly positive feedback from folks I've run it past, too. I need to prototype what it would look like (e.g. the exact encoding), but looks promising!