@openvtc/trust-tasks 0.28.13 → 0.28.15

package/src/_shared/components.ts

@@ -1678,6 +1678,10 @@ export type RecordConfidence = number;
  * **It counts the room, never the page.** The same rule `DataCommitment` states, and the same trap: a count scoped to what was returned is one a host satisfies by construction. So this is only comparable against a listing read to the end with **no** `prefix` and **no** `sinceVersion` — a filtered listing legitimately holds fewer, and a reader that compares one against this has found a discrepancy it created itself.
  */
 export type RecordCount = number;
+/**
+ * The instant the author made the edit that produced this version, RFC 3339 in UTC (`Z`). Set by the writer of every version after the first, and absent on the first, so that a reader seeing a record for the first time can tell whether it was ever edited — which `version` cannot say, since curation moves it too. Signed with the body on the sealed tiers. A reader shows a record carrying it as edited, and treats an implausible one as `SealedRecordBody` (*Edits*) says. Governed by `RoomProfile.recordMembers` like `writtenAt`. No host enforces or reads it.
+ */
+export type RecordEditedAt = string;
 /**
  * One thing a record cites in its support, discriminated by `kind`.
  *
@@ -1702,6 +1706,10 @@ export type RecordId = string;
  * The community's own identifier for one received notification, stable across the revisions that replace it. Opaque and compared for equality only; unguessable, because a read by a caller without the capability is refused and an enumerable identifier would turn the refusal into an oracle.
  */
 export type RecordId_VtcNotificationsV0_1 = string;
+/**
+ * What a reader shows a record as. Defined values: `note` — something kept in the room's library, titled or not, its `body` markdown; `message` — a turn in the room's conversation, its words in `body` as plain text; `reaction` — a short response to another record, its value in `body` (`SealedRecordBody`, *Reactions*). An open set, not an enumeration, so a new kind needs no new version of any schema: a reader MUST present a record whose kind it does not know as a note, and MUST NOT refuse a record for its kind. Absent means `note`, though a reader that keeps a conversation apart MAY show an untitled record without a kind as a message (*Untitled records*). A new version of a record MUST keep its kind. lowerCamelCase, at most 64 characters.
+ */
+export type RecordKind = string;
 /**
  * The path from one record's leaf to the room's `DataCommitment` — a Merkle inclusion proof, in the vocabulary this work already uses for it.
  *
@@ -1740,6 +1748,10 @@ export type RecordType = "authorization" | "recognition";
  * The instant after which the record's author no longer stands behind it as current. OPTIONAL; absent means the record does not expire. A reader hides a record whose `validUntil` has passed from default listings, search and recall, and shows it only on explicit request (`SealedRecordBody`, **Expiry**). No host enforces it.
  */
 export type RecordValidUntil = string;
+/**
+ * The instant the author wrote the record, RFC 3339 in UTC (`Z`). Set by the author and kept unchanged when the record is rewritten; an edit is marked by `editedAt`. OPTIONAL on a note; a `message` or `reaction` SHOULD carry it. The author's claim, not an attested time: a reader orders messages by it, compares it with the host's `createdAt`, and treats an implausible or backdated one as `SealedRecordBody` (*When it was written*) says. No host enforces or reads it.
+ */
+export type RecordWrittenAt = string;
 /**
  * What it takes to let a value LEAVE. Distinct from `Sensitivity`, which governs showing it to the holder.
  *
@@ -9587,6 +9599,8 @@ export interface FieldVisibility {
  * - check that the decrypted length equals the padded length, that every padding byte is zero, and, after removing the padding, that the plaintext matches `digest`.
  *
  * A reader **MUST** refuse a file that fails any check, and **MUST NOT** present it with a warning instead. A reader that streams **MUST NOT** treat the plaintext as received — save it under its final name, render it, or hand it to another component — until the digest has verified; it writes to a temporary destination and discards that destination on a mismatch.
+ *
+ * **An image's size and preview.** `width`, `height` and `preview` are OPTIONAL and advisory: they let a reader lay out an image, and show something, before it fetches and decrypts the blob. A reader that fetches the file checks them against the bytes — the decoded image's dimensions, and that the file is an image at all — and on a mismatch uses the bytes and discards them; it MUST NOT treat any of them as evidence about the file. On `attributed` and `private` rooms they are inside the sealed, signed body like the rest of the manifest, so the host learns nothing from them; on an `open` room they are in the clear, as everything there is, and a writer carries them only with `rooms/records/put/0.5` or later. A writer uses them only once the room's profile lists them in `recordMembers` (`RoomProfile`), as with the other members a reader that predates them refuses.
  */
 export interface FileManifest {
   /**
@@ -9626,6 +9640,27 @@ export interface FileManifest {
    * The file key itself, 32 bytes base64url without padding: present on an `open` room only, where there is no storage key to derive it from. Minted by the uploader from a cryptographically secure random source for this one file and never reused. MUST be absent on `attributed` and `private` rooms, where the key is derived and never stored.
    */
   fileKey?: string;
+  /**
+   * The image's width in pixels, as the uploader read it. Advisory. A writer sets `width` and `height` together or neither; a reader ignores one without the other. A reader checks it against the decoded image.
+   */
+  width?: number;
+  /**
+   * The image's height in pixels, as the uploader read it. Advisory. A writer sets `width` and `height` together or neither; a reader ignores one without the other. A reader checks it against the decoded image.
+   */
+  height?: number;
+  /**
+   * A small image standing in for the file until it is fetched: at most 8192 bytes before encoding, enough for a blurred thumbnail and small enough not to swell the record every listing reader opens. A reader renders it only as a raster image it decodes itself — never as SVG or any other type that can carry active content, never as a link, never fetching anything — and replaces it with the file once fetched. It is the uploader's rendering of the file, not a digest of it: a reader MUST NOT present it as the file's contents.
+   */
+  preview?: {
+    /**
+     * The preview's own media type. Raster types only.
+     */
+    mediaType: "image/jpeg" | "image/png" | "image/webp";
+    /**
+     * The preview's bytes, base64url without padding: at most 8192 bytes decoded.
+     */
+    data: string;
+  };
 }
 /**
  * A person's account on one forge. `id` is authoritative; `login` is for display only, because logins can be renamed and re-registered.
@@ -11478,6 +11513,46 @@ export interface NetworkMembership {
   joinedAt?: string;
   updatedAt: string;
 }
+export interface NetworkMembership_VtcV0_7 {
+  /**
+   * The network's DID.
+   */
+  network: string;
+  /**
+   * Where the network's API is reached: the base its `/.well-known/vtn` profile is served under.
+   */
+  url: string;
+  /**
+   * The network's name, as its profile gives it.
+   */
+  name?: string;
+  /**
+   * `acknowledged`: the community is a member — it signed the acknowledgement of the network's grant. `repudiated`: the community rejected the network's listing of it. `departed`: the community left, by repudiating the grant.
+   */
+  state: "acknowledged" | "repudiated" | "departed";
+  /**
+   * The network's listing credential naming the community, as the community verified it.
+   */
+  listing: {};
+  /**
+   * The network's membership grant (VMC), once the community acknowledged.
+   */
+  grant?: {};
+  /**
+   * The community's acknowledgement (VMC carrying the grant's digest).
+   */
+  acknowledgement?: {};
+  /**
+   * The community's repudiation (VSC) of the listing, or — on departure — of the grant.
+   */
+  repudiation?: {};
+  /**
+   * @maxItems 64
+   */
+  groups: RegisteredGroup_VtcV0_7[];
+  joinedAt?: string;
+  updatedAt: string;
+}
 /**
  * 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.
  */
