@openvtc/trust-tasks 0.28.2 → 0.28.4

package/CHANGELOG.md

@@ -11,6 +11,152 @@ The package versions over **its own API** — what a consumer compiles against
 not over `SPEC.md`. Below 1.0 a breaking change bumps the leading non-zero
 component.
 
+## 0.28.4 — 2026-10-30
+
+
+### Added
+
+- **vta/webvh/dids/update**: 1.1 lists or removes an existing log's did:scid alias (#992)
+
+* feat(vta/webvh/dids/update): 1.1 lists or removes an existing log's did:scid alias
+
+  Every did:webvh log is also a did:scid:vh:1 identity, but the two are distinct
+  subjects until the did:webvh document lists the did:scid DID URL in
+  alsoKnownAs (VTI-KEY-164). create/1.2 lists it in the first entry by default;
+  a log created before it, or without it, had no way to get it but sending a
+  whole replacement document with a hand-built DID URL — and the src encoding
+  (`%3A` for a port, `/` for each `:`) is exactly what a client gets wrong.
+
+  1.1 adds `scidAlsoKnownAs` (boolean): true lists the DID URL for the log's
+  current location (replacing one left from before a move), false removes
+  every did:scid entry naming this SCID. The agent derives the DID URL; the
+  caller never writes it. The response reports `scidAlsoKnownAs` and
+  `scidDidUrl`. New codes: `scidAliasRequired` (removing the alias of an
+  identity the agent presents as did:scid, VTI-KEY-166) and `noChange` (an
+  entry identical to the latest is not published, so the update key is not
+  rotated for nothing).
+
+  This is the pre-key-role path: vta/dids/update refuses every identity created
+  before key roles (notKeyRoleIdentity), which is every did:webvh DID that
+  exists today. Only adds, so 1.1 extends 1.0. All four bindings regenerated.
+
+- **peer-check**: Peer-check/ask 0.1 — a signed yes or no from a peer's own device (#973)
+
+* feat(peer-check): peer-check/ask 0.1 — a signed yes or no from a peer's own device
+
+  One party asks another a short question, such as "did you just ask me
+  for this?", over a channel they already share. The responder's device
+  prompts its user and returns a signed answer that echoes the challenge
+  and carries the task digest of the request, so the asker can verify it
+  against the responder's DID and it cannot be replayed against another
+  ask.
+
+  Draft. Specification, schema, negative examples and the regenerated Rust,
+  TypeScript, Go and Dart bindings.
+
+- **rooms/keys/act**: 0.9 completes rooms/records/put/0.4 (#990)
+
+rooms/records/put/0.4 (#987) lets a record on an open room carry a file,
+  its description and random file key in cleartext.file. 0.8's table is
+  closed (Recipient item 1) and names records/put at 0.1–0.3 only, so a
+  conforming key holder refuses 0.4 with typeNotActable: a member whose keys
+  their key holder holds could upload an open room's blob (upload/begin/0.2
+  is in the table) but never write the record that names it, and the blob
+  would sit unreferenced until collected.
+
+  0.9 adds rooms/records/put/0.4 to the put row, write, presentation
+  inserted, completed exactly as 0.3. The key holder neither mints nor checks
+  the file key: the producer mints it (put 0.4 Producer item 7), the host
+  checks the record (Host item 12), and the key holder signs what it was
+  handed unaltered (Recipient item 6).
+
+  Schemas are 0.8's and no error code is added; the table only widens, so
+  0.9 declares extends: "0.8" and every spec naming 0.8 stays current. All
+  four bindings regenerated.
+
+## 0.28.3 — 2026-10-30
+
+
+### Added
+
+- **rooms/records/put**: 0.4 lets an open room's record carry a file (#987)
+
+An open room could hold notes and nothing else. A file's description
+  (FileManifest) could only travel inside a sealed record body, and its key could
+  only be derived from the room's per-epoch storage key, and an open room has
+  neither: no sealed body, and no group to derive a key from. rooms/blobs/* never
+  cared about the tier; the gap was entirely on the record side.
+
+  - rooms/records/put/0.4 (extends 0.3): cleartext gains an optional `file`, a
+    FileManifest, and `blobs` may name that file's blob. On an open room the
+    host, which can read the record, refuses with malformedRequest a record whose
+    `blobs` is not exactly `cleartext.file.blobRef`, names a blob without a
+    `file`, or whose `file` carries no `fileKey`.
+  - rooms/_shared/0.1 FileManifest gains an optional `fileKey` (additive): on an
+    open room the uploader mints the file key at random for that one file and
+    carries it there; it MUST be absent from a sealed body, where the key is
+    derived. Padding, STREAM, associated data and reading are unchanged, so
+    there is one blob format and one reader for every tier. The key in the clear
+    withholds nothing from the host, which the open tier never did, but keeps
+    the stored blob opaque to a party holding only the storage.
+  - The descriptions of `name` and `digest` now say what holds on each tier.
+
+  All four bindings regenerated.
+
+- **vtc/admin/invites**: Create and list 0.2 — passkey invitations, with did optional (#989)
+
+* feat(vtc/admin/invites): create and list 0.2 — passkey invitations, with did optional
+
+  vtc/admin/invites/create 0.1 required `did`, so an administrator could invite
+  only someone who already held a DID in a wallet; a passkey invitation — whose
+  administrator DID is derived from the passkey registered at
+  vtc/install/claim/passkey/finish 0.1 — could be issued only by the operator on
+  the host.
+
+  create 0.2:
+  - `did` is optional. Present: a wallet invitation (claimed with
+    vtc/install/claim/{start,finish} 0.3). Absent: a passkey invitation.
+  - `did`, when present, must begin `did:`.
+  - Both kinds confer the same authority: an administrator entry with the
+    community's full administrative authority, delegated by the inviter,
+    labelled with `label`. A wallet invitation writes it now for a DID with no
+    entry; a passkey invitation records it with the invitation and
+    passkey/finish item 9 writes it for the derived DID.
+  - A passkey invitation costs what an entry-writing wallet invitation costs
+    (the inviter's step-up, another administrator's consent): at its claim no
+    administrator is present to authorise it, so issuing it is the grant.
+  - The response gains a required `kind` (`wallet` | `passkey`);
+    `aclEntryCreated` is always false for a passkey invitation.
+
+  list 0.2 (with vtc/_shared/0.2/invite): each InviteSummary gains a required
+  `kind`; a passkey invitation's `targetDid` is absent until it is consumed, then
+  the derived DID.
+
+  revoke is unchanged (it takes only `jti`); its prose now links the 0.2
+  versions.
+
+- **vta/dids**: Method-neutral key-role family, creation and recovery, with per-method profiles (#986)
+
+* feat(vta/dids): method-neutral key-role family, creation and recovery, with per-method profiles
+
+
+
+### Specifications
+
+- **vtc/install/claim/finish**: An invitation binds the approver at finish, not at bootstrap (#988)
+
+vtc/install/claim/finish/0.3 item 6 made the founder's approver binding wait
+  for vtc/admin/bootstrap. On an invitation of an additional administrator —
+  a token naming a DID whose administrator entry the invitation already wrote —
+  bootstrap answers alreadyBootstrapped, so the binding never took effect and
+  the invited administrator could answer no step-up.
+
+  New item 7: when the community already has an administrator, the binding
+  takes effect at finish, with the claim, as vtc/install/claim/passkey/finish
+  0.1 item 9 already writes an invited administrator's entry at finish. The
+  fresh-community rule (bind at bootstrap, discard if the token lapses) is
+  unchanged. Prose only; no schema change.
+
 ## 0.28.2 — 2026-10-29
 
 

package/dist/_extends.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"_extends.d.ts","sourceRoot":"","sources":["../src/_extends.ts"],"names":[],"mappings":"AAAA,wEAAwE;AAExE;;;;;GAKG;AACH,eAAO,MAAM,mBAAmB,EAAE,QAAQ,CAAC,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,CAC/D,CAAC"}
+{"version":3,"file":"_extends.d.ts","sourceRoot":"","sources":["../src/_extends.ts"],"names":[],"mappings":"AAAA,wEAAwE;AAExE;;;;;GAKG;AACH,eAAO,MAAM,mBAAmB,EAAE,QAAQ,CAAC,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,CAQ/D,CAAC"}

package/dist/_extends.js

@@ -5,5 +5,13 @@
  * are listed. Each entry is a DIRECT declaration; the runtime's
  * `extendsChain` follows them transitively.
  */
-export const EXTENDS_BY_TYPE_URI = Object.freeze({});
+export const EXTENDS_BY_TYPE_URI = Object.freeze({
+    "https://trusttasks.org/spec/rooms/keys/act/0.9": "0.8",
+    "https://trusttasks.org/spec/rooms/records/put/0.4": "0.3",
+    "https://trusttasks.org/spec/vta/did-templates/create/3.2": "3.1",
+    "https://trusttasks.org/spec/vta/did-templates/get/3.2": "3.1",
+    "https://trusttasks.org/spec/vta/did-templates/list/3.2": "3.1",
+    "https://trusttasks.org/spec/vta/did-templates/update/3.2": "3.1",
+    "https://trusttasks.org/spec/vta/webvh/dids/update/1.1": "1.0",
+});
 //# sourceMappingURL=_extends.js.map

package/dist/_extends.js.map

@@ -1 +1 @@
-{"version":3,"file":"_extends.js","sourceRoot":"","sources":["../src/_extends.ts"],"names":[],"mappings":"AAAA,wEAAwE;AAExE;;;;;GAKG;AACH,MAAM,CAAC,MAAM,mBAAmB,GAAqC,MAAM,CAAC,MAAM,CAAC,EAClF,CAAC,CAAC"}
+{"version":3,"file":"_extends.js","sourceRoot":"","sources":["../src/_extends.ts"],"names":[],"mappings":"AAAA,wEAAwE;AAExE;;;;;GAKG;AACH,MAAM,CAAC,MAAM,mBAAmB,GAAqC,MAAM,CAAC,MAAM,CAAC;IACjF,gDAAgD,EAAE,KAAK;IACvD,mDAAmD,EAAE,KAAK;IAC1D,0DAA0D,EAAE,KAAK;IACjE,uDAAuD,EAAE,KAAK;IAC9D,wDAAwD,EAAE,KAAK;IAC/D,0DAA0D,EAAE,KAAK;IACjE,uDAAuD,EAAE,KAAK;CAC/D,CAAC,CAAC"}