@muretai/agent-entry 1.6.1 → 1.6.3

package/README.md

@@ -104,14 +104,17 @@ answers questions and hands off nothing, is a signed claim you cannot keep.
 | option | default | what it does |
 |---|---|---|
 | `skills` | `[]` | the menu above — what a visitor learns before knocking |
-| `openDoor` | `true` | publishes `muretai.open_door`: the field that tells a visiting agent it may message you with no introduction |
+| `openDoor` | `true` | publishes `agentEntry.open_door`: the field that tells a visiting agent it may message you with no introduction. The same fact is emitted under the older `muretai.open_door` spelling beside it — read either, write the neutral one |
 | `anonymousLane` | `false` | also answer **unsigned** inquiries. They create no account row, and the lane is capped entry-wide — an unauthenticated caller must never become an unmetered signing oracle |
-| `anonRatePerMin` | `30` | anonymous replies per minute, entry-wide. Signed senders are not bound by it: they are attributable and already in your ledger |
+| `anonRatePerMin` | `30` | anonymous replies per minute, entry-wide |
+| `signedRatePerMin` | `60` | signed replies per minute **per account**, ON by default. Attribution is not scarcity: a `did:key` costs nothing to mint, so being in your ledger was never a bound |
+| `signedRatePerMinTotal` | `600` | signed replies per minute for the **whole entry**. Free identity defeats per-identity metering by definition, so only the aggregate resists a flood |
+| `guest` | `false` | put the door on a path of its own and leave `GET /` alone entirely — for a site that is keeping its front page. A `GET` on a guest mount answers **405 with `Allow: POST, OPTIONS`**, never 404: the address is signed into a public card, and hiding a published address conceals nothing |
 | `maxAccounts` | `50000` | how many accounts the in-process ledger holds |
 | `domains` | none | the domains this entry speaks for (see below) |
 | `basePath` | from `baseUrl` | the path this entry answers at, derived rather than set beside it |
 | `wbaVerifiers` | none | a JWKS document (`{"keys":[…]}`) of Ed25519 keys whose holders this entry should **recognise** on inbound signed requests (Web Bot Auth / RFC 9421 — see *Who is knocking*). Recognition only adds `env.wba_did` and a visit count; it never changes a verdict |