@@ -12757,6 +12832,63 @@ export interface RecordMetadataV2 {
    */
   blobs?: [BlobRef];
 }
+/**
+ * What `rooms/records/list/0.6` returns, and `rooms/keys/browse/0.4` passes through: `RecordMetadataV2` plus `kind` on an `open` room, `createdAt` and `bodyStoredAt` on every tier and `createdBy` on `open` and `attributed`. A separate definition, not a change to `RecordMetadataV2`, so that `rooms/records/list/0.2` to `0.5` keep the exact shape they published. Never the body.
+ */
+export interface RecordMetadataV3 {
+  /**
+   * The record's key within the room. On `attributed` and `private` rooms this MUST be opaque — a random identifier, never a descriptive slug. A key reading `decision/acquire-northwind` defeats the encryption sitting beside it; structured naming belongs inside the sealed body.
+   */
+  key: string;
+  /**
+   * Server-assigned, monotonic per room.
+   */
+  version: number;
+  /**
+   * The epoch the record was sealed under. Absent on an `open` room.
+   */
+  epoch?: number;
+  /**
+   * Curation state. `retracted` is a tombstone: the body is gone, the key and version remain so incremental sync converges and the audit chain stays intact.
+   */
+  status?: "active" | "deprecated" | "retracted";
+  updatedAt: string;
+  /**
+   * When the host stored the record's first version: RFC 3339, set by the host, never by a writer. Host metadata, not body, so it is served on every tier. A host MUST set it when it stores a record's first version and MUST keep it unchanged for as long as it holds the record — across every later version, every curation, retraction included, and a member's withdrawal — so that it says when the room received the record, which `updatedAt` cannot once the record has been edited or curated. A host that stored a record before it kept `createdAt` MUST omit it for that record rather than supply a guess such as the earliest `updatedAt` it still holds; a reader then falls back to `updatedAt` (`SealedRecordBody`, *When it was written*). Readers order messages and judge `writtenAt` by it.
+   */
+  createdAt?: string;
+  /**
+   * The author of the record's first version, as the host recorded it when it stored that version: the DID it authenticated for the write on an `open` room, and on an `attributed` one the author it records for every write. Set by the host, never by a writer, and kept unchanged for as long as it holds the record — across every later version, every curation and a retraction — like `createdAt`. Served on `open` and `attributed` rooms only: a `private` room's host records no author, and MUST NOT serve this. Omitted for a record stored before the host kept it, rather than guessed. Readers use it to apply the rules about a rewrite by another member to a record they see for the first time (`SealedRecordBody`, *The record's original author*).
+   */
+  createdBy?: string;
+  /**
+   * When the host stored the body the record's current version carries: the time of the `rooms/records/put` that wrote that body. Set by the host, never by a writer. A curation (`rooms/records/curate`), and anything else that moves the version without writing a new author-signed body, leaves it unchanged; for the first version it equals `createdAt`. The host knows which task wrote each version, so it is served on every tier, `private` included, and says nothing about the body. Readers verify the current version's proof against the author's DID document as it stood at this time (`SealedRecordBody`, *Which DID document*). Omitted for a version stored before the host kept it, rather than guessed.
+   */
+  bodyStoredAt?: string;
+  /**
+   * Present only on an `open` room; sealed with the body otherwise.
+   */
+  title?: string;
+  /**
+   * Present only on an `open` room; sealed with the body otherwise.
+   */
+  description?: string;
+  /**
+   * The member who wrote it. Present on `open` and `attributed`; on `private` the author is inside the sealed body, where only members can read it.
+   */
+  author?: string;
+  /**
+   * The stored blobs this record names, as rooms/records/put/0.2 wrote them. Absent when it names none, when it is retracted, and on records written by put 0.1. Cleartext on every tier, as on the write, so a listing discloses which records carry files, never anything about the files beyond the blobs' sizes.
+   *
+   * @minItems 1
+   * @maxItems 1
+   */
+  blobs?: [BlobRef];
+  /**
+   * The record's `kind` as its current version's `cleartext` carries it. Present only on an `open` room, where the host reads the body anyway; on `attributed` and `private` rooms `kind` is sealed with the body and a host MUST NOT serve it, nor anything from which it could be inferred. Absent on a record that carries none — which a reader reads as `note` — and on a tombstone, which keeps nothing of its body.
+   */
+  kind?: RecordKind;
+}
 /**
  * The mark a prune leaves: **that** records were removed, when, and how many — never which, and never anything they said.
  *
@@ -12799,6 +12931,19 @@ export interface RecordPrune_RoomsV0_2 {
    */
   removed: number;
 }
