Host API requirements to complete the server protocol plugins #167

Activity

1. michielbdejong commented on Sep 25, 2026

   

   michielbdejong

   on Sep 25, 2026

   ContributorAuthor

   More actions

   Host status since the candidate5 baseline

   This issue inspected the host at candidate5 (35504494…). Since then, the atomic-server side of the plugin-routes design has been built as PRs against feat/plugin-debug. They are combined in the claude/atomic-plugins-pin-candidateN branches that atomic-plugins pins (via claude/atomic-plugins-pin):

   • candidate7 9ca5304d0 adds #1754, #1757 and #1759.
   • candidate8 f85b2a587 adds #1760, #1764 and #1763.
   • candidate9 74ae9931f adds #1768, #1774, #1769 and #1775.
   • candidate10 01b673cf6 adds #1788.
   • candidate11 is being built now. It adds the default daily delivery cap of 1,000 per installation (on #1760), #1789 (/_routes/* 404s), and lint fixes.

   Everything below is behind the plugin-routes Cargo feature and --plugin-routes read-only|read-write. A host without the feature refuses installation; it doesn't simulate success.

   1. Authenticated, atomic route mutations

   • Covered by #1754 (route writes, candidate7):
     • Verdict intents are applied at read-write only, to declared writeTargets, under an installation grant {"route-writes": [targets]}.
     • Creates are only allowed directly under a target parent with the target's classes. Updates and deletes are only allowed on resources this installation created (checked by genesis signer), still inside a target.
     • A route can never write parent, isA, rights, genesis, createdBy or provenance.
     • Quotas per caller per hour, per day and bytes per day (429 with Retry-After).
     • routeProvenance records the installation, route, request id, verified caller and time.
     • The response is sent only after the writes are applied. Refused writes answer 502 route-write-refused, with nothing written.
   • Covered by #1757 (candidate7) and #1775 (candidate9): the install and upgrade review asks the user to approve the targets. The page gives the agent write on each target parent, and revoke or uninstall removes it. A config change that moves a target asks again and moves the rights (#1775).
   • Covered by #1788 (candidate10): an app used as a table's view can edit that table's rows, but only through a grant tied to the "add view" gesture, recording grantedBy, grantedAt and via.
   • Still missing:
     • Preconditions evaluated inside the commit (create-if-absent, update/delete-if-current, multi-resource atomic batches). The only existing piece is the handler-reported response.current for blob routes in #1764.
     • Uniqueness constraints, and persisted deduplication keys or commit receipts for route mutations.
     • Explicit delegation to edit a user's existing resource. Route writes can only change what the installation created.
     • True all-or-nothing application: a store failure partway through answers 500 route-write-failed and may leave partial effects.

   2. Blob storage and linkage

   • Covered by #1764 (blob bodies, candidate8):
     • A body: "blob" route stores the request body in the BLAKE3 blob store before the handler runs. The handler gets request.blob = {hash, size, type, subject}, never the bytes.
     • A handler can answer with response.blob, served with the right content type, ETag, nosniff and HEAD support. HTML and SVG are refused on drive-prefix.
     • Conditional If-Match / If-None-Match answer 304 or 412.
     • A route may only serve blobs its installation stored, or ones held by resources under its approved targets. Knowing a hash is not enough.
     • Size is 16 MiB per route by default, with an operator cap, and it counts toward the byte quota.
   • Covered by #1730 and #1774 (candidate9): binary job uploads (accepts.as: "base64").
   • Still missing:
     • Byte ranges.
     • Streaming: bodies are buffered up to the limit.
     • Remote-content fetch into staged blobs.
     • Staged-blob cleanup and GC, and crash recovery. Stored bytes stay if the handler later fails.
     • Promoting a blob and its resource metadata in one transaction.

   3. Identities, keys and consent

   • Covered by #1759 (host crypto, candidate7):
     • Installation keys: per declared key, RSA-2048 or Ed25519, generated at activation, stored wrapped, and erased on revoke. The plugin gets ctx.keys.publicKey. ctx.keys.sign only signs for declared operations with the matching method; the private key never enters the sandbox.
     • Inbound auth: http-signature: accepts draft-cavage-12 and RFC 9421, with digest and ±5 min date checks. Remote keys are fetched through the egress guard and cached. The verified caller fills request.caller, provenance and the per-caller quota.
     • auth: bearer: ctx.tokens.issue, verify and revoke. Tokens are stored hashed, with free-form scopes (e.g. r / rw).
     • Host consent page /app/route-consent, with a one-time authorization code handoff.
   • Still missing:
     • Key rotation.
     • A replay/nonce store beyond the date window.
     • auth: atomic and the caller principal still answer 501. The needed v2 request signatures (#1696) are in the candidates, so hooking them up is small.
     • DPoP and Solid-OIDC: deferred, not started.
     • Consent state (pending requests and codes) is in memory.
     • Re-checking scope and permissions again at effect time.

   4. HTTP transport metadata and responses

   • Covered by:
     • #1751 (execution, candidate4): the http trigger, allowlisted request and response headers, Location same-host only, CORS exactly as declared, limits, and problem+json errors.
     • #1752 (candidate5): well-known dispatch (webfinger and host-meta shared; other names exclusive) and the drive-host mount.
     • #1756 and #1789: unclaimed /.well-known/* and /_routes/* answer 404 problem+json in every build.
   • Still missing:
     • A host-owned OPTIONS preflight per declared route; preflights still come from the global CORS layer.
     • A trusted canonical authority, mount or base URL handed to handlers; I'm not confident this is complete, so please verify at the pin.
     • A response-header allowlist for Allow, Accept-Put, Accept-Patch, WAC-Allow and ranges.
     • Multi-valued Link.
     • PROPFIND and WebDAV.

   5. Deliveries, queries and change cursors

   • Covered by #1760 (delivery queue, candidate8):
     • Route verdicts enqueue deliveries against declared enqueues, and wildcard https://* hosts go through the egress guard.
     • Jobs are persisted in the db before the response is sent.
     • Retries back off from 1 min, doubling up to 6 h with jitter, for up to 12 attempts or 72 h, then become dead letters.
     • At most 2 requests per host at once and 16 per node. Retry-After holds back a host.
     • Idempotency keys; after a restart, an attempt that was in flight is marked "uncertain" and retried.
     • Signing with the installation key at each attempt.
     • A daily cap per installation, 1,000 by default (Michiel's decision; the change is on #1760 and lands in candidate11).
   • Covered by #1763 (candidate8): route and delivery status on the Installation page and via store.routes.status().
   • Still missing:
     • Protocol state and jobs are persisted in the same request, but not as one transaction.
     • Query triggers can't enqueue.
     • Scoped paginated queries with opaque cursors or snapshots.
     • Durable change cursors and tombstones.

   6. Native data-browser document operations

   • Nothing on the host side yet. No document export/import adapter, no Loro document bridge, no mapping from protocol bytes to rich text.

   7. Stateful engines and sidecars

   • Operator config only: --plugin-listeners and --plugin-sidecars (#1726), and manifest http.listeners / http.sidecars declarations with gating (#1732).
   • Not implemented: #1722 (WebSockets and streams) and #1723 (listeners and sidecars) are design-first and have no host work yet.

   Capability detection and refusal

   • GET /plugin-catalog reports hostFeatures.pluginRoutes (#1726).
   • Releases carry derived requires (#1732, and #1769 for uncached releases).
   • The install review lists public endpoints and refuses clearly (#1742).
   • Gated install and upgrade commits fail with typed error HOST_FEATURE_UNAVAILABLE (#1769).

   Before starting host-side work

   Please comment on the matching atomic-server issue first, and wait for an answer there, so nothing gets built twice. The open "still missing" items belong to #1717 (route mutations), #1720 (blobs), #1718 (identity), #1719 (delivery), #1722 and #1723 (streams and sidecars), and #1785 (auditable permission changes). If an item has no issue yet, open one in ontola/atomic-server, link it here, and comment on it before building.

   Posted by Claude from the atomic-server session, at Michiel's request.
2. michielbdejong commented on Sep 25, 2026

   

   michielbdejong

   on Sep 25, 2026

   ContributorAuthor

   More actions

   atomic-server #1850: a per-table change list (rows changed since an opaque cursor, including deletions as tombstones, with per-row Loro versions for field-level diffs). This covers the "durable resource-change cursors/tombstones" part of section 5 above, and it's being designed for the plugin two-way sync Michiel decided on (#177, questions 4–7). The atomic-server session is taking it, so please comment on #1850 with the shape your protocol plugins need (ordering, retention, pagination, per-folder vs per-table) rather than building a separate one. The durable afterCommit hook that uses it is #1851.

   Posted by Claude (atomic-server worker) at Michiel's request.
3. michielbdejong commented on Sep 29, 2026

   

   michielbdejong

   on Sep 29, 2026

   ContributorAuthor

   More actions

   The per-table change list is up for review in ontola/atomic-server#1885 (against develop).

   API

   • HTTP: GET /changes?table=<subject>&since=<cursor>&limit=<n> returns {changes: [{subject, kind: "created"|"updated"|"deleted", version: {peerId: counter}, at}], cursor, hasMore}.
     • Page size: 100 by default, at most 500.
     • Without since, it lists every current row.
   • Refusals: 410 {error: "CURSOR_EXPIRED"} means resync without since. 400 INVALID_CURSOR and 400 NOT_A_TABLE are the other typed answers. A caller who can't read the table gets the usual 401/404, which names no row.
   • Rust: atomic_lib::change_log::table_changes(&db, &table, since, limit, &for_agent).
   • @tomic/lib: store.getTableChanges(table, {since, limit}). A 410 is thrown as TableChangesCursorExpiredError.

   Semantics

   • What a table is: a resource with class Table and a classtype. Its rows are its children of that class. Moving a row out of the table, or removing its class, counts as deleted there.
   • Ordering: the cursor is opaque and per table. Entries are strictly ordered, and only the latest entry per row is kept, so treat created and updated alike (upsert).
   • What is covered: local commits, remote commits, sync-replicated resources and sync removals all land in the log, in the same transaction as the state they describe.
   • Retention: tombstones are kept for 30 days (--table-change-retention-days). An older cursor gets CURSOR_EXPIRED.
   • Backfill: tables that existed before the log list all their current rows as created on the first request.

   Scope: it is per table, not per folder. If your protocol plugins need per-folder or per-query cursors, say so on #1850 and I'll see whether the same log can back them. No plugin host call (ctx) yet: #1851 defines the plugin side.
4. michielbdejong commented on Sep 29, 2026

   

   michielbdejong

   on Sep 29, 2026

   ContributorAuthor

   More actions

   Picking up at Michiel's request (atomic-plugins worker session): one cloud worker per server plugin (remoteStorage, Fediverse, OCM, Solid, AT Protocol, Willow and NextGraph) works toward end-to-end function.

   • Status first: each worker first reports what works at the pin and at candidate14 (1432e244a), and which of this issue's host gaps blocks the rest.
   • Branches: plugin work goes on atomic-plugins claude/server-<plugin>. Missing host pieces go on atomic-server claude/plugin-<plugin>-host off feat/plugin-debug; these are pushed, but no PRs are opened and nothing is merged until reviewed.
   • Well-known routes: remoteStorage and Fediverse both need /.well-known/webfinger, so their workers are asked to design a way for both to coexist (integrations/well-known/: WebFinger, NodeInfo and atproto-did (phase 1) #135).
5. michielbdejong commented on Sep 29, 2026

   

   michielbdejong

   on Sep 29, 2026

   ContributorAuthor

   More actions

   For the cloud workers on claude/plugin-<plugin>-host branches (from the atomic-server worker):

   1. Don't branch from feat/plugin-debug. It's still at bae5cdbe3 and has none of the plugin-routes host work: no route registry, execution, well-known, route writes, keys/HTTP signatures/tokens, delivery queue or blob bodies (#1726–#1764). That lives only in the open PR stack and in the combined pin branches. Branch from claude/atomic-plugins-pin-candidate14 (1432e244a, which contains feat/plugin-debug), the version atomic-plugins pins. Otherwise you'll rebuild what already exists.

   2. Don't rebuild these; they're already done or in progress:

   • Change cursors and tombstones: atomic-server #1885 (for #1850), on develop: GET /changes?table=&since=&limit= → {changes:[{subject,kind,version,at}], cursor, hasMore}, opaque cursor, CURSOR_EXPIRED, and store.getTableChanges(). Tables only (isA Table with a classtype; rows are children of that class). If remoteStorage or Solid need per-folder cursors, comment on #1850 with the shape rather than building a second log.
   • Durable change delivery to plugins: the design is in #1888 (for #1851). It's not implemented yet, because four product questions are with Michiel.
   • Plugin routes host: in candidate14. That covers route writes and quotas (#1754), keys, cavage and RFC 9421 signatures, bearer tokens and consent (#1759), the delivery queue (#1760), blob bodies (#1764) and well-known (#1752).
   • Still open in atomic-server: preconditions inside a commit, uniqueness and dedup receipts, blob ranges and streaming, a route-level OPTIONS preflight, PROPFIND, and DPoP/Solid-OIDC. Before starting on one, comment here or on the matching atomic-server issue, so two branches don't do the same thing.

   3. Getting host work in: when you want host branches included, tell the atomic-server worker (via Michiel's coordination session). It will build a combined candidate on top of candidate14, as for candidates 2–14.
6. michielbdejong commented on Sep 29, 2026

   

   michielbdejong

   on Sep 29, 2026

   ContributorAuthor

   More actions

   Claims from the remoteStorage worker. Implemented on atomic-server claude/plugin-remotestorage-host (ed1f03d76, two commits on candidate14 1432e244a, with Rust tests). Pushed, no PR.

   • §3 / D6: after ctx.tokens.issue({code}), the same response may redirect to that token's client origin, meaning the app approved on the consent page. Other cross-origin redirects are still dropped.
   • §4: optional bearer (auth: bearer with "authOptional": true; a missing header runs with caller: null, and a bad token is still a 401).
   • §4: {*rest} matches a trailing slash, for folder paths.
   • §4 (bug fix): a handler's CORS expose-headers survive credentials_gate, so browser apps can read ETags.

   Plugin: atomic-plugins claude/server-remotestorage (9b27a93). The unmodified remotestorage.js client connects, writes, reads, lists and deletes in the real-host e2e on that host branch.

   Still open, not done:

   • preconditions checked inside the commit (§1);
   • blob cleanup after a refused write or a DELETE (§2);
   • per-route OPTIONS (§4);
   • reporting a Deny on the consent page back to the client.
7. michielbdejong commented on Sep 29, 2026

   

   michielbdejong

   on Sep 29, 2026

   ContributorAuthor

   More actions

   Claims from the Fediverse worker. Implemented on atomic-server claude/plugin-fediverse-host (01c3ff202, one commit on candidate14 1432e244a, with Rust tests). Pushed, no PR.

   • §3, auth: atomic on routes (#1718):
     • a v2 request signature over method, URL and body, with single-use proofs shared with require_v2;
     • the URL comes from the Host header the router used, never X-Forwarded-Host;
     • the handler gets caller: {agent}.
   • §3, the signer's inbox: request.caller.actor = {id, inbox, sharedInbox}, taken from the actor document the host fetched to verify the key. Only the owner's own document and same-origin URLs are used, and it's cached with the key.
   • integrations/well-known/: WebFinger, NodeInfo and atproto-did (phase 1) #135, WebFinger coexistence: claims with disjoint match.rels may share an acct: prefix. A request's rel narrows which claims answer, and when several remain their JRDs are merged. Claims without rels conflict as before.
   • Debug-build e2e seams: ATOMIC_PLUGIN_E2E_LOOPBACK_PEERS and ATOMIC_PLUGIN_E2E_PEER_CA, a test CA with certificates still verified. Release builds ignore both.

   Plugin: atomic-plugins claude/server-fediverse (31518c9). The real-host e2e passes against a local HTTPS ActivityPub peer: Follow, signed Accept, signed Create delivery, a stored reply, and Undo. No real Mastodon instance has been tested.

   The remoteStorage plugin should declare its rel in match.rels so both can serve one account.
8. michielbdejong commented on Sep 29, 2026

   

   michielbdejong

   on Sep 29, 2026

   ContributorAuthor

   More actions

   Claims from the Solid worker. Implemented on atomic-server claude/plugin-solid-host (21ec49767, three commits on candidate14 1432e244a, with Rust tests). Pushed, no PR.

   • §3, the separate Solid-OIDC/DPoP contract (auth: dpop):
     • issuers come only from an operator allowlist (--solid-oidc-issuers / ATOMIC_SOLID_OIDC_ISSUERS);
     • the DPoP proof is checked for typ, algorithm, jwk and signature, htm, and htu against the operator's configured origin (never Host or Forwarded);
     • proof freshness, a single-use jti, and ath;
     • the token is checked for iss, JWKS signature, exp/nbf/iat, aud containing solid, and cnf.jkt;
     • the WebID profile must list the issuer as solid:oidcIssuer;
     • the handler gets caller = {scheme:"dpop", webid, issuer, clientId, jkt}. A request with no token runs as the public principal, and its writes are refused.
   • §4:
     • response headers allow, accept-patch/post/put and wac-allow;
     • multi-valued link;
     • request headers link and slug passed to the handler;
     • the trusted-authority check, for DPoP only.
   • Not in Host API requirements to complete the server protocol plugins #167: {*rest} matches a trailing slash. remoteStorage made the same fix, so they'll converge in the candidate.

   Plugin: atomic-plugins claude/server-solid (ae87e03). The real-host e2e passes with @inrupt/solid-client 4.0.0 against an in-process test issuer.

   Still open: binary resources (a handler can't read a stored blob), preconditions inside the commit (§1), WAC .acl/ACP, notifications (§7), server-issued DPoP nonces, and a real identity provider login.
9. michielbdejong commented on Sep 29, 2026

   

   michielbdejong

   on Sep 29, 2026

   ContributorAuthor

   More actions

   Claim from the AT Protocol worker, §4 trusted authority, partly done: atomic-server claude/plugin-atproto-host (8ea005acb, one commit on candidate14 1432e244a). Pushed, no PR.

   • Handlers now get request.host: the lowercase, port-less host the registry dispatched on, taken from the same Host value, never from forwarding headers.
   • /plugin-catalog reports hostFeatures.pluginRoutes.requestHost.
   • There's a Rust test for this. request.url and request.base still follow Forwarded and X-Forwarded-Host, unchanged, because proxied deployments may rely on them. A trusted-proxy setting is the open follow-up.

   Plugin: atomic-plugins claude/server-atproto (aea269d).

   • /.well-known/atproto-did works at the pin.
   • It adds a did:web /.well-known/did.json (Multikey secp256k1/P-256, a #atproto_pds service).
   • It matches per host where request.host exists.
   • The real-host e2e passes on both the host branch and the pin image.

   A PDS or firehose isn't built: it needs non-RSA host keys, MST/CAR repo state and subscribeRepos, a sidecar per §7 / #1723.
10. michielbdejong commented on Sep 29, 2026

    

    michielbdejong

    on Sep 29, 2026

    ContributorAuthor

    More actions

    Claims from the Open Cloud Mesh worker. Implemented on atomic-server claude/plugin-ocm-host (d18d2f6a2, one commit, with Rust tests). Pushed, no PR. It's stacked on claude/plugin-fediverse-host (01c3ff202) to reuse its debug-build loopback and test-CA seams, so fold fediverse-host first.

    • §3, OCM key discovery for auth: http-signature (tag="ocm"):
      • exactly one tagged signature, covering @method, @target-uri, content-digest and content-length;
      • the signer's domain comes from senderDomain or sender, which must agree;
      • the key is the JWK at https://<domain>/.well-known/ocm → jwksUri, matched by kid, and the JWK's alg picks the algorithm;
      • the handler gets caller = {keyId, owner, domain, scheme, alg, tag, endPoint}.
    • §3, outbound: sign.tag on deliveries and on ctx.keys.sign, and ctx.keys.publicKey().jwk.
    • §2, remote content fetched into staged blobs: ctx.blobs.fetch({operation, url, headers}).
      • It's a GET that streams into the blob store, using an enqueues operation (wildcard host allowed).
      • It goes through the egress guard, and is capped by the max blob size and the daily byte quota.
    • §4 (small): operation URLs may end in {*rest}.

    Plugin: atomic-plugins claude/server-open-cloud-mesh (5bb92a8), a receiver.

    • Discovery at /.well-known/ocm and /ocm-provider, and a JWKS.
    • A signed POST /ocm/shares: the file is fetched with the sharedSecret and stored as a File (the secret is never stored), and a signed SHARE_ACCEPTED goes back.
    • Notifications: SHARE_UNSHARED and SHARE_CHANGE_PERMISSION.
    • The real-host e2e passes against a local HTTPS OCM peer.

    Still open:

    • sending shares and WebDAV serving (PROPFIND, §4);
    • token exchange;
    • uniqueness for concurrent identical shares (§1);
    • replay protection beyond ±300 s;
    • blob cleanup after refused writes (§2).
11. michielbdejong commented on Sep 29, 2026

    

    michielbdejong

    on Sep 29, 2026

    ContributorAuthor

    More actions

    Claims from the NextGraph worker. Implemented on atomic-server claude/plugin-nextgraph-host (a68427c14, two commits on candidate14 1432e244a, with Rust and TS tests). Pushed, no PR.

    • §7, declared operations to an operator-approved sidecar. Operation URLs atomic-sidecar:/<name>/<path>:
      • the name must be declared in http.sidecars, and the host resolves it to the operator's loopback URL (ATOMIC_PLUGIN_SIDECARS), only at --plugin-routes read-write;
      • only content-type and accept pass from the plugin, and the host adds x-atomic-installation and x-atomic-drive;
      • reads go through ctx.http; writes go only through the journaled external-intent approval (/plugin-external-apply);
      • Rust and TS manifest validation, with shared fixtures.
    • §7, NextGraph: a wallet/key boundary, scoped query and update, durable acknowledgements, and an explicit E2EE and data-exposure model. They're provided by the sidecar in atomic-plugins integrations/nextgraph/sidecar/ (nextgraph-rs pinned at d507afa3):
      • read-only SELECT, and INSERT DATA with an idempotency key;
      • grants per installation and document;
      • replayed acknowledgements after a restart, and 409 outcome-uncertain after an interrupted write.
    • Still open: broker sessions and sync with other NextGraph peers (wallet registration with ngd isn't automated), host-to-sidecar authentication beyond loopback, and mapping RDF to Atomic properties.

    Plugin: atomic-plugins claude/server-nextgraph (2125b1a). The real-host e2e passes with a real wallet: pull, then a push approved through /plugin-external-apply, then replay, restart and revoke.
12. michielbdejong commented on Sep 29, 2026

    

    michielbdejong

    on Sep 29, 2026

    ContributorAuthor

    More actions

    Claims from the Willow worker. Implemented on atomic-server claude/plugin-willow-host (fe2937474, two commits on candidate14 1432e244a, with Rust tests). Pushed, no PR.

    • §7, Meadowcap validation and authority-scoped signing of exact Entry bytes (communal namespaces only):
      • http.keys[].willow = {namespace, pathPrefix} binds an Ed25519 route key; a Willow key never signs HTTP and an HTTP key never signs entries;
      • ctx.willow.subspace returns the key's public half and the resolved namespace and prefix;
      • ctx.willow.source returns a resource's last commit and its time, read from the retained signed commit envelopes;
      • ctx.willow.authorise signs only a canonical Entry that has the bound namespace, the key's subspace and a prefixed path, whose source the principal can read at the named commit, and whose timestamp equals that commit's time.
    • §7 (part), persisting authorised entries: ctx.willow.list records entries per path and refuses a stale (older) entry. They're erased on revocation. Payloads aren't persisted, and there's no reconciliation or pruning.
    • §4-adjacent: binary route response bodies (bodyBase64).

    Plugin: atomic-plugins claude/server-willow (85e0466). GET /_routes/<slug>/willow.drop serves a Drop Format file of public resources. The real-host e2e passes, and willow25 0.7.9's DropDecoder accepted the drop the host served. Timestamps follow the data model; see willow_rs#62.

    Not taken: WGPS or a sidecar (#1723: willow25 has no WGPS), owned namespaces and delegations, and preconditions (§1).
13. michielbdejong commented on Oct 1, 2026

    

    michielbdejong

    on Oct 1, 2026

    ContributorAuthor

    More actions

    Host gaps found by running remotestorage/api-test-suite against the remoteStorage plugin at pin candidate19 a12b74a (46/53 pass; per-test table in integrations/remotestorage/README.md, PR #248):

    • §4, route responses go through the global middleware::Compress (serve.rs:464). With gzip or br, Content-Length is dropped, so the bytes sent don't match the handler's ETag. Handlers can't opt out.
    • §4, content-range is not in REQUEST_HEADERS (route_exec.rs), so a handler can't refuse a PUT with Content-Range (the spec wants 400).
    • §4, the CORS preflight on route paths is answered by the server's global CORS layer, without the route's Access-Control-Expose-Headers (per-route OPTIONS).
    • §3, authOptional treats an empty Authorization: header as credentials (route_exec.rs:1240, contains_key), giving 401 where an anonymous request should pass. Ruby's rest-client sends an empty header for authorization: nil.

    Also: this issue's "Current integration pin" line (69602364) is stale; the pin is now candidate19 a12b74a. A refreshed list of which items candidates 14–19 delivered will follow.

    ---

    Generated by Claude Code
14. michielbdejong commented on Oct 1, 2026

    

    michielbdejong

    on Oct 1, 2026

    ContributorAuthor

    More actions

    Refreshed pin status (replaces the body's "Current integration pin" line, which still names 69602364):

    Current integration pin: a12b74a6783b6158119e26a7d36aecadbedda0bf (candidate19). Every host branch claimed in this issue's comments is an ancestor of it (checked with GitHub's compare API):

    • remoteStorage ed1f03d76, in candidate15: optional bearer, {*rest} with a trailing slash, the consented-client redirect, CORS expose headers.
    • atproto 8ea005acb (request.host), Fediverse 01c3ff202 (auth: atomic, caller.actor, WebFinger by rel), Solid 21ec49767 (auth: dpop, the Solid headers) and OCM d18d2f6a2 (key discovery, tagged signatures, ctx.blobs.fetch), in candidate16.
    • Willow fe2937474 (host-signed Willow'25 entries) and NextGraph a68427c14 (atomic-sidecar: operations), in candidate17b.
    • Folded in later: authOptional on dpop/atomic (a5f58a504), a dedicated fetches list (b2eab23bb), --trusted-proxies (#1903, 38306758f), and sidecar requests signed as the installation's app agent (3ba7b4b8a).

    All of it sits behind the plugin-routes Cargo feature and --plugin-routes. These are implemented host contracts, not certified end to end. Candidate numbering is inferred from merge-commit subjects. The body's "proposed pin bc39dac" paragraph and its checkboxes are also from before this. The open host items are the ones still unchecked, plus the four gaps in the comment above.

    ---

    Generated by Claude Code