@factoidal/core 0.11.0 → 0.13.0

package/CHANGELOG.md

@@ -1,5 +1,570 @@
 # Changelog
 
+## 0.13.0
+
+**A parsed document is a set of quads** (RDF 1.1 Concepts §3 and §4;
+https://github.com/danbri/factoidal/issues/972). Up to 0.12.0 a document
+that stated the same triple twice gave a graph with two copies: `size`
+counted 2 and `SELECT (COUNT(*) AS ?n)` answered 2. Every parser, the
+streamed parse, the command's `query` and the stores now keep one copy.
+Language tags compare case-insensitively (RDF 1.2 Concepts §3.4), so
+`"a"@en` and `"a"@EN` are one term in a graph and in a store dictionary
+(https://github.com/danbri/factoidal/issues/977).
+
+SPARQL and RDF semantics fixes:
+
+- `=` and `!=` follow RDFterm-equal (SPARQL 1.1 §17.4.1.7). Terms of
+  different kinds (IRI, blank node, literal, triple term) give `=` false.
+  Two literals that are different terms give a type error, except where
+  the §17.3.1 extension of the W3C tests gives false: `rdf:langString`
+  against another datatype, and `xsd:dateTime` against `xsd:date`. The
+  SPARQL 1.0 open-world tests: 18 pass, 0 fail (out of 18); were 13 pass,
+  5 fail.
+- `rdf:XMLLiteral` values compare by RDF term equality; SPARQL `=` on two
+  different XMLLiteral terms is a type error
+  (https://github.com/danbri/factoidal/issues/963). The RDF/XML parser's
+  exclusive XML canonicalization is repaired.
+- A query with `FROM` clauses queries the RDF merge of those graphs
+  (SPARQL 1.1 §13.2.1): blank nodes from different `FROM` graphs are no
+  longer joined (https://github.com/danbri/factoidal/issues/979).
+- RDFS closure rule rdfs9 accepts a blank node as the sub-class
+  (RDF 1.1 Semantics §9.2; https://github.com/danbri/factoidal/issues/982).
+- The RDF/XML writer keeps the base direction of a directional language
+  string (`its:dir` with `rdf:version="1.2"`). The JSON-LD writer still
+  drops it: https://github.com/danbri/factoidal/issues/984.
+- Opening a dataset renames blank nodes inside triple terms as well as at
+  the top level.
+- `factoidal sample-store` under Deno printed its path three times: the
+  pack and the activate each re-executed the whole command. It now
+  re-executes once, before any work.
+
+**`proofCheck` no longer joins blank nodes across artifacts**
+(https://github.com/danbri/factoidal/issues/976). Up to 0.12.0 a bundle
+could take `:A rdfs:subClassOf _:x` from one graph artifact and
+`_:x rdfs:subClassOf :C` from another with the same RDFC-1.0 digest, and
+conclude `:A rdfs:subClassOf :C` with `valid: true`. Blank nodes are now
+scoped to the artifact or assumption they come from (RDF 1.1 Semantics
+section 5.2), so that bundle is refused. A chain inside one artifact, and
+a chain across artifacts through triples with no blank node, are still
+accepted. The report has a new member `rejection`: `null` for a valid
+bundle, else the first failed check in words. The bundle format and the
+profile `fpp0/1` are unchanged.
+
+**XMPP server from wasm.** `factoidal xmpp-serve DIR` and
+`@factoidal/core/xmpp/server` run the Lean XMPP server
+(`L4Factoidal.XMPP.Server` — RFC 6120 negotiation, SASL PLAIN and
+SCRAM-SHA-256, binding, RFC 6121 roster/presence/messages) in the
+WebAssembly engine, one engine session per TCP or direct-TLS (XEP-0368)
+connection. New engine ops `xmppOpen`, `xmppSessionOpen`,
+`xmppSessionFeed`, `xmppSessionDeliver`, `xmppSessionClose`,
+`xmppRosterGet`, `xmppRosterSet`, `xmppClose`
+(`formal/lean4/Wasm/Ops/XmppSession.lean`). The state directory is the
+native carrier's layout (`accounts`, `roster/`, `spool/`), so a stanza
+written as a file under `spool/<bare jid>/` is delivered to that
+account. See `xmpp/README.md`.
+
+Linked Web Storage kept in files, stage 2 (https://github.com/danbri/factoidal/issues/918;
+design record `docs/designissues/2026-10-22-lws-storage-on-disk.md`):
+
+- Stage 2 (`L4Factoidal/LWS/Bodies.lean`): with `--storage files` the bodies
+  stay in their body files. An entry keeps its length, its FNV-1a and SHA-256
+  digests and the types of a Turtle body, and no bytes (ACL resources keep
+  theirs). A step that needs bytes (GET body or range, JSON Patch, a PUT a
+  subscription may hear of, a move of a Turtle resource) answers
+  `read: [PATH, ...]`; the host reads those files and gives them to the new op
+  `lwsRead` (byte-region entry only), which checks them, and steps again. A
+  start reads no body file unless the metadata lacks a fact; the peak RSS of a
+  start and one GET of 1,000 and 4,000 resources of 16 KiB is 230 and 211 MiB
+  (stage 1: 258 and 515 MiB). A changed body file is refused when it is read
+  (the request answers 500), no longer at start.
+- The LWS handles run a tree store (`TreeStore`, theorem `treeStoreLaws`) and
+  a type index in persistent trees: the engine's step and persist of a PUT
+  take 0.30, 0.27, 0.28 and 0.29 ms in a storage of 1,000, 2,000, 4,000 and
+  16,000 resources (stage 1: 0.21 ms at 1,000, about 3 ms at 16,000). A POST
+  no longer lists every path; a DELETE lists paths only for a container.
+- The order of the entries of a snapshot and of `lws-files.json`, and of the
+  activities of a recursive DELETE in one notification, is path order (was
+  newest first). `lwsSnapshot` of a storage kept in files is refused.
+- `solid-serve` keeps the snapshot: an expected failure naming issue 918.
+
+An authorization server as a component (https://github.com/danbri/factoidal/issues/916;
+design record `docs/designissues/2026-10-22-authorization-server.md`; skill
+`skills/authz-server/SKILL.md`), decided in Lean (`L4Factoidal/Authz/`):
+
+- `factoidal authz-serve DIR --resource IRI[,IRI...]` and
+  `import { listen } from '@factoidal/core/authz'`: RFC 8414 metadata at
+  `/.well-known/lws-configuration` (and `/.well-known/oauth-authorization-server`),
+  a JWK Set, and an RFC 8693 token endpoint that exchanges a subject token for
+  an RFC 9068 access token whose `aud` is exactly the requested resource
+  (lws10-core "Authorization"). `lws-serve --issuer <its issuer>` accepts its
+  tokens with no other setting. `factoidal authz-keys DIR` prints the JWK Set.
+- Subject tokens: OpenID Connect ID tokens (lws10-authn-openid) and
+  self-issued JWTs for https and did:key subjects (lws10-authn-ssi-cid; P-256
+  and Ed25519 did:keys). SAML 2.0 is refused and not advertised: there is no
+  XML Signature verifier (https://github.com/danbri/factoidal/issues/926).
+  solid-serve does not accept these tokens yet
+  (https://github.com/danbri/factoidal/issues/928).
+- Documents the server fetches for a subject token: `https` only (`--allow-http`
+  for tests), never from a loopback, link-local or private address
+  (`--allow-private-fetch` for tests), from the address the engine checked,
+  with no redirect.
+- Keys: ES256 by default (`--alg EdDSA`), signed by HACL\* through three new
+  P-256 externs (sign, secret-to-public, point decompression; RFC 6979 and
+  Wycheproof vectors in `lake exe l4crypto-probe`); `kid` is the RFC 7638
+  thumbprint; `--rotate-after` rotates and keeps the old key published until
+  its tokens expire; `DIR/authz-keys.json` (mode 0600) is sealed under
+  `FACTOIDAL_LWS_KEY` when it is set.
+- New ops `authzOpen`, `authzStep`, `authzFetched`, `authzKeys`, `authzRotate`,
+  `authzClose`.
+- Theorems: `issueToken_verifies_published` and `issueToken_audience_exact`
+  hold because of a run-time check of every issued token (the proof that
+  removes the check: https://github.com/danbri/factoidal/issues/927);
+  `exchange_refused_no_token` (a subject token that fails validation never
+  yields an access token), `cid_valid_verified`, `didKey_valid_verified`,
+  `oidc_valid_named_provider`, `chooseAddress_refuses_private` and others.
+- Touchstone with this server in place of its reference one
+  (`tools/lws-touchstone.sh --config auth --authz factoidal`, 2026-10-22):
+  212 passed, 0 failed, 9 inapplicable (out of 221); of these
+  core/authorization_server 9 pass, 0 fail (out of 9), auth/oidc 6 pass,
+  0 fail (out of 6), auth/cid 22 pass, 0 fail (out of 22), auth/saml 3
+  inapplicable (issue 926).
+
+CORS in the LWS HTTP binding (https://github.com/danbri/factoidal/issues/923),
+decided in Lean (`L4Factoidal/HTTP/Cors.lean`, `L4Factoidal/LWS/Cors.lean`), so
+a page on another origin (for example GitHub Pages) can call `lws-serve`:
+
+- A CORS-preflight request (`OPTIONS` with `Access-Control-Request-Method`
+  and `Origin`) is answered 204 before any other decision, with no token and
+  no access check: `Access-Control-Allow-Methods` (with `QUERY` and `PATCH`),
+  `-Allow-Headers` (`Authorization`, `Content-Type`, `If-Match`,
+  `If-None-Match`, `If-Modified-Since`, `If-Unmodified-Since`, `Link`,
+  `Prefer`, `Slug`, `Range`, `DPoP`, `Accept`), `-Max-Age` 7200. An `OPTIONS`
+  without `Access-Control-Request-Method` is answered as before.
+- Every answer carries `Vary: Origin` (one `Vary` field with the answer's
+  own), and, for an answered origin, `Access-Control-Allow-Origin` and
+  `Access-Control-Expose-Headers` (`ETag`, `Link`, `Location`, `Allow`,
+  `Accept-Patch`, `Accept-Post`, `Accept-Put`, `Accept-Query`,
+  `Accept-Ranges`, `Content-Location`, `Content-Range`, `WWW-Authenticate`,
+  `Preference-Applied`, `Repr-Digest`, `Last-Modified`,
+  `Factoidal-Merkle-Root`). No `Access-Control-Allow-Credentials`: the token
+  goes in `Authorization`.
+- Default: echo a valid request `Origin` (Solid Protocol §8.1), never `null`.
+  `lws-serve --cors-origin ORIGIN` (repeatable) answers only those origins;
+  `--no-cors` sends no CORS field; config member `cors` (`false` or a list).
+  A malformed origin stops the start.
+- `authz-serve` gets the same (`Authz.stepCors`; methods `GET, HEAD, OPTIONS,
+  POST`), with the same flags. `solid-serve` keeps its own Solid §8.1 CORS;
+  its preflight is now answered before Web Access Control (it was 401 for a
+  resource that is not public).
+
+An LWS client (https://github.com/danbri/factoidal/issues/917; design record
+`docs/designissues/2026-10-22-lws-client.md`):
+
+- `@factoidal/core/lws/client`: `createLwsClient({ fetch, subjectToken,
+  subjectTokenType })` with `discover`, `read`, `head`, `create`, `update`,
+  `patch`, `delete`, `readLinkset`, `updateLinkset`, `move`, `list`,
+  `typeIndex`, `search`, `subscribe`, `unsubscribe`, `requestAccess`,
+  `grantAccess`, `getAccess`, `revokeAccess`, `verifyNotification`; and
+  `createNotificationReceiver`, a webhook receiver that answers each delivery
+  with the engine's verdict. `fetch` is injected (Node, a browser, or a
+  transport such as XMPP).
+- Every decision is in Lean (`L4Factoidal/LWS/Client/`, wasm ops
+  `lwsClientStart` and `lwsClientStep`): the 401 flow with the three checks of
+  lws10-core "Discovery Validation by a Client", RFC 8414 metadata and RFC 8693
+  token exchange; conditional writes (the current ETag by default for
+  `update`, `patch`, `updateLinkset`, `move`); no repeat after 405 or 415, no
+  POST again after a 5xx or a lost answer; paging by `rel="next"` only;
+  linkset writes only in advertised methods and formats; the RFC 9421 check of
+  a notification. Theorems: `walk_concat`, `walk_members_once`,
+  `step_write_precondition`, `step_no_token_request_without_validation`,
+  `step_no_blind_create_retry`, `step_no_repeat_after_refusal`.
+- CLI `factoidal lws-client <op> URL`.
+- Self-issued credentials (lws10-authn-ssi-cid): `createLwsClient({ selfIssued:
+  { subject, keyId, jwk } })`; the engine signs the ES256 JWT with HACL*.
+- Expected failure: OpenID sign-in is not built (row names issue 917).
+
+## 0.12.0 — 2026-10-22
+
+One error model for the whole package
+(https://github.com/danbri/factoidal/issues/882 item 4,
+https://github.com/danbri/factoidal/issues/901 KR 3.1). Every op error
+envelope of the engine carries a stable `code`, the input `position` where
+the input defines one, and the `spec` section where one applies; the engine
+decides all three (`formal/lean4/Wasm/Ops/ErrorModel.lean`). The package
+copies them into one class, `FactoidalError`. The README "Errors" table is
+generated from the engine's list.
+
+### Breaking changes
+
+- `DatasetHandle`, the name of `Dataset` before 0.10.0, is removed. Use
+  `Dataset`.
+
+- `ParseError` is removed. Every function rejects with `FactoidalError`
+  (`code`, `position`, `spec`, `cause`); a parse error has
+  `code: 'parse.syntax'` (or `parse.rdf12-required`, `term.invalid-iri`,
+  `term.invalid-langtag`) and `err.position.{line, column, offset}` in place
+  of `err.line`, `err.column`, `err.offset`. `position.byteOffset` is new.
+- Error messages are the engine's text, with no `<function>: l4factoidal:`
+  prefix. A parse with an inferred format no longer appends "(format inferred
+  as ...)" to the message; `err.formatInferred` and `err.format` say it.
+- An unknown option key, an unknown format name, an `entail`, `output`,
+  `version`, `owlClosure` mode, `rmlMap` source kind or `Dataset.closure`
+  regime outside the engine's tables, and options that cannot be combined
+  were a `TypeError`; each is now a `FactoidalError` (`option.unknown`,
+  `format.unknown`, `option.invalid-value`, `regime.refused`,
+  `option.conflict`) decided by the new engine op `apiCheck`. A `TypeError`
+  stays only for an argument of the wrong JavaScript type.
+- A method of a disposed `Dataset` was a `TypeError`; it is now the engine's
+  `FactoidalError` with code `handle.disposed`. A closed `Store` is the same.
+- `queryRaw` rejected with an `Error` whose message began "SPARQL query
+  failed:" and which had `stderr`; it now rejects with the engine's
+  `FactoidalError` (`query.syntax` with a position, or `query.failed`).
+- File-system and IndexedDB failures (`openStore`, the delta log) are
+  `FactoidalError` with code `host.io` and the original error as `cause`.
+- `@factoidal/core/fn` `entail()` with an `x-ikl-*` regime rejects with code
+  `regime.refused` and the message names `query`, the function that refuses.
+
+Linked Web Storage kept in files, stage 1 (https://github.com/danbri/factoidal/issues/918;
+design record `docs/designissues/2026-10-22-lws-storage-on-disk.md`), decided in
+Lean (`L4Factoidal/LWS/Journal.lean`, `FileLayout.lean`):
+
+- `factoidal lws-serve DIR --storage files` (config member `storage: "files"`,
+  `listen({ storage: 'files' })`; the default stays `snapshot`): DIR holds one
+  file per resource body under `bodies/`, a journal `lws-journal` with one
+  record per change, and a metadata file `lws-files.json` that the journal is
+  folded into when it passes max(1 MiB, the size of the metadata file). A
+  write no longer rewrites the whole storage: a PUT into a storage of 1,000,
+  2,000 and 4,000 resources took 2.70, 2.40 and 2.89 ms, against 42.6, 83.9 and
+  170.4 ms with the snapshot (`tests/lws/scaling.mjs`, rows "storage").
+- A journal record is valid only when it is complete and its SHA-256 matches;
+  a torn last record is ignored at start (theorem `decodeFrames_torn`).
+  Replaying the records of a sequence of steps gives the metadata of the store
+  after them (`replay_records`, `persist_replay`).
+- With `FACTOIDAL_LWS_KEY` every body file and journal record is sealed with
+  ChaCha20-Poly1305 (HACL*), the file's own name in the associated data, and
+  `lws-files.json` as the snapshot is.
+- An existing `lws-state.json` is migrated at the first start in files mode and
+  renamed to `lws-state.json.migrated`.
+- New ops `lwsLoad` and `lwsPersist` (byte-region entry only): the engine names
+  the files to read and gives every file operation and byte; the host
+  (`lws/persist.mjs`) performs them. `tools/lws-touchstone.sh --storage files`.
+- Stage 1 still holds the whole storage in memory; stage 2 (bodies read on GET,
+  the metadata in an on-disk index) is an expected failure in
+  `tests/lws/scaling.mjs` naming issue 918.
+
+Linked Web Storage Search and Type Index Services (`lws10-index`, w3c/lws-protocol
+`9a08ff65`; https://github.com/danbri/factoidal/issues/912), decided in Lean
+(`L4Factoidal/LWS/TypeIndex.lean`, `Search.lean`):
+
+- The storage description advertises a `TypeIndexService`
+  (`GET /.well-known/lws-type-index`, a paged `TypeIndex`) and a
+  `TypeSearchService` (`QUERY /.well-known/lws-type-search` with an
+  `application/lws-query+json` filter in conjunctive normal form over `type`
+  and indexed relations such as `describedby`; a paged ContainerPage).
+  Option `typeIndex: false` of `listen`/`openLwsStorage` turns both off.
+- Types come from the native class, from `Link: <T>; rel="type"` on POST and
+  on `Prefer: set-linkset` PUT and PATCH, and from `rdf:type` in Turtle
+  content up to 1 MiB. Such a `type` link was refused with 409 before; it is
+  now a declared type and appears in the linkset document. A `type` link
+  that names an LWS or LDP class is still refused with 409. A PUT or PATCH
+  that applies `Prefer: set-linkset` answers `Preference-Applied: set-linkset`.
+- The index is kept by the store on every write and rebuilt in one pass when
+  a snapshot is opened. Answers, `totalItems` and the type index hold only
+  what the requesting agent may read now. Theorems `ixSearch_eq_specSearch`
+  and `searchAnswer_authorized`.
+
+Linked Web Storage Access Requests and Grants (LWS core §Access Requests
+and Grants, w3c/lws-protocol `9a08ff65`;
+https://github.com/danbri/factoidal/issues/913), decided in Lean
+(`L4Factoidal/LWS/AccessPolicy.lean`, `AccessGrants.lean`):
+
+- The storage description advertises an `AccessRequestService`
+  (`/.well-known/lws-access-requests/`) and an `AccessGrantService`
+  (`/.well-known/lws-access-grants/`), each with `conformsTo`
+  `https://www.w3.org/ns/lws#AccessProfile`. Both endpoints are LWS
+  containers: GET lists (paged), POST of an `application/lws+json` document
+  answers 201 with `Location`, GET and DELETE act on one member. Option
+  `accessGrants: false` of `listen`/`openLwsStorage` turns both off.
+- Any authenticated agent creates an access request; only the storage
+  controller (`acl:Control` on the storage root) creates or revokes a grant.
+  A document without `type`, `storage` (this storage), `access`, a policy
+  `type` with `AccessPolicy`, `action` (`read`, `modify`, `create`,
+  `delete`), `assignee`, or with a bad `inbox`, `target` or constraint,
+  answers 400.
+- A grant is part of the access policy beside Web Access Control: it permits
+  exactly its actions on exactly its targets (a container grant does not
+  reach the members) to its assignee (`foaf:Agent` for the public), when
+  every constraint holds: `dateTime` (`eq`, `gt`, `gteq`, `lt`, `lteq`),
+  `format` and `type` of the resource, `client` (the token's `client_id`)
+  with `eq` or `isAnyOf`; `purpose` is accepted and no request satisfies it.
+  A move needs `delete` of the resource and `create` in the destination.
+  Notification subscriptions and deliveries, and the type index answers,
+  see the same access. Theorems `grantsPermit_sound`,
+  `policyPermits_excluded`, `recordPermits_expired`, `grantsPermit_revoke`,
+  `grantAllows_acl`.
+- A new grant is announced (one `Create` notification) to its `inbox` and
+  to the inbox of each access request naming one of its assignees. Grants
+  and requests are kept in the storage snapshot (member `access`).
+- The storage controller hears of a new access request
+  (https://github.com/danbri/factoidal/issues/920). Core §Access Requests and
+  Grants: "When a new access request is submitted, the storage controller
+  SHOULD be notified." The draft names no inbox for the controller, so this
+  server's is configuration: `listen({ controllerInbox: URL })` or
+  `factoidal lws-serve --controller-inbox URL`. When it is set, each new
+  access request gives one `Create` notification there (signed, retried, as
+  every delivery); when it is not set, nothing is sent. An inbox that is not
+  `http` or `https` stops the start.
+
+Linked Web Storage moves and notifications, three more rules
+(w3c/lws-protocol `9a08ff65`), decided in Lean:
+
+- 301 at the previous identifiers of a moved resource
+  (https://github.com/danbri/factoidal/issues/914;
+  `L4Factoidal/LWS/MoveRedirect.lean`). §Moving Resources: "Such a server
+  SHOULD respond to subsequent requests on the previous identifiers of the
+  resource and of its auxiliary resources with 301 Moved Permanently,
+  including a `Location` header field pointing at the new identifier." After
+  a move, a request to the old path of the resource, of each descendant of a
+  moved container, of its `.acl` and `.meta` and of its `?linkset` answers
+  301 with the new IRI, when the same request at the new path would be
+  authorized (§Privacy Considerations, "Redirects": "Servers SHOULD apply the
+  same access control to such responses as to the moved resource itself");
+  otherwise the old path answers as before. A chain of moves answers the
+  current path. The table holds at most `redirectsMax` pairs (default 256,
+  `lws-serve --redirects-max N`), is kept in the snapshot (member `moved`),
+  and loses a pair when a new resource is created at its old path or the
+  moved resource is deleted. Theorems `redirect_current`, `after_ok`,
+  `redirect_after_move`.
+- A webhook inbox that names this server under another host name, an IP
+  address or `localhost`, at its port, is refused with 400
+  (https://github.com/danbri/factoidal/issues/915;
+  `L4Factoidal/LWS/InboxGuard.lean`). The engine compares the inbox
+  authority with the base IRI, the bound address and the interface
+  addresses; for a host name it answers `lwsStep` with `resolve: {host}`, the
+  host resolves the name and steps the request again with `resolved`. The
+  host passes `listen: {address, port, addresses}` to `lwsOpen`.
+- A delivery rate limit per subscription (issue 915; the webhook suite:
+  "Rate limiting and endpoint verification are suggested to prevent abuse of
+  the subscription mechanism"): at most `deliveryLimit` deliveries (default
+  10) in a window of `deliveryWindow` seconds (default 60;
+  `lws-serve --delivery-limit N --delivery-window S`; `deliveryLimit: 0`
+  turns it off). The activities over the limit wait and go, when the window
+  ends, in one envelope with an `activity` array (core §Batching
+  Notifications). An answer may carry `wake: SECONDS`; the host then calls
+  the new op `lwsFlush`. Theorem `admits_le`: at most `deliveryLimit`
+  deliveries per subscription in one window. Endpoint verification: the
+  drafts define no procedure (no request, no challenge, no expected answer),
+  so there is no behaviour to implement.
+
+Linked Web Storage, three rules of the editor's draft (w3c/lws-protocol
+`9a08ff65`, 2026-10-19), all decided in Lean:
+
+- Container pagination (§LWS Media Type, Pagination;
+  https://github.com/danbri/factoidal/issues/887). A container with more
+  than `pageSize` members (option of `listen`/`openLwsStorage`, default 100,
+  0 turns it off) answers in pages: `Link` relations `first`, `last`, `next`
+  (not on the last page) and `prev` (not on the first page), page URIs
+  `CONTAINER?page=N`, `totalItems` over the full membership, one `ETag` per
+  page. Members are listed in increasing path order, each once (theorem
+  `pageItems_concat`).
+- Client-managed links (§Metadata, §Update Resource;
+  https://github.com/danbri/factoidal/issues/888): `Link` with
+  `Prefer: set-linkset` on PUT (replace) and PATCH (add), `Link` on POST, and
+  JSON Patch or PUT of `application/linkset+json` on `PATH?linkset`.
+  Server-managed relations (`linkset`, `type`, `format`, `size`, `modified`,
+  `up`, `items`, `lws#storage`) answer 409; a malformed link answers 400.
+  Client links are kept in the storage snapshot.
+- Notifications (§Notifications and the webhook notification suite
+  `lws10-notifications-webhook`;
+  https://github.com/danbri/factoidal/issues/890). The storage description
+  advertises a `NotificationService` (`subscriptionType`
+  `["WebhookSubscription"]`, endpoint `/.well-known/lws-subscriptions/`) and
+  an Ed25519 `JsonWebKey` verification method. An authenticated POST of a
+  `WebhookSubscription` (`topic`, `inbox`, optional `expires`) answers 201;
+  each topic must be readable by the agent (403 otherwise). Every successful
+  write gives Activity Streams 2.0 `Create` (with `target`), `Update` or
+  `Delete` (with `origin`) activities, sent only to subscribers who may read
+  the resource at that time, as an `application/lws+json` POST to the inbox,
+  signed with HTTP Message Signatures (RFC 9421) and `Content-Digest`
+  (RFC 9530). The endpoint lists the agent's subscriptions; GET and DELETE
+  manage one. A delivery answered 5xx, 408, 425, 429 or not at all is tried
+  up to three times; 410 or three failed deliveries deactivate the
+  subscription. Subscriptions and the signing key are kept in the storage
+  snapshot. The host makes the requests the engine names and reports each
+  status to the new op `lwsDelivered`; `listen`/`openLwsStorage` take
+  `notifications: false` to turn it off.
+- Moving resources (§Moving Resources;
+  https://github.com/danbri/factoidal/issues/914). The storage description
+  describes a `MoveResource` capability (`appliesTo` DataResource and
+  Container, `preservesIdentifier` false). A JSON Patch (or PUT) of a
+  resource's linkset that changes its `up` link moves it to that container,
+  with its descendants when it is a container, in one step: the answer is
+  200 with the new linkset and `Content-Location`, both containers get a new
+  ETag, and a subscriber hears one `Move` activity (`origin`, `target`). A
+  destination that is missing or not a container, a cycle, the storage
+  root, a name already taken, another storage or a removed `up` link is
+  409. The agent needs the delete of every moved resource and the create in
+  the destination. `listen`/`openLwsStorage` take `moves: false` to turn it
+  off. Theorem `move_tree`: a move keeps the containment hierarchy a tree.
+- Three server options, each off by default and decided in Lean
+  configuration, so that every Touchstone test that one of our
+  configurations can satisfy runs (`tools/lws-touchstone.sh --config all`):
+  `lws-serve --moves all|data|off` (`moves: "data"` describes `appliesTo`
+  `[DataResource]` and answers a change of a container's `up` link with 409;
+  `"off"` describes no `MoveResource`), `--no-linkset-put` (`linksetPut:
+  false`: a linkset's `Allow` leaves out PUT and a PUT answers 405 with
+  `Allow`, as lws10-core §Metadata requires when PUT is not advertised) and
+  `--paginate-always` (`paginateAlways: true`: a container listing that fits
+  on one page is still one paginated page, with `rel="first"` and
+  `rel="last"` and no `rel="next"` or `rel="prev"`). An unknown `moves`
+  value stops the start.
+- Fixed: on a paginated container, `If-Match` with the `ETag` of its first
+  page (which a GET of the container URI answers) failed with 412; the
+  first page's tags are now current tags of the container.
+
+Encryption at rest of the LWS and Solid storage snapshot, off by default
+(https://github.com/danbri/factoidal/issues/921; owner, 2026-10-21: "Yes env
+var please. Again off by default but good to show we can."):
+
+- When the environment variable `FACTOIDAL_LWS_KEY` holds a 32-byte key (64
+  hex digits or base64url), `lws-serve` and `solid-serve` write
+  `DIR/lws-state.json` as format `lws-snapshot-sealed-1`: format id, cipher
+  id `chacha20-poly1305`, key id (first 8 bytes of SHA-256 of the key), a
+  12-byte nonce new for every write, and the ChaCha20-Poly1305 (RFC 8439,
+  HACL*) ciphertext of the snapshot, with the header as associated data.
+  `listen`/`openLwsStorage`/`openSolidStorage` take `storageKey` (text, or
+  `null` to read no key).
+- At start the file is authenticated before use. A wrong key, a changed or
+  truncated file, a clear-text file with the variable set and a sealed file
+  without it each stop the start with a one-line message (exit 1). With the
+  variable unset, behaviour is unchanged.
+- It protects the file on disk only: not the memory of a running server, not
+  the key in its environment, not the answers to clients.
+- Decided in Lean (`L4Factoidal/LWS/SnapshotSeal.lean`), with theorems over
+  any AEAD with RFC 8439 correctness (`unsealDoc_sealDoc`,
+  `unsealDoc_authenticated`, `unsealDoc_wrongKey`, ...). `lwsSnapshot` and
+  `solidSnapshot` take an optional second argument `{"nonce":…}`.
+- Cost with a key (2026-10-21, about 1,050 resources): a write takes about
+  2.7 times as long (133 to 143 ms against 49 to 54 ms), the file is 1.33
+  times larger, a restart about 2.1 times as long.
+
+### Breaking changes
+
+- The storage description has a second service, `NotificationService`, and
+  `verificationMethod` and `authentication` members; its `ETag` is a digest
+  of the document.
+- A container listing is in increasing path order. Before, it was in the
+  order of the store (newest write first).
+- A container with more than 100 members returns only its first 100 members
+  unless `pageSize` is set; follow `rel="next"`.
+- PUT on a linkset resource replaces the client links. Before, it answered
+  405.
+
+### Unstable
+
+- ANTICIPATORY AND UNSTABLE, off by default: a type search results resource
+  (https://github.com/danbri/factoidal/issues/922). With
+  `listen({ searchResults: true })` or `factoidal lws-serve
+  --unstable-search-results`, a QUERY answer of the Type Search Service by an
+  authenticated agent carries `Content-Location` naming
+  `/.well-known/lws-type-search/results/<id>` (RFC 10008 section 2.3).
+  lws10-index defines no such resource; its path, lifetime, snapshot member
+  and behaviour are likely to change. A GET by the same agent and client lists
+  the QUERY's results that a new QUERY would still answer (paged, filtered by
+  current read access); anyone else gets 404; after `searchResultsTtl`
+  (600 s) 410. The storage description marks it with the extension member
+  `https://github.com/danbri/factoidal/issues/922#unstableResultsResource`.
+  `lwsStep` request documents may carry `random` (16 bytes, base64); the LWS
+  host sends it with every request. Decided in Lean
+  (`L4Factoidal/LWS/SearchResults.lean`).
+- Off by default: Merkle hashes of the LWS storage
+  (https://github.com/danbri/factoidal/issues/919; owner, 2026-10-21: "As an
+  optional, probably default off until we settle on stronger motivating
+  usecase but good to have the fundamentals there"). With
+  `listen({ merkle: true })` or `factoidal lws-serve --merkle`: a GET or HEAD
+  of a resource carries `Repr-Digest: sha-256=:<base64>:` (RFC 9530, SHA-256
+  of the stored bytes, HACL*); a container listing carries
+  `Factoidal-Merkle-Root` and the member
+  `https://github.com/danbri/factoidal/issues/919#merkleRoot` (a Merkle digest
+  over its members and their digests); the storage description carries
+  `https://github.com/danbri/factoidal/issues/919#storageMerkleRoot`. Under
+  authorization the roots go to the storage controller only. Entity tags do
+  not change. The hashes are kept by the store on every write, delete and
+  move (only the containers above the change are recomputed) and rebuilt when
+  a storage is opened; no hash is in the snapshot. Decided in Lean
+  (`L4Factoidal/LWS/Merkle.lean`, `MerkleHttp.lean`), with theorems
+  `MkState.dig_eq_recompute` (the kept digests equal a recomputation from the
+  store) and `change_reaches_ancestor` (a change reaches every container
+  above it, with collision-freedom of SHA-256 as a stated hypothesis).
+  Cost (2026-10-21, wasm in Node): a write into a container of 2,000 members
+  takes about 6.3 ms with the option on against 0.9 ms off (linear in the
+  members of each container above the write); a reopen of 2,000 resources
+  with the hashes rebuilt takes 246 ms.
+
+### Performance
+
+- LWS and Solid PUT and GET of a large body
+  (https://github.com/danbri/factoidal/issues/903): one 100,000-triple
+  N-Triples body (7.7 MB) took about 17 s to PUT and the GET stopped the
+  engine with out of memory; now the PUT takes 85 ms and the GET 40 ms
+  (`npm run test:costs`). The cause was the FNV-1a digest of the entity tag,
+  computed in `Nat`: on wasm32 each byte made heap numbers. It now runs in
+  `UInt32` (theorem `fnv1a32_eq_spec`: same value as the `Nat` definition).
+  Peak memory of the 100,000-triple PUT and GET fell from 2,640 MiB to
+  288 MiB. Scaling check: `node tests/lws/scaling.mjs`.
+
+### Fixed
+
+Seven defects of `lws-serve` that the Touchstone LWS conformance harness found
+(https://github.com/danbri/factoidal/issues/911; record:
+`docs/designissues/2026-10-21-lws-touchstone-run.md`). All are decided in
+Lean (`formal/lean4/L4Factoidal/LWS/`):
+
+- A POST or PUT with no content and no `Content-Type` is accepted
+  (`Operations.writeMediaType`). Before, it answered 400, so the draft's own
+  container-creation example (`POST`, `Content-Length: 0`, the
+  `lws#Container` type link) failed. An empty data resource made this way
+  has type `application/octet-stream`. Content without `Content-Type` still
+  answers 400.
+- The Turtle form of a container uses `http://schema.org/size`, as the
+  `application/lws+json` context and the core draft's examples do. Before,
+  it used `https://schema.org/size`, so the two forms were not RDF
+  isomorphic. The WG's `lws10-vocab/vocabulary.yml` declares
+  `https://schema.org/`; the conflict is recorded in `Binding.containerTurtle`.
+- A container's `ETag` carries the FNV-1a digest of its listing in the
+  negotiated media type (`Binding.containerTag`). Before, it was the
+  container's clock only, and a host with a real clock sets the clock to
+  the current second, so two changes in one second gave one strong tag.
+  `Last-Modified` is unchanged.
+- The `lws#storage` link of a 401 and the default token audience are the
+  storage description IRI `<base>.well-known/lws-storage`, the IRI every
+  other response links and the description's `id` (`Authorization.storageIri`).
+  Before, both were the storage root `<base>`.
+- `If-Unmodified-Since` is evaluated for every method (412 when the resource
+  changed after the date), and `If-Modified-Since` and `If-Unmodified-Since`
+  are compared as instants in all three HTTP-date formats of RFC 9110
+  §5.6.7 (`HttpDate.parseHttpDate`; theorem `unixOfCivil_civilOfUnix`).
+  Before, `If-Unmodified-Since` was ignored and `If-Modified-Since` matched
+  only the exact `Last-Modified` text.
+- A POST names its new resource with the first free name of the hint (or
+  `res<clock>`), `-1`, `-2`, ... (`Operations.childPathFor`, theorem
+  `childPathFor_fresh`). Before, a clash got the clock as its one suffix,
+  and under a real clock the third POST to one container in one second
+  REPLACED the second resource.
+- The Turtle form of a container gives a contained container no
+  `dcterms:modified`: the `application/lws+json` context defines
+  `modified` for a DataResource only, so the JSON item's `modified` of a
+  container is no triple, and the two forms must be RDF isomorphic.
+- `factoidal lws-serve --page-size N` passes `N` to the engine's
+  `pageSize`.
+- Result: Touchstone (221 tests) runs with no failure, open 70 pass, 0
+  fail, 151 inapplicable; with authorization 146 pass, 0 fail, 75
+  inapplicable.
+
+Breaking: an LWS access token must name the storage description IRI in
+`aud` (or the `--audience` given). A token for the storage root IRI is now
+refused with 401 `invalid_token`.
+
 ## 0.11.0 — 2026-10-21
 
 No RDF, SPARQL, datatype or IRI decision is made in JavaScript any more