Should invocation be different from deriviation ?

[Gozala]

I found myself recently suggesting to disambiguate invocation from delegation by encoding former differently (omitting some fields that seem irrelevant in that context). Reflecting on it I, realize I've been motivated by the fact that there is something odd about defining RPC protocol in terms of UCANs, although perhaps it's just novelty that makes it fill that way ?

Here is the laundry list of what feels odd with RPC in UCANs

1. List of capabilities imply list of operation to run.
   1. That means responses need to be mapped back by index which is awkward unless you think of them as tuples as opposed to lists. For invocations I'd find named records to be far better personally.
   2. Should those operation be run concurrently or sequentially ? While it certainly can be domain specific, I find that specificity behavior would be far better. I'm also mildly in favor of sequential order simply because you could send multiple invocations in same request and run those concurrently.
2. Bunch of fields seem kind of irrelevant in invocation
   1. exp seems redundant, if invocation has proof than it inherits it. If it is self issued and recipient just needs to run it I can't think of reason to put expiration on that (although perhaps that is because all operations are idempotent).
   2. nbf seems to be the same as exp.
   3. nnc also seems odd to me, I think it would be much more cleaner to put a field in the specific "capability" been invoked to ensure uniqueness.
   4. fct seem relevant in derivation context, but I'm not sure they do in invocation. If you need to supply some facts with your invocation it probably better be inside invoked capability ?
   5. att Already covered that in 1. It feels like it should just be a single invocation of the capability instead.
3. This is silly but having can field as discriminant of invocations seems awkward (and turns out confuses team mates). Feels like different key (e.g. do) fits better the invocation.
   • I also found myself encoding invocations as nested structures resembling GraphQL, so you end up with can paths e.g store/add been mapped into { store: { add: { ... } } without having to encode those in can fields.

On the other hand I am also recognizing that differentiating invocations from delegation would imply that audience of the invocation will be unable to derive from it, which in turn implies that invocations that pass through multiple actors should know final recipient. I'm not certain if that is a limitation or just forces more clarity in regards to when one should use delegation opposed to invocation.

One other observation is that we basically always have a leaf UCAN that reduces capabilities to minimum needed to perform an action, which probably would be unnecessary if separate structure for invocations existed.

Finally all this thinking was inspired by the fact that "revocation" has different structure which did not exactly fit into our RPC defined in terms of UCANs. This in turn go me thinking that perhaps "invocation" and "revocation" are far more alike than "delegation" so problem is not that "revocation" does not fit, but rather that "revocation" is specific "invocation" and we just don't have a good structure for invocation itself.

Thoughts ?

[Gozala]

On the other hand I am also recognizing that differentiating invocations from delegation would imply that audience of the invocation will be unable to derive from it, which in turn implies that invocations that pass through multiple actors should know final recipient. I'm not certain if that is a limitation or just forces more clarity in regards to when one should use delegation opposed to invocation.

It is worth pointing out that invocation & delegation can coexist, issuer could invoke an action and delegate capability to do that and other things to the audience at the same time, which would address unknown final recipient case.

Audience of the invocation may require additional capabilities to perform sub-task, in which case issuer would need to delegate those along with invocation. I kind of feel that should not be an argument against disambiguating invocations, but rather an argument to consider more clear interface for invocations that calls out what is been delegated.

On the related note, does it always clear from just capabilities what audience is been asked to do (especially when set of capabilities are delegated) ? I suspect not, which is precisely why I find need for separate form for invocation.

[expede]

Just to copy/paste over to this thread, here's one extremely rough (and frankly contrived!) version of what that could look like:

Wrapper

// Capability per normal
{
  "with": "mailto:[email protected]",
  "can": "msg/send"
}

// Complex invocation/scheduler wrapper

{
  "act": [
    {
      "with": "mailto:[email protected]",
      "do": "msg/send", // May not match 1:1 with "can", since some are hierarchical
      "to": "[email protected]",
      "sub": "Coffee",
      "msg": "Let's get a coffee this afternoon"
    }
  ],
  "now": [0]
  "cron": [
    {
      "tab": "0 0 * * 0",
      "act": [0]
    }
  ],
  "prf": ["bafyABCDEF"] // The UCAN
}

[Gozala]

@expede few questions regarding the spec

1. Why is act an array ? Is the idea that it could have multiple invocations ? Is there reason why one would do this over creating just separate invocations (meaning those wrapper object) ?
2. I would push now and cron inside the act[0] itself, while I realize those could general enough it still feels like executor should act per input, although maybe I'm missing something.

[expede]

extremely rough (and frankly contrived!) version

@Gozala no grand reason why, I threw this draft together in under 2 minutes 🤷‍♀️ Don't take it as a serious proposal, just as something to get the feel for the kinds on things we'd want to do

[expede]

Is there reason why one would do this over creating just separate invocations (meaning those wrapper object) ?

@Gozala I agree that scheduling several cron jobs in the same request likely doesn't make sense, but there is a good reason to support this: atomic actions. For example "I want to update both of these file systems, but if only if they both succeed", or "when the long running process X finishes (when I'll be offline), the run Y"

