-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tweaks to Support Workflows #14
Conversation
README.md
Outdated
type Invocation struct { | ||
ctx Context | ||
auth &Authorization | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I'm fairly convinced that this is a requirement regardless of how we want to write worflows. The concern with the existing system is that you need to sign all of the sub-invoctaions because the resource limits are at the same level as the signature. This changes the CID, so you can't sign the Workflow wrapper at the same time without finding a hash cycle.
By pulling the auth to another layer, we get the flexibility to do nesting with a single signature without breaking the signature reference mechanism as it exists in v0.1
.
I actually don't mind if the signature is subtyped or wrapped. I just need a struct that's everything minus the signature, and IPFS Schema doesn't have subtying/splats:
type Context struct {
v Semver
run &Task
meta {String : Any}
prf [&UCAN]
}
-- Subtyped
type Invocation struct { -- Exactly the same as today
...Context
auth &Authorization
}
-- Wrapped
type Invocation struct {
ctx Context -- could also be a Link, but this is closer to today
auth &Authorization
}
The added bonus is that this also signs over all fields, and is really really clear about that fact
Move us to what will be https://github.com/ucan-wg/invocation/pull/13/files (in review/discussion) vs pre-version. Includes: Essentially, all spec things except `Effects(fx)` and still in-progress `Authorization`, i.e. ucan-wg/invocation#14.
Subsumed by #15 |
I'm having trouble expressing workflows that account for resources like timeouts and Wasm fuel limits using the current layout 😭 The core problem is that I don't want to mix resources into the Task level. I'd also like to avoid creating multiple signatures, but that's not as critical.
I think a minor tweak fixes this. I'm trying a few things, but I keep coming back to an earlier proposal. This is just a draft for now, but I want to work in the open, so here's the draft PR 😉