@openvtc/trust-tasks 0.26.18 → 0.26.19

package/CHANGELOG.md

@@ -11,6 +11,62 @@ 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.26.19 — 2026-10-19
+
+
+### Added
+
+- **vtc/directory**: Pictures and external cards — images/upload, images/get, card/publish, card/public (#826)
+
+The two parts of the member directory that had no Trust Task.
+
+- **vtc/directory**: Disclosure — the statement of what a community's directory discloses, and to whom; join manifest 0.4 carries it (#823)
+
+A community offering a member directory must publish a statement of what it discloses and to whom, generated from its configuration, and show it to applicants before they apply (VTI-DIR-130). No task carried one.
+
+  vtc/directory/disclosure/0.1 returns it. The request carries nothing; any reader the community answers vtc/join-requests/manifest for may read it, with or without a proof. The statement (`DirectoryDisclosure`, in directory/_shared/0.1/disclosure-statement.schema.json) lists every active field with its source, ceiling, default visibility and whether it is searchable or a facet; what a new card gets (listing, search, and introductions where the community delivers them); how far a member's membership DID can reach; whether administrators keep notes; whether the community has groups, and how long their membership credentials last; and whether a card can be published beyond the community. Every audience is an upper bound, since policy only narrows. It names itself with a statementDigest (JCS without the digest, SHA-256 multihash), so an applicant can record which statement it was shown. It carries no timestamp, so the digest changes exactly when what it says changes.
+
+  vtc/join-requests/manifest/0.4 adds one optional response member, directoryDisclosure: the same statement, present exactly where the community offers a directory, outside every criterion, so no requirementsDigest moves. Nothing else changes from 0.3.
+
+
+
+### Specifications
+
+- **rooms/owner/group**: Add 0.3 and renew 0.2 settle a pending removal by remove 0.3 item 8 (#824)
+
+rooms/owner/group/remove 0.3 item 8 settles a pending removal "at a later
+  request — of this task or of any other that settles the room's pending
+  advance", and has that other task refuse with its own hostRefused carrying
+  {member, code, listKept}. add and renew are those other tasks, and neither
+  said so: their item 6 knew only the epoch check (read alone, it never
+  redelivers the removal's revocation list), and their hostRefused meant "the
+  host declined the epoch advance; nothing was changed" with no details shape.
+  OpenVTC/verifiable-trust-infrastructure #2191 implements remove 0.3 item 8
+  before add and renew at every version, so that implementation diverged from
+  the add and renew specifications it serves.
+
+  rooms/owner/group/add 0.3 and rooms/owner/group/renew 0.2:
+  - item 6.1 settles a pending removal by remove 0.3 item 8, in full and before
+    the request's own work; item 6.2 is the old epoch check for every other
+    pending advance (and now says an unanswered rooms/info is hostUnreachable);
+  - add earlierRemovalRefused {member, code, listKept}, the same code and
+    details remove 0.3 uses, so all three tasks report it alike;
+  - hostUnreachable gains details.stage (revocation | advance) as remove 0.3;
+    hostRefused gains a bounded details {code, reason} and means only that the
+    host declined this request's own advance.
+  Payload and response schemas unchanged.
+
+  Earlier versions (add 0.1/0.2, renew 0.1) are untouched. The new versions'
+  compatibility notes say what a recipient answers there, which is what remove
+  0.3 item 8 already requires: hostRefused carrying {member, code, listKept}
+  (their hostRefused declares no details shape) and hostUnreachable with no
+  details.
+
+  remove 0.3 item 8 is edited in place, errata-style: its "at another task"
+  clauses now name add 0.3 / renew 0.2's earlierRemovalRefused and stage, and
+  keep hostRefused for versions declaring no such code. No pre-existing
+  version's wire behaviour changes.
+
 ## 0.26.18 — 2026-10-18
 
 

package/dist/_shared/components.d.ts

@@ -723,6 +723,10 @@ export type Handle = string;
  * **Not a timestamp.** A time is host-asserted, unverifiable and useless for this: two roots a second apart are not evidence of anything, while two roots at one version are.
  */
 export type HeadVersion = number;
+/**
+ * The media types a directory image may have — those a `CardBlobRef` admits.
+ */
+export type ImageMediaType = "image/png" | "image/jpeg" | "image/webp" | "image/avif";
 /**
  * Who may ask the community to introduce them to this member. `anyone`: any active member who can find the entry. `groups`: only members who share a community group with them. `connections`: only members holding an attributed, in-force verified relationship with them. `off`: nobody. A refused introduction is never reported to its sender.
  */
@@ -4621,7 +4625,7 @@ export interface CapabilityScopeNone {
     scope: "none";
 }
 /**
- * A content-addressed image held in the community's blob store — an avatar or an `image` field. At most 256 KiB, images only, re-encoded by the community on upload (metadata stripped, dimensions capped) so its digest does not link the member across communities. `url` and `urlExpiresAt` appear only in a projection: a short-lived URL the community checks against the same projection, so a member-only image is never a public URL.
+ * A content-addressed image held in the community's blob store — an avatar or an `image` field. At most 256 KiB, images only, re-encoded by the community on upload (vtc/directory/images/upload: metadata stripped, dimensions capped) so its digest does not link the member across communities. A viewer reads the bytes with vtc/directory/images/get, which answers only where the same projection shows the value. `url` and `urlExpiresAt` MAY appear in a projection: a short-lived URL the community checks against the same projection, so a member-only image is never a public URL. A community that does not offer one leaves both out.
  */
 export interface CardBlobRef {
     /**
@@ -5801,6 +5805,7 @@ export interface DirectoryCard {
      * @maxItems 64
      */
     groupAudience?: string[];
+    externalCard?: ExternalCard;
     /**
      * Incremented on every accepted change to the card, by its subject or by an administrator's assertion.
      */
@@ -5814,6 +5819,36 @@ export interface DirectoryCard {
      */
     ext?: Ext;
 }
+/**
+ * The statement itself. Every member is generated from the community's configuration when the statement is read. `statementDigest` names this exact statement, so an applicant can record which one it was shown.
+ */
+export interface DirectoryDisclosure {
+    /**
+     * Every active field, base and community-defined, in display order. A base field the community has disabled is absent, which is how a reader learns it is not collected.
+     *
+     * @maxItems 128
+     */
+    fields: DisclosedField[];
+    newCard: NewCardDefaults;
+    /**
+     * The widest audience a member's membership identifier — the DID they joined with — can reach through the directory: the ceiling of the base field `did`, or `admins` where that field is disabled. `members` or `public` means a member may choose to show it that widely; a new card never shows it beyond `admins` (VTI-DIR-042). Administrators always see it.
+     */
+    membershipIdentifiers: Audience;
+    /**
+     * Whether administrators keep notes about members. Notes are never on a card and never reach another member; a member may ask for the notes about them.
+     */
+    adminNotes: boolean;
+    groups?: GroupDisclosure;
+    /**
+     * Whether a member may publish a card beyond the community: their `public` values, signed by them, offered through the community's trust registry. Always the member's own choice, and off on a new card. False where the community cannot publish external cards.
+     */
+    externalCards: boolean;
+    /**
+     * Digest over the RFC 8785 (JCS) canonicalization of this statement with the `statementDigest` member removed, as a multibase-encoded multihash (SHA-256 and base58btc RECOMMENDED). Changes exactly when what the statement says changes.
+     */
+    statementDigest: DigestMultibase;
+    ext?: Ext;
+}
 /**
  * One entry as a particular viewer sees it.
  */
@@ -5844,6 +5879,35 @@ export interface DirectoryRef {
      */
     entryId: DirectoryEntryId;
 }
+/**
+ * One active field of the community's directory, as an applicant needs to see it: what it is, who writes its value, the widest audience it may ever reach and the audience a new card gives it. Disabled and retired fields are not listed: no projection shows them.
+ */
+export interface DisclosedField {
+    key: FieldKey;
+    label: FieldLabel;
+    description?: FieldDescription;
+    type: FieldType;
+    /**
+     * Who writes the value. `admin` and `credential` matter most to an applicant: an `admin` field holds what the community asserts about the member, which the member reads and cannot change.
+     */
+    source: FieldSource;
+    /**
+     * The widest audience the field may ever reach, whatever the member chooses.
+     */
+    ceiling: Audience;
+    /**
+     * The audience a new card gives the field until its member chooses. Never wider than `ceiling`.
+     */
+    defaultVisibility: Audience;
+    /**
+     * Whether a member's search may match the field, within what the searcher may see.
+     */
+    searchable: boolean;
+    /**
+     * Whether members may filter on the field and see counts by its values. Absent: false.
+     */
+    facet?: boolean;
+}
 /**
  * The member's three discoverability decisions, made separately.
  */
@@ -6285,6 +6349,20 @@ export interface ExternalAccount {
     createdAt: string;
     updatedAt: string;
 }
+/**
+ * Where the member's external card stands. Present on a card exactly when `discoverability.external` is true. `published`: the community is serving the card the member signed, and its trust registry points to it. `awaitingSignature`: the member's `public` values have changed since they signed, so the community has withdrawn the card it was serving and serves none until the member signs the current values (vtc/directory/card/publish). The community never serves a card the member did not sign, and never one that differs from their current `public` values.
+ */
+export interface ExternalCard {
+    state: "published" | "awaitingSignature";
+    /**
+     * Present while `published`: digest of the card served, as vtc/directory/card/publish defines it.
+     */
+    cardDigest?: DigestMultibase;
+    /**
+     * Present while `published`: when the card now served was published.
+     */
+    publishedAt?: string;
+}
 /**
  * One displayed value, with where it comes from and how to render it.
  */
@@ -6583,6 +6661,15 @@ export interface GroupBinding {
     createdAt: string;
     createdBy?: string;
 }
+/**
+ * Present when the community has groups. A member of a group holds a credential, issued by the group's own identifier, that evidences their membership, and can present it outside the community — which is why an applicant is told.
+ */
+export interface GroupDisclosure {
+    /**
+     * How long each group membership credential is valid for, as an ISO 8601 duration in weeks, days, hours, minutes and seconds (`P30D`). It is renewed while the member stays in the group, and a credential already issued stays valid until it expires even after its holder leaves.
+     */
+    credentialValidity: string;
+}
 export interface GroupJoinRequest {
     requestId: JoinRequestId;
     groupId: GroupId;
@@ -7501,6 +7588,23 @@ export interface MonitorFilter {
      */
     failuresOnly?: boolean;
 }
+/**
+ * The discoverability a card has when the community creates it, before its member chooses. A new card is never published beyond the community (VTI-DIR-042), so there is no member for that here: `externalCards` says whether the member may turn it on.
+ */
+export interface NewCardDefaults {
+    /**
+     * The listing a new card starts with: the community's `defaultListing` (vtc/directory/fields/list). Every member may always choose `hidden`.
+     */
+    listing: Listing;
+    /**
+     * What a member's search may match, as the card's `discoverability.search`.
+     */
+    search: "byName" | "exactNickname" | "off";
+    /**
+     * From whom a new card accepts introductions. Absent where the community does not deliver introductions.
+     */
+    introductions?: Introductions;
+}
 /**
  * A community's offer of admission to a room it owns, as the member it is addressed to sees it.
  */
@@ -8012,6 +8116,14 @@ export interface PublicKeyCredentialRequestOptions {
     allowCredentials?: PublicKeyCredentialDescriptor[];
     userVerification?: "discouraged" | "preferred" | "required";
 }
+/**
+ * A member's external card: a JSContact `Card` (RFC 9553) holding exactly their values whose visibility is `public`, mapped as `JSContactCard` maps them, with the member's W3C Data Integrity `proof`. The community serves it as received and never signs, composes or edits it (VTI-REG-004 item 4).
+ *
+ * Carried as an open object, and deliberately so: the proof covers every member of the card, and a typed binding that kept only the members named here would drop the rest and break the signature. So this schema constrains none of its members, and a consumer MUST check them itself: `@type`, `version`, `uid` and `proof` are present; `@type` is `Card`; `version` is `1.0`; `uid` is `urn:vtc-directory:<EntryId>`; `proof` is a `DataIntegrityProof` with `cryptosuite` `eddsa-jcs-2022` or `ecdsa-jcs-2019`, `proofPurpose` `assertionMethod`, and a `verificationMethod` of the member's membership DID authorized for `assertionMethod`; and the proof verifies over the card without it, before any member is relied on.
+ */
+export interface PublishedCard {
+    [k: string]: unknown | undefined;
+}
 /**
  * The parameters exactly as they now appear in this community's join manifest, under vetting.ext. What an applicant and a vetter read.
  */