@openvtc/trust-tasks 0.28.2 → 0.28.3

package/CHANGELOG.md

@@ -11,6 +11,89 @@ 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.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,CAM/D,CAAC"}

package/dist/_extends.js

@@ -5,5 +5,11 @@
  * 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/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",
+});
 //# 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,mDAAmD,EAAE,KAAK;IAC1D,0DAA0D,EAAE,KAAK;IACjE,uDAAuD,EAAE,KAAK;IAC9D,wDAAwD,EAAE,KAAK;IAC/D,0DAA0D,EAAE,KAAK;CAClE,CAAC,CAAC"}