Readonly blocksMap of all the IPLD blocks that were included with this delegation DAG.
Usually this would be blocks corresponding to proofs, however it may
also contain other blocks e.g. things that capabilities or facts may
link.
It is not guaranteed to include all the blocks of this DAG, as it represents
a partial DAG of the delegation desired for transporting.
Also note that map may contain blocks that are not part of this
delegation DAG. That is because Delegation is usually constructed as
view / selection over the CAR which may contain bunch of other blocks.
Readonly bytesReadonly cidReadonly dataOptional nonceOptional notReadonly rootThe root block of the IPLD DAG this is the view of. This is the the block from which all other blocks are linked directly or transitively.
Attach a block to the delegation DAG so it would be included in the
block iterator.
⚠️ You can only attach blocks that are referenced from the capabilities
or facts.
Encodes all the blocks and creates a new IPLDView instance over them. Can be passed a multihasher to specify a preferred hashing algorithm. Note that there is no guarantee that preferred hasher will be used, it is only a hint of preference and not a requirement.
Optional options: "/home/runner/work/w3up/w3up/node_modules/.pnpm/@ucanto+interface@10.0.1/node_modules/@ucanto/interface/dist/src/lib".BuildOptions<unknown, "/home/runner/work/w3up/w3up/node_modules/.pnpm/@ucanto+interface@10.0.1/node_modules/@ucanto/interface/dist/src/lib".MulticodecCode, "/home/runner/work/w3up/w3up/node_modules/.pnpm/@ucanto+interface@10.0.1/node_modules/@ucanto/interface/dist/src/lib".MulticodecCode>Returns an iterable of all the IPLD blocks that are included in this view. It is RECOMMENDED that implementations return blocks in bottom up order (i.e. leaf blocks first, root block last).
Iterator MUST include the root block otherwise it will lead to encoders into omitting it when encoding the view into a CAR archive.
Note that we would like to rename this method to blocks but that would
be a breaking change on the Delegate API so we defer it for now.
Generated using TypeDoc
An Invocation represents a UCAN that can be presented to a service provider to invoke or "exercise" a Capability. You can think of invocations as a serialized function call, where the ability or
canportion of the Capability acts as the function name, and the resource (with) and caveats (nb) of the capability act as function arguments.Most Invocations will require valid proofs, which consist of a chain of Delegations. The service provider will inspect the proofs to verify that the invocation has sufficient privileges to execute.