We can choose to not support these, but should do so intentionally

[Gozala]

@Gozala I agree that scheduling several cron jobs in the same request likely doesn't make sense, but there is a good reason to support this: atomic actions. For example "I want to update both of these file systems, but if only if they both succeed", or "when the long running process X finishes (when I'll be offline), the run Y"

We can choose to not support these, but should do so intentionally

Yeah this is a good point which reminds me I have considered this in my ucan-rpc work myself as a way to express atomic transactions. Ultimately I decided against them because:

1. Some actions can't be made transactional e.g. msg/send that sends out email. You could have transaction that says send email and do this other thing that can fail. If the other thing fails you can't really take the email back.

   Making it part of invocation interface seems troublesome because either system would need to be fully transactional or it would have to fail if non transactional operations are weaved in. In the end seems like it would cause more trouble in practice. It seems like expressing transactions at the capability level would provide better ergonomics for both providers and users.

2. Mapping request / response types became a lot more complicated again in ucan-rpc stuff. In my current implementation every request can contain multiple ucan invocations and if each invocation could have multiple actions you end up with tuple of tuples on every request.

3. Encoding and verification is both simpler if you have a single path to trace, although perhaps not significantly so.

For what it's worth I have considered adding transactions via separate interface as a means to still support transactional invocations, but I have not got around to that yet.

[Gozala]

As we start developing more things using ucanto (our UCAN RPC library) we've started recognizing few patters that I'd like to report and hopefully get some ideation around.

1. We have decided to keep things simple and allow a single capability in the invocation.
   • 💔 It does prevent encoding transactional invocations like do A and then B or neither.
   • 💚 But we find requirement of making all capabilities transaction-ally composable unrealistic. This API choice reflects that and if you want transactional A + B you can still define separate capability A+B instead.
2. More and more we are recognizing the fact that constraints on capabilities in (att) aren't always the same as parameters of invoked capability. Relation there is more on the side of parameters MUST satisfy imposed constraints.
   • I'm starting to think we need another field that is a dual to "caveats" (known as nb field in v0.9 spec).
   • On the other hand our supervisor / router service may receive invocation and derive routed invocation to other service in which case it's delegated invocation which doesn't exactly fit into either invocation or delegation semantics.
   • We have already talked about the idea of maybe disambiguating issued capabilities from re-delegated capabilities by moving former from att into dedicated my field. Maybe it would make sense to do the same for invocations and introduce another act field ? That way delegated invocation would have be REQUIRED to copy subset of act-ed capabilities.
     • I think that may make things a bit more clearer

[andrewzhurov]

exp seems redundant, if invocation has proof than it inherits it

I.e., treat UCANs as deltas that only add more specificity / attenuation, rather than a snapshot / version.
Akin to capturing capturing deltas to a text file vs capturing snapshots of that file (as in Git).
Seems that deltas more closely capture semantics of the issued UCAN - what exact specificity it introduces.
Deriving a snapshot also is more challenging on UCAN issuer, as it would require merging the delta to the previous UCAN.
As well as snapshots are more challenging for validator, as it would need to derive back the delta of each UCAN to verify that it's an attenuation.
Also snapshots seem to add redundant size, as validator would in any case need to go through the UCAN chain in order to validate.
I.e., only deltas are valuable (novel) information, the rest is evident from the UCAN chain.