@calimero-network/mero-js 24.2.0 → 24.3.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -230,16 +230,18 @@ export declare class AdminApiClient {
230
230
  * Ask what this node can do for a member in `contextId`, before they sign
231
231
  * anything.
232
232
  *
233
- * The two facts {@link performIntent} needs and a client cannot derive: whose
234
- * account and key go in the warrant's `executor` and `executor_key`, and
235
- * whether this node holds `CAN_AUTHOR_ON_BEHALF` on the owning group.
233
+ * The facts {@link performIntent} needs and a client cannot derive: whose
234
+ * account and key go in the warrant's `executor` and `executor_key`, which
235
+ * release it pins, and whether this node holds `CAN_AUTHOR_ON_BEHALF` on the
236
+ * owning group.
236
237
  * `canAuthorOnBehalf: false` comes back as an answer rather than an error, as
237
238
  * it is the default state of every context, so a caller can say "an admin of
238
239
  * `groupId` must grant it to `executorAccount`" instead of presenting a
239
240
  * warrant that will be refused after the author has spent a nonce on it.
240
241
  *
241
- * `404` means the context belongs to no group, or this node holds no account
242
- * yet; either way it can be named as no warrant's executor.
242
+ * `404` means the context belongs to no group, this node holds no account or
243
+ * identity in it yet, or its group names no release yet; no warrant can be
244
+ * spent here until that changes.
243
245
  *
244
246
  * For a caller with no credential on the node at all — a browser tab holding
245
247
  * one signing key — use `RelayClient`, which reads this same route on a node
@@ -562,16 +562,18 @@ export class AdminApiClient {
562
562
  * Ask what this node can do for a member in `contextId`, before they sign
563
563
  * anything.
564
564
  *
565
- * The two facts {@link performIntent} needs and a client cannot derive: whose
566
- * account and key go in the warrant's `executor` and `executor_key`, and
567
- * whether this node holds `CAN_AUTHOR_ON_BEHALF` on the owning group.
565
+ * The facts {@link performIntent} needs and a client cannot derive: whose
566
+ * account and key go in the warrant's `executor` and `executor_key`, which
567
+ * release it pins, and whether this node holds `CAN_AUTHOR_ON_BEHALF` on the
568
+ * owning group.
568
569
  * `canAuthorOnBehalf: false` comes back as an answer rather than an error, as
569
570
  * it is the default state of every context, so a caller can say "an admin of
570
571
  * `groupId` must grant it to `executorAccount`" instead of presenting a
571
572
  * warrant that will be refused after the author has spent a nonce on it.
572
573
  *
573
- * `404` means the context belongs to no group, or this node holds no account
574
- * yet; either way it can be named as no warrant's executor.
574
+ * `404` means the context belongs to no group, this node holds no account or
575
+ * identity in it yet, or its group names no release yet; no warrant can be
576
+ * spent here until that changes.
575
577
  *
576
578
  * For a caller with no credential on the node at all — a browser tab holding
577
579
  * one signing key — use `RelayClient`, which reads this same route on a node
@@ -475,10 +475,10 @@ export interface PerformIntentResponseData {
475
475
  * What a node says about running intents in one context — read before minting a
476
476
  * warrant, not after being refused one.
477
477
  *
478
- * Every input to a warrant is something the author already holds except two:
479
- * whose account and key go in `executor` and `executor_key`, and whether that
480
- * node may act here at all. Both belong to the node, so both are answered here,
481
- * on the path the intent will be presented to.
478
+ * Every input to a warrant is something the author already holds except three:
479
+ * whose account and key go in `executor` and `executor_key`, which release it
480
+ * pins, and whether that node may act here at all. The node knows them, so they
481
+ * are answered here, on the path the intent will be presented to.
482
482
  *
483
483
  * Reading it first is what lets a client fail before signing. A warrant spends a
484
484
  * nonce from a monotonic per-device sequence, and one naming the wrong executor
@@ -504,6 +504,14 @@ export interface IntentRelayInfo {
504
504
  canAuthorOnBehalf: boolean;
505
505
  /** The group whose admin must grant that capability, 64 hex. */
506
506
  groupId: string;
507
+ /**
508
+ * The blob id of the release that group names, 64 hex: what a warrant for this
509
+ * node must pin as `release_bytecode_id`. The route answers 404 while the group
510
+ * names no release.
511
+ */
512
+ releaseBytecodeId: string;
513
+ /** That release's semver, for the warrant's `release_version`. */
514
+ releaseVersion: string;
507
515
  }
508
516
  export interface NodeIdentity {
509
517
  /**