+/**
+ * Names another record of the same room: the record a reply answers or a reaction responds to. Never a record of another room — a citation that crosses rooms is `RecordEvidenceRecord`. A reader resolves it only against records it can already list or read in this room, and MUST NOT fetch anything else because of it. It MUST NOT name a record of kind `reaction`.
+ */
+export interface RecordReference {
+  /**
+   * The record's key, as in `rooms/records/put`. Opaque on the sealed tiers, like every key there.
+   */
+  key: string;
+  /**
+   * The version of the record the author was answering. OPTIONAL. A reader SHOULD say that the target has changed since only when its content has, never because its version moved: curation moves a record's version without touching its content (`SealedRecordBody`, *Whether the target has changed*).
+   */
+  version?: number;
+}
 /**
  * How long a room keeps its records, by age: the room's **record retention**. Records older than it states become **eligible** to be removed by `rooms/records/prune`; nothing is removed until a holder of `admin` asks for a prune, and nothing a prune removes can be brought back.
  *
@@ -12919,6 +13064,33 @@ export interface RegisteredGroup {
   acceptance: {};
   registeredAt: string;
 }
+export interface RegisteredGroup_VtcV0_7 {
+  /**
+   * A role the network defines, e.g. `admins`: lowercase letters, digits, `-` and `_`.
+   */
+  role: string;
+  /**
+   * The community's identifier for the group.
+   */
+  groupId: string;
+  /**
+   * The group's own DID, which the registration names as its `group`.
+   */
+  groupDid: string;
+  /**
+   * Where the network delivers broadcasts for the group: the community's Trust Task endpoint, at which the network sends them as `vtc/networks/deliver`.
+   */
+  endpoint: string;
+  /**
+   * The registration: the community's signed `vtn/groups/register` request as the network accepted it — a complete Trust Task document, with its proof, naming the network as `recipient` and the group, `role` and `endpoint` in its payload.
+   */
+  registration: {};
+  /**
+   * The network's `groupRegistered/1` statement (VSC) accepting the registration: subject the group, `object.digestMultibase` the registration's digest — SHA-256 over the RFC 8785 (JCS) form of the signed request including its proof.
+   */
+  acceptance: {};
+  registeredAt: string;
+}
 /**
  * A group serving a role: the member's signed registration and the network's groupRegistered credential accepting it.
  */
