Irakli Gozalishvili

> > Non linear proofs > > Yeah, I agree with you, at least in principal! I think that revocation and memoization get harder if we aren't including the proof...

> I'm not totally sure that I follow the topic here. Do you mean the idea that we discussed last week or the week before where Alice can "automatically forward"...

> If the issuer of UCAN_A revokes UCAN_C, this is a very straightforward marking of UCAN_C invalid everywhere. wait I thought issuer could only revoke tokens it issued and not...

> In the current system, a delegation chain like this... > > UCAN_A > | > V > UCAN_B > | > V > UCAN_C > | > V >...

> Under this proposal, you now have to say something like "you can't use UCAN_A to prove UCAN_C". We now gossip about the tuple (UCAN_A, UCAN_C, signature) instead of the...

I guess it’s along the lines of downstream revocation. You may not want to revoke all of the things just individual use

I don’t think tracking is getting much more complicated, or at least I don’t see why. We already have to track cid sets to account for amplification. With this proposal...

> How does having the roots in the UCAN paylaod make consuming this easier? We omit some of the blocks we have transmitted prior. So you may have CAR that...

I'm also realizing after discussions in https://github.com/ucan-wg/invocation/pull/1 I'm realizing that context in which I was seeking this feature was invocations and not delegations. I am also starting to understand why...

While I think removing `prf` may have merit, I'm bit hesitant. I really like that UCANs are essentially stateless, so I can go and verify them on different nodes with...