v0.10 #132
v0.10 #132
Conversation
Co-authored-by: Irakli Gozalishvili <contact@gozala.io> Signed-off-by: Brooklyn Zelenka <be.zelenka@gmail.com>
Signed-off-by: Irakli Gozalishvili <contact@gozala.io>
update example as per discussion in #123
|
Why is the Valid DagJSON would be: "prf": [
{ "/": "bafkreihogico5an3e2xy3fykalfwxxry7itbhfcgq6f47sif6d7w6uk2ze" },
{ "/": "bafkreiemaanh3kxqchhcdx3yckeb3xvmboztptlgtmnu5jp63bvymxtlva" }
]Maybe there's a reason for this that I'm missing? |
Co-authored-by: Hugo Dias <hugomrdias@gmail.com> Signed-off-by: Brooklyn Zelenka <be.zelenka@gmail.com>
| ] | ||
| { | ||
| "ucan:bafkreihogico5an3e2xy3fykalfwxxry7itbhfcgq6f47sif6d7w6uk2ze": {"ucan/*": [{}]}, | ||
| "ucan:*": {"ucan/*": [{}]} |
There was a problem hiding this comment.
Do we need ucan/ prefix on the ability here ? We used to have special * ability to denote "all" abilities which was far more intuitive than ucan/*. If it really need to be name-spaced I would suggest */* as it feels far more intuitive that * and */* would include crud/read than ucan/*.
There was a problem hiding this comment.
We also use { with: "ucan:*", can: "*" } when linking devices which I think would be considered invalid ? If so it is probably worth calling out what it would imply.
| end | ||
| end | ||
|
|
||
| ... --> * |
There was a problem hiding this comment.
I would really like if the hierarchy above was actually part of the spec, meaning that it would be really useful if it was specified that msg/* includes msg/send and * included msg/* and crud/* etc.. Which as I understood from our side channel conversation is not implied
There was a problem hiding this comment.
At the level of the UCAN spec, we're leaving it by convention for now. Not all namespaces have a .../*, but I do think that we want to start writing related specs for essentially a stdlib of common abilities and resources 💯
|
Love the new structure for attenuation! Feels much better than previous list of |
|
|
||
| The DID spec [permits an arbitrary DID method to specify the use of the URI path segment](https://www.w3.org/TR/did-core/#path), the `own` scheme separates out the reference of owned resources rather than a DID document itself. Other URI schemes (such as `dns` and `telnet`) define their own syntactic rules. `own` makes it clear that the contained DID is the "owner" of the resource in the path, fragments, and queries. | ||
| `ucan:*` represents all of the UCANs in the current proofs array. If selecting a particular proof (i.e. not the wildcard), then its CID MUST be used. In the case of selecting a particular proof, the validator MUST check that the delegated content address is listed in the proofs (`prf`) field. |
There was a problem hiding this comment.
@expede Bit confused by this section. This paragraph says:
ucan:*represents all of the UCANs in the current proofs array.
But the table above says:
ucan:*All possible provable UCANs
ucan:./*All in this UCAN's proofs
Does the syntax in the paragraph need to be adjusted to ucan:./*?
Or am I confused about what ucan:* actually means?
I assume it means more than just the current proofs array?
There was a problem hiding this comment.
Ah indeed, we should make this consistent — apologies. It's also something that I don't love about this syntax: it's not very salient despite the meaning being quite different
Preview 📜
Closes
atttocap?fctinto a map as opposed to array #1343.2.5 Attenuation? #135OWN#141 [remove it]alg:noneoption #145fctinto a map as opposed to array #134ucvfield from header to body (to make implementation & e.g. CACAO interop easier)Removed/Deferred from Scope
did:mailto)