Task as a UCAN #27
andrewzhurov
started this conversation in
Ideas
Replies: 1 comment
-
Usings UCANs as Tasks allows for an interesting feature - subsequent UCANs can be issued to provide more specificity / restrictions. Which is an interesting property for the problem of "how to specify that a particular Receipt must be used for an await", mentioned here. E.g. {
"bafy...updateDns": {
"dns:example.com?TYPE=TXT": {
"crud/update": {
"input": {
"value": {"ok/await": "bafy...someInstruction"}
}
}
}
},
"bafy...updateDnsTask": {
"ucv": "0.2.0",
"iss": "Invoker's DID",
"aud": "Executor's DID",
"nnc": "some nonce",
"fct": {"retries": 5,
"cause": {"/": "bafy...somePriorInstructionTaskInvocationReceipt"}},
"cap": {"/": "bafy...updateDns"},
"prf": [{"/": "bafyreieynwqrabzdhgl652ftsk4mlphcj3bxchkj2aw5eb6dc2wxieilau"}]
},
"bafy...updateDnsTask2": {
"ucv": "0.2.0",
"iss": "Executor's DID", // issued by the Executor
"aud": "Executor's DID",
"nnc": "some nonce",
"fct": {"retries": 5,
"cause": {"/": "bafy...somePriorInstructionTaskInvocationReceipt"},
"awaited": [{"/": "bafy...someInstructionReceipt"}]}, // awaited Receipt
"cap": {"/": "bafy...updateDns"},
"prf": [{"/": "bafy...updateDnsTask"}] // previous UCAN
}
} |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
As hard as I try to squint my eyes I struggle to see the difference between the two.
Here's how it appears to me.
Task is Instruction + Meta + authorization of Executor to perform the Instruction.
UCAN's Capability is akin to Instruction, Facts is akin to Meta,
aud
is akin to authorization.Perhaps Task could be expressed as a UCAN?
So the invocation spec can reuse all great effort UCAN spec's done towards authorization and could focus solely on solving the problem of invocation.
E.g., expressing Task (in v1 spec #21 ) as a UCAN
There is one misalignment however, in that Caveats are meant to capture both restrictions on what can be called (akin to Inputs of an Instruction) and how it can be called (e.g., gas, retries, etc.), i.e., restrictions on how it can be invoked.
I.e., Caveats are used to express restrictions of what a function can be as well as restrictions of how it is to be invoked.
Whereas in Invocation spec it corresponds to Instruction's Input and Task's Meta.
I think Invocation spec got it right, it's a useful distinction. For example, it allows to reuse functions/Instructions in Await.
But this mix of the two in UCAN spec is not a problem, since UCAN provides Facts field which could be used for Meta.
We just need to agree to store Meta there.
I may be wrong, goes without saying 😄, happy to hear your thoughts!
Beta Was this translation helpful? Give feedback.
All reactions