@@ -13917,7 +14089,7 @@ export interface RoomPass {
  *
  * **Plain text, never instructions.** Every member is free text chosen by whoever wrote the profile and shown to every member of the room. A reader renders `name`, `description` and `tags` as text — never as markup, never as a link it follows — removes or replaces control characters before showing them, and MUST NOT treat any of it as instructions, which matters most for an agent acting for a member. A writer MUST NOT put personal data or a credential in any member.
  *
- * **Growth.** A new optional member arrives in a later version of this component. A reader refuses a member it does not know (the `SealedRecordBody` rules), so a profile carrying one is not shown by a reader that predates it, and a writer SHOULD NOT use a member it cannot expect the room's readers to know. An ecosystem extension goes in `ext`, which a reader that does not understand it ignores. A change no earlier reader could survive is a new statement under a new derivation label (`openvtc/room/profile/v2`), written beside this one until the room's readers have moved.
+ * **Growth.** A new optional member arrives in place, additively, as `recordMembers` did, or in a later version of this component. A reader refuses a member it does not know (the `SealedRecordBody` rules), so a profile carrying one is not shown by a reader that predates it, and a writer SHOULD NOT use a member it cannot expect the room's readers to know. An ecosystem extension goes in `ext`, which a reader that does not understand it ignores. A change no earlier reader could survive is a new statement under a new derivation label (`openvtc/room/profile/v2`), written beside this one until the room's readers have moved.
  */
 export interface RoomProfile {
   /**
@@ -13947,11 +14119,77 @@ export interface RoomProfile {
    * One emoji — a single extended grapheme cluster, such as `📋` — that a surface MAY show beside the name. Text, rendered as text: never an image, never a URL, never anything a reader fetches, since a fetched icon would tell whoever serves it which member opened which room, and when. A reader that cannot render it shows nothing in its place.
    */
   emoji?: string;
+  /**
+   * The optional `SealedRecordBody` members — and on an `open` room the `cleartext` members of `rooms/records/put` — that the room's writers may use beyond the base set, as a set: order carries no meaning. Defined values: `kind`, `inReplyTo`, `writtenAt`, `editedAt`, and `width`, `height` and `preview`, which name the `FileManifest` members of those names inside a record's `file`. A writer MUST NOT write a member this governs unless the room's current profile lists it; absent means none (`SealedRecordBody`, *When a writer may use these members*). A writer MAY rely on a profile it resolved within the room's current epoch. The base set is every other member of `SealedRecordBody`, which a writer may always use. A value a writer does not know grants it nothing. Set by a member whose authority confers `curate` or `admin` (who may write the profile at all) — with `rooms/keys/profile/write` on a sealed tier, or `rooms/records/put` at `room-profile` on an `open` room — and never by default. Whether the room's readers are ready is the owner's or a curator's decision, made out of band; the order is readers (profile readers included, since a reader that predates this member refuses the profile carrying it), then the owner's key holder, which re-writes the profile after a removal and so MUST accept this member before any profile carries it, then on the sealed tiers the key holders that seal for writers, then the profile (`SealedRecordBody`, *Turning them on*). Listing a member never obliges a writer to use it, and removing one stops writers using it by the room's next epoch at the latest; records already written keep it.
+   *
+   * @minItems 1
+   * @maxItems 32
+   */
+  recordMembers?: [string, ...string[]];
   /**
    * Ecosystem-defined extension members per SPEC.md §4.5.1. A reader ignores what it does not understand.
    */
   ext?: Ext;
 }
+/**
+ * The room's profile as a record carries it: the `roomProfile` member of a `SealedRecordBody`, signed by its author like every record body, with the evidence a reader needs to decide whether the author was entitled to say it.
+ *
+ * **Where it is: one record per epoch, at a key only members can compute.** On an `attributed` or `private` room the profile written under epoch `E` is stored at the record key
+ *
+ *     profile_key(E) = base64url-nopad(HKDF-SHA256(ikm = storage_key(E), salt = "", info = "openvtc/room/profile/v1" || roomId || u64be(E), L = 16))
+ *
+ * where `storage_key(E)` is the room's storage key for epoch `E` — the one records sealed under `E` are sealed with, as for a file key (`blobs.schema.json`) — `roomId` is its UTF-8 bytes exactly as on the wire, `u64be` is as `blobs.schema.json` defines it, and `salt` is the empty string. The result is 22 characters, the shape of any random record key, so to the host it is one more opaque record and the family's rule that a sealed room's keys are opaque (`RecordMetadata.key`) holds for it as for any other. A member finds it knowing nothing but the room and the epoch, which is all a member who has just joined has. Since `storage_key(E)` never leaves a member's key holder, it is the key holder that computes it (`rooms/keys/profile/read`, `rooms/keys/profile/write`).
+ *
+ * On an `open` room, which has no storage key and hides nothing from its host, the profile is the record at the fixed key `room-profile`, and its `cleartext.body` is the UTF-8 JSON of the signed `SealedRecordBody` — the object the sealed tiers seal — so that a reader verifies one thing on every tier. A writer SHOULD also set `cleartext.title` to the profile's `name`.
+ *
+ * The record is written with `rooms/records/put` like any other, so a host enforces only `write` on it and cannot tell it from any other record. Whether its author could say what the room is called is therefore decided by readers, from what the statement carries.
+ *
+ * **Who may write it.** The author's `authority` must confer `curate` or `admin` at the room's scope: `admin` because naming the room is part of governing it, `curate` because it is the standing to judge what the room's shared knowledge is, and a room's name and purpose are the first thing a member reads of it. `write` alone never suffices: every member able to add a record could otherwise rename the room for everyone.
+ *
+ * **Accepting one.** A reader resolving a room's profile MUST apply to the record at the profile's location the `SealedRecordBody` reading rules (1)–(4) — on an `open` room to the body parsed from `cleartext.body`, with rule (4) against the author the host recorded — and MUST also refuse it unless:
+ *   1. it carries `roomProfile` and none of `title`, `description`, `body`, `tags` and `file`;
+ *   2. on a sealed tier, the epoch it was sealed under is `E`, the epoch whose key located it;
+ *   3. `authority` verifies as a host verifies a chain (`AuthorityPresentation`): at most 8 links, leaf first; every link's `proof` made with a key its own `issuer` lists for `assertionMethod`; the last link issued by `roomId`; no link widening what its parent conferred, in actions, scope or validity; the whole conferring `curate` or `admin` at this room's scope; the leaf's subject equal to the body's `author`, which stands in for a host's presenter binding; and every link valid at `issuedAt` rather than at the moment of reading. The reader MUST NOT dereference a link it was not given;
+ *   4. `issuedAt` is no later than five minutes after, and no earlier than one hour before, the `updatedAt` the host reports for the record;
+ *   5. where the reader holds a `RevocationList` for the room, verified as a host verifies one, no link of `authority` is revoked by an entry whose `revokedAt` is at or before `issuedAt`.
+ * A reader MUST ignore a profile that fails any of these, as though it were absent — and, unlike an ordinary record, SHOULD say that it did, naming the author where the tier discloses one: a profile written by somebody without the standing to write it is somebody trying to rename the room.
+ *
+ * **Revocation is not retroactive.** A profile written while its author held the standing to write it stays valid after that author is removed, their grant lapses, or a `room` entry resets every credential. The statement was made with authority; withdrawing the authority withdraws what the author may do next, not what they already did, and the alternative — every member's view of the room's name going blank when whoever named it is removed — is something nobody asked for. It is not a back door. A removed party cannot write afterwards, because a host refuses every presentation a list it holds revokes; a statement back-dated into a grant its author no longer holds fails item 4 unless the host colludes; and removal advances the room's epoch, after which the owner's key holder re-writes the profile under the new epoch as the owner (`rooms/keys/profile/write`), so on the ordinary path the removed author's statement is superseded by the same act that removes them.
+ *
+ * **Choosing among several.** There is at most one profile per epoch, because there is one record per key. A reader at epoch `C` takes the profile at `profile_key(C)`; if there is none, or it fails the checks above, it tries `C - 1`, and so on down to the earliest epoch it can derive a storage key for, and takes the first one it accepts — the newest. It MUST NOT prefer an older profile to a newer one it accepts. A record at a profile location that is `retracted` is a profile deliberately cleared — retraction is `rooms/records/curate`, for which a host requires `curate` — and the walk stops there: the room has no profile. A profile accepted below `C` is **stale**: written before the room's latest epoch advance and not re-written since. A member of a `fromJoin` room cannot walk back at all, which is why the profile is re-written at every advance.
+ *
+ * **Size.** A writer SHOULD set `padding` so that the UTF-8 JSON of the signed body is a multiple of 1024 bytes, so that a host comparing ciphertext lengths learns nothing about how long the name or the description is. A reader ignores `padding`.
+ */
+export interface RoomProfileStatement {
+  profile: RoomProfile;
+  /**
+   * When the author made this statement: signed with it, the instant `authority` is evaluated at, and bounded against the host's `updatedAt` for the record so that it cannot be back-dated into a grant the author no longer holds.
+   */
+  issuedAt: string;
+  /**
+   * The author's authority chain, LEAF FIRST, ending with a credential the room issued, conferring `curate` or `admin` on `author` at this room's scope. The credentials themselves, never a zero-knowledge presentation: a reader is a member, who already sees `author`. Carried in the statement because readers, not the host, decide whether its author could say it, and a reader fetches no link it was not given. Capped at 8, as a presentation is.
+   *
+   * @minItems 1
+   * @maxItems 8
+   */
+  authority:
+    | [string]
+    | [string, string]
+    | [string, string, string]
+    | [string, string, string, string]
+    | [string, string, string, string, string]
+    | [string, string, string, string, string, string]
+    | [string, string, string, string, string, string, string]
+    | [string, string, string, string, string, string, string, string];
+  /**
+   * Ignored by readers; see **Size**. A writer SHOULD use spaces.
+   */
+  padding?: string;
+  /**
+   * Ecosystem-defined extension members per SPEC.md §4.5.1.
+   */
+  ext?: Ext;
+}
 /**
  * Withdraws every credential whose `validFrom` is earlier than `revokedAt`, whoever holds it.
  */
@@ -14192,6 +14430,119 @@ export interface SealedRecord {
    */
   version?: number;
 }
+/**
+ * The plaintext inside `SealedRecord.ciphertext` on an `attributed` or `private` room, as JSON, signed by its author. Client to client: no host task carries it, because a host receives only ciphertext. Defined so that every member's client writes and reads the same thing.
+ *
+ * **Producing.** A writer builds the object without `proof`, signs it with a W3C Data Integrity proof whose `verificationMethod` is a key of `author` and whose `proofPurpose` is `assertionMethod`, and seals the result (its UTF-8 JSON bytes) under the AEAD that binds the same `roomId`, `key`, `version` and epoch. A writer MUST support `eddsa-jcs-2022`; `ecdsa-jcs-2019` MAY be used for a hardware-backed signer.
+ *
+ * **Reading.** After opening a record a reader MUST, before showing any member of it or trusting its `file`: (1) parse it as this object and refuse an unknown member; (2) verify `proof` against `author`'s DID document, for `assertionMethod`, as that document stood when the host stored this version's body (*Which DID document*); (3) check that `roomId`, `key` and `version` equal the location the record was sealed at — the record's `roomId` and `key`, and `sealed.version` where present, else the record's `version` (`SealedRecord`); (4) on an `attributed` room, check that `author` equals the `author` the host recorded for the record. A reader MUST refuse a record that fails any of these, and MUST NOT show it with a warning instead; the exceptions, *Which DID document* and *An author whose DID does not resolve*, show a placeholder and none of the record.
+ *
+ * **Which DID document.** Rule (2) verifies the proof of the version the reader reads against `author`'s DID document **as it stood at the host's `bodyStoredAt`** for that version (`RecordMetadataV3`) — when the host stored the body that version carries, which an edit moves and a curation does not. Not at the proof's own `created`, which the author chose, and not only against the document as it is now. A key the author rotated away after `bodyStoredAt` still verifies the version; a key rotated away before it does not. Where the author's DID method keeps its history — `did:webvh`, resolved with `versionTime` — a reader resolves the document as of `bodyStoredAt`, and a proof that fails against it is refused like any other. Where the method keeps no history, a reader can only use the current document, and a proof that fails against it may be a forgery or may be a key rotated away since the version was written, which the reader cannot tell apart: it MUST show such a record as the placeholder below — its author cannot be verified, nothing of it shown — and MUST NOT drop it silently. Where the reader has no `bodyStoredAt` — a host that predates it, or a read that does not carry it — it uses the current document, and treats a proof that fails there the same way.
+ *
+ * **A record curated before `sealed.version` existed.** A host that predates `SealedRecord.version` moved such a record's version without recording the one it was sealed at, so it opens at neither. Where a record carries no `sealed.version` and does not open at its own `version`, a reader MAY try each earlier version in turn, newest first, and use the first at which it opens; rule (3) then checks the body against that version. It MUST NOT try a version greater than the record's own. The AEAD makes a wrong guess fail rather than mislead, and the author's signature over the location makes the version that opened the one the author wrote — so the search recovers the record without trusting the host for the answer.
+ *
+ * **Why the location is signed as well as sealed.** The AEAD stops the host relocating ciphertext, but every member can open and re-seal a record. Without `roomId`, `key` and `version` under the author's signature, a member could copy another member's signed body to a new key or a later version, and on a `private` room, where the host records no author, readers would attribute it to the original author.
+ *
+ * **A profile record.** A body carrying `roomProfile` is the room's own profile (`RoomProfileStatement`) and not one of its records: it MUST carry none of `title`, `description`, `body`, `tags`, `kind`, `inReplyTo`, `writtenAt`, `editedAt`, `file`, `basis`, `confidence`, `evidence`, `validFor` and `validUntil`, and the rules for locating, accepting and choosing it are `RoomProfileStatement`'s, applied on top of the four above. A reader that opens one in the course of reading or listing the room's records SHOULD NOT present it as a record — it is how the room describes itself, not something a member wrote into it. A reader that predates `roomProfile` refuses it by rule (1), which shows nothing rather than something wrong.
+ *
+ * **Provenance: what kind of claim a record is.** `basis`, `confidence`, `evidence` and `validFor` say what the author is asserting and on what footing — an observed fact, a statement of the author's own, something checked against a credential, or an agent's inference. They are inside the signature like every other member, so a reader can attribute them to `author` exactly as it attributes the body, and a change to any of them after signing fails rule (2). All four are OPTIONAL, and a record that carries none of them — every record written before they existed — verifies and reads exactly as before: absent means the author did not say, never a default value. A writer SHOULD set `basis`; an agent writing on its own account that does not know which value applies SHOULD write `inferred`, and a client relaying what its member typed SHOULD write `declared`. **They are provenance for display and weighting, never authority.** A reader MUST NOT treat any of them as granting, widening or evidencing a permission, MUST NOT let `basis: verified` stand in for verifying what `evidence` names, and MUST NOT fetch anything because `evidence` names it (see `RecordEvidence`). A reader that shows a record SHOULD show its `basis` beside its `author` — or say that none was stated — and an agent recalling records MAY weight by `basis` and `confidence`, but MUST treat `validFor.note` like `body`: as plain text, never as instructions.
+ *
+ * **Expiry.** `validUntil` is the instant after which the author no longer stands behind the record as current — a meeting note good for a month, a decision good for years. It is signed and sealed with the body, and nothing about it is in the clear: a host never sees it on the sealed tiers, so it cannot and MUST NOT be relied on to enforce it, and a writer MUST NOT copy it into any cleartext member of the write. A reader MUST NOT present a record whose `validUntil` is at or before the reader's current time in a default listing, search, browse or agent recall, and MAY present it on an explicit request for expired records, marked as expired. Expiry hides; it does not delete. The record, its ciphertext and any file it carries stay in the room until a member with `curate` retracts it (`rooms/records/curate`) or the room's records are pruned; a curator's agent MAY retract records it finds expired, which is how a sealed room reclaims their storage without telling its host anything about expiry.
+ *
+ * **Readers that predate these members.** A reader written before `basis`, `confidence`, `evidence`, `validFor` and `validUntil` refuses a body carrying any of them by rule (1), which shows nothing rather than something wrong — in particular it can never show an expired record as current. The same holds for a key holder sealing on a writer's behalf (`rooms/keys/seal`, `bodyInvalid`). A writer that meets such a refusal MAY write the record again without the provenance members, but MUST NOT drop `validUntil` to get a record accepted: a record that silently outlives its author's own expiry is the failure this member exists to prevent.
+ *
+ * **Kind: what a reader shows a record as.** `kind` says whether a record is a note — something kept in the room's library, titled or not — a message — a turn in the room's conversation — or a reaction to another record (`RecordKind`). It is inside the signature like every other member. Absent means `note`, so every record written before `kind` existed reads as the note it always was. The set is open: a reader MUST present a record whose `kind` it does not know as a note, and MUST NOT refuse it for its `kind`. A `message` carries its words in `body` and SHOULD carry no `title`. A reader that keeps a conversation apart from a library SHOULD show messages in the first and notes in the second, and MAY show both together. A reader MUST NOT treat `kind` as authority: it describes the record and confers nothing.
+ *
+ * **Untitled records.** A reader that keeps a conversation apart from a library MAY treat a record with no `kind` and no `title` as a message — it is how a writer that may not yet use `kind` writes one (*When a writer may use these members*) — and a reader that does so shows such records and records of `kind: message` in the same conversation, ordered together. Where it shows such a record as a message, it renders its `body` as plain text, as it renders a `message`'s; where it shows it as a note, it renders markdown (*What `body` is*).
+ *
+ * **What `body` is.** On a `message`, `body` is plain text: a reader MUST NOT render it as markup — not as markdown, not as HTML, not as a link it follows — and shows its characters as written. A reader never follows a URL in a record by itself; it MAY offer to open one only after the member explicitly asks to and confirms. On a `reaction` it is the reaction's value (*A reaction's value*), plain text likewise. On a `note`, and on a record of a kind the reader does not know, which it shows as a note, it is markdown, rendered inert. On a record with no `kind` and no `title` it follows how the reader shows it: plain text where it is shown as a message (*Untitled records*), markdown where it is shown as a note. On a record carrying `file` it is also the file's caption (*A file's caption*), plain text or markdown by the same rule; a `message` carrying `file` with an empty `body` is a photo or a file sent with no caption.
+ *
+ * **When it was written.** `writtenAt` is the instant the author wrote the record (`RecordWrittenAt`), in UTC, signed with the body. It is OPTIONAL on a note; a `message` or a `reaction` SHOULD carry it. **It does not move when the record is edited:** a writer rewriting a record MUST carry the `writtenAt` of the version it rewrites, unchanged; what marks an edit is `editedAt` (*Edits*). A reader orders a room's messages by `writtenAt`, then by `key` where two are equal; a message without one is ordered by the host's `createdAt` for it (`RecordMetadataV3`), which stands in for it, else by its `updatedAt`. A reader MAY instead order a conversation by `createdAt` throughout — the order in which the room received its records — rather than by `writtenAt`; the rules below about an implausible or backdated `writtenAt` still say what it shows. **The host's times.** `createdAt` is when the host stored the record's first version, and neither an edit nor a curation moves it; `updatedAt` is when the version the reader reads was stored, and both move it. So `writtenAt`, which is also kept across edits and curation, is compared with `createdAt`: against `updatedAt` an edit made a day later, or a pin, would read as a record claiming to be older than it is. Where the reader has no `createdAt` — a host that predates it, or a listing that does not carry it — it falls back to `updatedAt` as stated below. **It is the author's claim, not a time anyone attests.** A reader MUST treat as implausible a `writtenAt` later than the host's `createdAt` for the record, or, where it has none, later than the `updatedAt` for the version it reads, or, where it has neither, later than the instant it read the record — in each case by more than five minutes, for clock skew — and a rewrite whose `writtenAt` differs from the version it rewrote, where the reader holds that version. A reader orders an implausible record by `createdAt` (else by `updatedAt`, else by the instant it read it), and MUST NOT show the claimed time as when it was written. **Backdating.** A `writtenAt` more than 24 hours before the host's `createdAt` for the record claims to have been written well before the room received it. A reader MUST order such a record by `createdAt`, not by `writtenAt`, and MUST show that it arrived later than it claims — a record may be written offline and sent later, but a member must not be able to place a message silently in the room's past. Within 24 hours a reader MAY say how long after writing the room received it. Where the reader has no `createdAt`, a `writtenAt` long before `updatedAt` is not by itself implausible, since an edit or a curation moves `updatedAt`, and a reader MAY say how long after writing the room received it. Like every member, it confers nothing.
+ *
+ * **Replies.** `inReplyTo` names the record this one answers — another record of the same room, by `key`, and OPTIONALLY the `version` the author was answering (`RecordReference`). Any kind may carry it: a message may answer a note, and a note a message. It is signed, so a reader attributes the reply's target to `author` as it attributes the body. A reader resolves it only against records it can already list or read in this room with the authority it holds, and MUST NOT fetch anything else because of it. Where the target cannot be read — never written, withdrawn (*Withdrawing a message*), retracted, pruned, expired, sealed under an epoch the reader cannot open, or failing the reading rules above — the reader MUST still show the reply, marked as answering a record that is not available, and MUST NOT show anything of a target it could not verify.
+ *
+ * **Whether the target has changed.** Where `version` is present, a reader that shows the target SHOULD say that it has changed since only when the target's **content** differs from its content at that version — never because its `version` moved, which curation also does (`rooms/records/curate`). A record's content is every member of its body except `proof`, its location (`roomId`, `key` and `version`) and `editedAt`: on the sealed tiers the signed `SealedRecordBody`, on an `open` room the `cleartext` of `rooms/records/put`. Curation sets only a record's standing — its `status` and pinning, which are outside the body on every tier — so it never changes content. On a sealed tier a target whose body was written at the version the reply names — the body's own `version`, served as `sealed.version` once the record is curated — is unchanged, however far the record's own version has moved. Where the body was written at a later version, the reader compares the two contents if it holds the named version; if it does not, it MAY say the target was edited when the target carries an `editedAt` later than the reply's `writtenAt`, and otherwise says nothing.
+ *
+ * **Nothing answers a reaction.** A writer MUST NOT name a record of kind `reaction` in `inReplyTo`, whatever the kind of the record it writes: a reaction is not answered or reacted to. A reader that reads the target of an `inReplyTo` and finds a `reaction` MUST ignore the record naming it — show it nowhere, count it as no reaction — and refuses that record alone, never the room's others. This is a reader's rule. No host enforces it, and on the sealed tiers none could: a host never sees `kind`.
+ *
+ * **Reactions.** A record of kind `reaction` is a short response to another record: its target in `inReplyTo`, which it MUST carry, and its value in `body` — an emoji or a few words (*A reaction's value*). It SHOULD carry no `title`, `description`, `tags` or `file`. A reader MUST NOT show a reaction as a note or a message; it SHOULD show the values beside the target. A reader shows no reaction whose target is not available, and MUST NOT show a reaction that lacks `inReplyTo` or whose value is longer than 64 code points or holds a line terminator; it refuses that record alone, never the room's others. Like every record on a sealed tier, a reaction's key is opaque: a writer MUST NOT encode its target, its value or its `kind` in the key.
+ *
+ * **A reaction's value.** A reaction's value is its `body` normalised to Unicode Normalization Form C (NFC) with every U+FE0E and U+FE0F (variation selectors 15 and 16) then removed, so that `❤` and `❤️` are one value. A reader and a writer apply that normalisation before both the length check and any comparison. The value is at most 64 Unicode code points, counted after normalisation, and is one line: it holds no line terminator (U+000A, U+000B, U+000C, U+000D, U+0085, U+2028 or U+2029). A value that is empty, or holds only White_Space characters, is empty, and a version whose value is empty withdraws the reaction. Two values are the same when their normalised forms are equal code point for code point. The normal form is for measuring and comparing only: a reader MAY show a value in its fully qualified form, with U+FE0F where an emoji takes it.
+ *
+ * **Counting reactions.** One reaction per author, value and target: of the reactions whose `inReplyTo.key` names the same record, those with the same `author` and the same value count once, however many records carry them; one author's different values are different reactions. A new version of a reaction record with a different non-empty value changes that author's reaction: the earlier value no longer counts for the record, and the new one does. A writer reacting with a value it already holds a reaction record for, on the same target, SHOULD write a new version of that record — the same key — rather than a new one, so that a retry after a lost response leaves one record and not two. A reaction is withdrawn by its author writing a new version of the same reaction record with an empty value, and a reader counts nothing for a current version whose value is empty. **Only the reaction's author withdraws it:** an empty version counts as a withdrawal only when its `author` is the `author` of the version it replaces; a reader that holds an earlier version by another author MUST NOT count the empty one as withdrawing that author's reaction, and goes on counting the earlier version. Since every record carrying the same author, value and target counts, a writer withdrawing a reaction MUST withdraw every reaction record its author holds with that value and target.
+ *
+ * **Removed members.** A reaction counts for as long as its record is current, whether or not its author is still a member: a removed member's reactions keep counting until a member with `curate` retracts them (`rooms/records/curate`). A member who returns under a new DID is a different author, and their reactions count beside the ones their earlier DID left, not as the same person's.
+ *
+ * **Edits.** A record is rewritten by writing a new version under the same key (`rooms/records/put`), and that is how a message or a note is edited. The writer keeps `writtenAt` (*When it was written*) and, where the room's profile lists it, sets `editedAt` (`RecordEditedAt`) to the instant it made the edit; the first version of a record MUST NOT carry `editedAt`. A reader shows a record as edited when the version it shows carries `editedAt`, and MUST NOT infer an edit from `version`, which curation also moves. `editedAt` is the author's claim, as `writtenAt` is: a reader treats one earlier than the record's `writtenAt`, or later than the host's `updatedAt` for the version by more than five minutes, as implausible, and then shows that the record was edited but not when. The new version is a whole body, signed by whoever wrote it. A reader showing a version whose `author` differs from the version it last showed for that key MUST show the new author, and MUST NOT present it as an edit by the earlier one.
+ *
+ * **What a new version keeps.** A new version MUST keep the `kind` of the version it rewrites, absent included, and a new version of a reaction MUST keep its `inReplyTo`. A reader that holds an earlier version of a record and reads a later one that changes either MUST refuse that version: it MUST NOT show it as the record, nor count it as a reaction, and it refuses that version alone, never the room's others. Without this a member with `write` could rewrite another member's message as a reaction, and every reply to it would disappear (*Nothing answers a reaction*), or move another member's reaction to a record they never reacted to. A reader that has never read an earlier version has nothing to compare. On an `open` room a host MAY refuse a new version of a message or a reaction by anyone but its original author (`rooms/records/put`, Host item 15); on the sealed tiers no host can, since it never sees `kind`, and these reader rules are the only defence (`rooms/records/put`, *Security & Privacy*).
+ *
+ * **The record's original author.** Several rules turn on whether a new version comes from the record's own author. A reader that holds an earlier version compares with it. Where a listing or a read gives the host's `createdBy` (`RecordMetadataV3`) — the author of the record's first version, recorded by the host on `open` and `attributed` rooms — a reader that sees the record for the first time uses it as the record's author for those rules: a current version whose `author` is not `createdBy` is shown as a rewrite by that author and never as the original author's edit (*Edits*); an empty version of a message or a reaction by anyone but `createdBy` is not a withdrawal (*Withdrawing a message*, *Counting reactions*), and such a reaction is counted for its own author, not for `createdBy`. `createdBy` is the host's word: on `attributed` the host already attributes every version, so it tells a reader nothing the host could not have lied about before; it cannot tell a reader whether a rewrite kept `kind` or `inReplyTo`, which only an earlier version can. On `private` there is no `createdBy`, and a first-time reader has only the version in front of it.
+ *
+ * **Withdrawing a message.** The author of a `message` withdraws it by writing a new version of it — the same key, keeping its `kind` and any `inReplyTo` — with an empty `body` and no `file`. A reader shows a current version of a message with an empty `body` and no `file` as withdrawn, or not at all, and MUST NOT show any earlier version's content in its place; replies to it stay, as answering a record that is not available (*Replies*). It counts as a withdrawal only when its `author` is the `author` of the version it replaces; one by another member is that member's rewrite (*Edits*), never the author withdrawing their own message. Withdrawing needs only `write`. It is a rewrite, not a retraction: the record keeps its key and its place, and only a member with `curate` retracts it (`rooms/records/curate`).
+ *
+ * **Tombstones.** A retracted record keeps its key and version and nothing of its body (`rooms/records/curate`). On the sealed tiers `kind`, `inReplyTo`, `writtenAt` and `editedAt` were inside the sealed body and go with it. On an `open` room they were in `cleartext`, which is the body there, so an open room's tombstone keeps none of them either (`rooms/records/put`, *Retention*). A reader that held an earlier version of a retracted record uses the `kind` and the place in the conversation that version gave it — a retracted message shown as retracted where the message was, a retracted reaction counted as no reaction. A reader that held none shows the tombstone in no conversation and in no reaction count. Replies to a retracted record stay, as answering a record that is not available (*Replies*).
+ *
+ * **An author whose DID does not resolve.** Rule (2) fails in two ways, which a reader MUST tell apart: `author`'s DID does not resolve to a DID document — it no longer resolves, or its method reports it deactivated — or the proof does not verify against the document it resolves to. A record whose proof does not verify is refused, as above, except where *Which DID document* requires the placeholder instead. For a record whose author's DID does not resolve, a reader MAY, instead of refusing it, show a placeholder saying that the record's author cannot be verified, in the room's conversation, ordered by the host's `createdAt` for it, else its `updatedAt`, so that replies naming its key still anchor to it. It MUST NOT show or use any member of the body — not its `body`, `title`, `file`, `kind`, `inReplyTo` or `writtenAt` — MUST NOT count it as a reaction, and MUST NOT accept it as the room's profile (`RoomProfileStatement`). A placeholder is not a record shown with a warning: it shows none of the record.
+ *
+ * **A file's caption.** On a record carrying `file`, `body` is the file's caption. A reader that shows the file SHOULD show its `body` with it. A manifest's `width`, `height` and `preview` let a reader lay out and show an image before fetching it; they are advisory (`FileManifest`).
+ *
+ * **When a writer may use these members.** `kind`, `inReplyTo`, `writtenAt` and `editedAt`, and the `FileManifest` members `width`, `height` and `preview` inside `file`, are gated together. A conforming reader that predates them refuses a body carrying any of them by rule (1), as it refused provenance before it knew it: a message written with `kind` is invisible to it rather than shown wrong. **Not every reader conforms.** A reader that ignores the members it does not know shows a reaction as a post holding its value, and a withdrawn reaction as an empty post — which is why a room's readers move first, and the room says when its writers may follow. A writer MUST NOT write `kind`, `inReplyTo`, `writtenAt`, `editedAt`, `width`, `height` or `preview` into a room unless the room's current profile (`RoomProfileStatement`, as a reader resolves it) lists that member in `recordMembers` (`RoomProfile`). No profile, a profile without `recordMembers`, or one the writer cannot resolve means none of them may be written — the most restrictive reading. A writer MAY rely on a profile it resolved within the room's current epoch, without resolving it again for each write; once the room's epoch advances, it resolves the profile again before writing any of them. A writer that may not use them MAY write a message as a record with `body` and no `title`, which every reader shows (*Untitled records*). On the sealed tiers a writer whose key holder signs or seals for it needs one that accepts these members: `rooms/keys/seal/0.3` does, which `trust-task-discovery` tells it, and a key holder that predates them refuses them with `bodyInvalid`, as it refuses provenance.
+ *
+ * **Turning them on.** Whether a room's readers are ready is decided out of band by the room's owner or a curator: nothing in this family tells them which readers the room's members use. They list a member in `recordMembers` only once every reader they expect in the room accepts it — non-conforming readers included, which show the new records wrong rather than not at all — and in this order: (1) the readers, including every reader of the room's profile, since a reader that predates `recordMembers` refuses the profile carrying it; (2) the owner's key holder, which re-writes the profile under each new epoch after a removal (`RoomProfileStatement`, `rooms/keys/profile/write`) and MUST accept a profile carrying `recordMembers` before any profile carries it — one that refused it would re-write an older profile, or none, and the next removal would silently turn the members off; (3) on the sealed tiers, the key holders that seal for the room's writers (`rooms/keys/seal/0.3`); (4) then the profile. No room lists them by default. A room's profile lists them when its owner or a curator writes it with them — with `rooms/keys/profile/write` on an `attributed` or `private` room, or by writing the record at `room-profile` with `rooms/records/put` on an `open` one — both of which need `curate` or `admin`.
+ */
+export interface SealedRecordBody {
+  /**
+   * The room the record was written in, exactly as on the wire.
+   */
+  roomId: string;
+  /**
+   * The record's key, as in `rooms/records/put`.
+   */
+  key: string;
+  /**
+   * The version the writer intended the record to take, as sealed with `rooms/keys/seal`: the version the body is bound to. A record curated since keeps its body and moves to a new version, and carries this one as `sealed.version` (`SealedRecord`).
+   */
+  version: number;
+  /**
+   * The DID of the party that wrote the record: the member, or the agent acting under an attenuated credential, whose key signed `proof`. On a `private` room this is the only attribution there is.
+   */
+  author: string;
+  title?: string;
+  description?: string;
+  /**
+   * The record's text: plain text on a `message`, the value on a `reaction`, markdown on a note and on a kind the reader does not know (*What `body` is*). Human-readable, never a model-optimised blob, and rendered inert.
+   */
+  body?: string;
+  /**
+   * @maxItems 32
+   */
+  tags?: string[];
+  kind?: RecordKind;
+  /**
+   * The record this one answers or, on a `reaction`, responds to. See *Replies* and *Reactions*.
+   */
+  inReplyTo?: RecordReference;
+  writtenAt?: RecordWrittenAt;
+  editedAt?: RecordEditedAt;
+  basis?: RecordBasis;
+  confidence?: RecordConfidence;
+  evidence?: RecordEvidenceList;
+  validFor?: PermittedUse;
+  validUntil?: RecordValidUntil;
+  /**
+   * Present when the record carries a file. Its `blobRef` MUST be the one the record names in `blobs`.
+   */
+  file?: FileManifest;
+  /**
+   * Present only on the room's profile record, which then carries no `title`, `description`, `body`, `tags` or `file`. See `RoomProfileStatement`.
+   */
+  roomProfile?: RoomProfileStatement;
+  /**
+   * The author's Data Integrity proof over every other member.
+   */
+  proof: {};
+}
 export interface SealedShare {
   recipient: TrusteeIndex;
   share: SealedPayload;