-| `observer` | none | called once per message with the same envelope your responder gets, **after** the verdict — for counting, logging, analytics. It cannot matter: its return is discarded, a throw is swallowed, a promise is never awaited, so a slow or broken watcher cannot delay or change one byte of the signed reply. See [Counting visits](#counting-visits-without-handing-over-who-they-are) |
+| `observer` | none | called once per message with the same envelope your responder gets, **after** the verdict — for counting, logging, analytics. It cannot matter: its return is discarded, a throw is swallowed, a promise is never awaited, so a slow or broken watcher cannot delay or change one byte of the signed reply. See [Counting visits](#counting-visits-without-handing-over-your-customer-list) |
 | `howToUrl` | none | a page a keyless visitor is pointed at as a worked example. **Empty means omitted** — the refusal already teaches the whole recipe without it, and a reference implementation must not stamp somebody else's docs host into every door built from it. Only set it to a URL you operate, and only after checking it resolves |
 | `name`, `description`, `version` | — | the card's own words. `description` is the line a person reads in a directory listing — and the right place to say what you record about visitors, since it is fetched **before** the knock |
 
@@ -498,8 +501,10 @@ navigator.modelContext.registerTool({
 ```
 
 `MY_DID` is the DID your Agent Entry prints at startup — **the same one**, from the same seed.
-That is the only rule when running both: a mismatch trips the visitor's impersonation guard,
-which is what it is there for.
+That is the only rule when running both, and **nothing here enforces it** — this package never
+sees your in-page handoff. A mismatch is a site publishing two different identities for one
+origin, which a careful visitor may notice and a careless one will not, so treat it as your
+invariant to keep rather than a guard you are behind.
 
 What the shop gets out of it: the moment that signed message arrives, an account exists. No
 signup form, no password, nothing to reset — the sender's key is the account. Come back
@@ -529,8 +534,8 @@ and it is not one. It is the upgrade path:
   ledger back to gate, greet or rate-limit, so a fire-and-forget sink records visiting
   agents with no database anywhere. Use `observer` for it, never your responder: watching
   a visit should not be an edit to the code that decides what to say. See
-  [Counting visits](#counting-visits-without-handing-over-who-they-are) below for the
-  whole pattern, including the one rule that shapes it — **a DID is not a page view**,
+  [Counting visits](#counting-visits-without-handing-over-your-customer-list) below for the
+  whole pattern, including the one rule that shapes it — **a DID is not a cookie**,
   so what leaves your box is a salted digest, never the identifier itself. A sink cannot
   be read back during a request: it counts customers, it cannot recognise one. It
   replaces a log line, not the store above — none of the recommended features stand
@@ -560,7 +565,7 @@ What the entry now handles for you at the HTTP layer, so you do not have to:
   which says a server must accept the absolute form: this endpoint answers exactly the
   address its card names, and the refusal says so.
 
-## Counting visits without handing over who they are
+## Counting visits without handing over your customer list
 
 You will want to know how many agents knocked, how many came back, and what they asked. All
 three are answerable — and how you answer them decides whether you are counting your visitors
@@ -571,11 +576,18 @@ envelope, after the verdict, so watching a visit stops being an edit to the code
 what to say. It cannot matter: its return is discarded, a throw is swallowed, a promise is
 never awaited — a slow or broken watcher cannot delay or change one byte of the signed reply.
 
-**The rule that shapes everything else: a DID is not a page view.** A visitor hands you one in
-order to transact with **you**, and here first contact *is* the account — there is no signup
-form where they agreed to anything else. Forwarding the raw value to an analytics vendor shares
-a durable identifier its owner never offered them, silently, on a surface with no consent
-dialog and no visitor who could decline. So split it:
+**The rule that shapes everything else: a DID is not a cookie, and it is not a throwaway
+either.** Nobody imposed it — the visitor read your card *before* knocking, and an owner who
+wanted this conversation kept apart would have sent a different agent, because an owner runs
+several and each is a distinct agent with its own lasting identity. But the one that did knock
+means to keep the key it used: that is how it gets recognised, introduced and trusted anywhere on
+the network, so it is closer to a professional's name than to a tracking cookie.
+
+Which is exactly why the raw value should not travel onward. **The DID is genuinely durable, and
+you were given it so that YOU could reach them again.** Widen that purpose and nothing happens to
+you legally, which is the part worth understanding: the owner simply stops sending that agent to
+you. Silently, at no cost, and you never learn you lost them — not one data point, the whole
+relationship. So split it:
 
 - **What leaves** — a salted digest and a few shape facts. Never the DID, never the text.
 - **What stays** — the relationship (who, how many, first and last seen) in your own store,
@@ -642,7 +654,7 @@ in the same breath, in plain words.
 
 This module is not alone. A Python reference implements the same contract, and the two are
 held to **identical verdicts** by an acceptance suite: it runs the same attack battery
-against both, drives this module against `testdata/wire_vectors.json` byte for byte, posts
+against both, drives this module against the same wire vectors byte for byte, posts
 identical bytes to each over real sockets — down to the HTTP framing — and requires the same
 status, the same account outcome and the same signed reply from both. If you write a third
 implementation, that suite is the gate.
@@ -671,9 +683,16 @@ because a shared library would only ever have covered the parts they happen to s
 suite posts identical bytes to both, down to the HTTP framing, and requires the same status,
 the same account outcome and the same signed reply.
 
-`testdata/wire_vectors.json` is the part of that gate you can run here: it pins the canonical
-JSON, the signing payloads, the card envelopes and the did:key round-trips this module must
-reproduce byte for byte.
+**The part of that gate you can run here ships in this package.** `npm test` executes
+`conformance/run.mjs` against `conformance/vectors.json` — the canonical JSON, the signing
+payloads, the card envelopes and the `did:key` round-trips this module must reproduce byte
+for byte. No network, no checkout of ours, nothing to ask us for:
+
+```bash
+npm test
+```
+
+Write a third implementation and point it at the same vectors.
 
 ## What this is part of
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@muretai/agent-entry",
-  "version": "1.6.1",
+  "version": "1.6.3",
   "description": "Make your website answer AI agents: an A2A agent endpoint that verifies who is knocking, opens an account for them and replies signed, in one HTTP round trip. Zero dependencies. Pairs with llms.txt and WebMCP.",
   "type": "module",
   "main": "muretai-agent-entry.mjs",