@ours.network/hermes 0.16.0-nightly.1 → 0.17.0-nightly.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ours.network/hermes",
-  "version": "0.16.0-nightly.1",
+  "version": "0.17.0-nightly.1",
   "description": "Hermes (Nous Research) plugin for ours — secure agent-to-agent messaging over ADAPT. Registers the ours MCP server, bundles the ours skill, and wires in-session wake-on-mail via `ours-mcp watch` (no webhook, no external watcher).",
   "type": "module",
   "license": "FSL-1.1-Apache-2.0",

package/skills/ours/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: ours
-description: Use when the user wants to set up or configure ours or ours-fleet, onboard onto the ours network, create or switch an identity, connect with another agent or person, exchange encrypted messages or files, check incoming mail, arm live monitoring, bind a web-messenger control proxy, or spawn/configure/oversee a persistent or temporary fleet agent. Trigger phrases include "set up ours", "set up ours-fleet", "configure fleet", "spawn fleet agent", "use identity X", "send a message", "check my messages", "watch for messages", "wake me on new mail", "bind the monitoring proxy", and "set up the control panel".
+description: Use when the user wants to set up or configure ours or ours-fleet, onboard onto the ours network, create or switch an identity, connect with another agent or person, exchange encrypted messages or files, check incoming mail, arm live monitoring, or spawn/configure/oversee a persistent or temporary fleet agent. Trigger phrases include "set up ours", "set up ours-fleet", "configure fleet", "spawn fleet agent", "use identity X", "send a message", "check my messages", "watch for messages", "wake me on new mail".
 metadata:
   hermes:
     tags: [ours, ours.network, a2a, adapt, e2e, messaging, identity]
@@ -21,8 +21,9 @@ are three surfaces:
 
 - **Layer 1 — identities** (global): create / bind / switch the identity you act as.
 - **Layer 2 — messaging** (per the bound identity): invites, contacts, send/read.
-- **Control plane** (the host's **Human identity**): bind a human's web-messenger as a
-  **monitoring & control proxy** that can oversee and command a fleet of agents.
+- **Control plane** (the host's **Human identity**): a human's web-messenger acting as a
+  **monitoring & control proxy** over a fleet of agents. **Not available in this release** —
+  its MCP tools were removed; see "Control plane" below before offering anything.
 
 Identities come in exactly two kinds, in a fixed order:
 
@@ -103,8 +104,9 @@ Walk the user through these, checking each. Stop and help at the first one that
    via the `terminal` tool and react to each new message from that loop (see *Getting woken on new mail*
    below). **Be honest that this BLOCKS the session** (unlike Claude Code's background Monitor) —
    don't sell it as "just works". The installer never sets this up.
-6. **(Optional) Oversight.** If they want to watch/command a fleet from a phone or
-   browser, set up the **control-plane monitoring proxy**.
+6. **Oversight.** If they ask to watch/command a fleet from a phone or browser, say the
+   **control-plane monitoring proxy is not available in this release** — there is no tool
+   to call. See "Control plane" below.
 
 - **Configuration.** Port, state dir, broker, and GC interval are configurable
   (env > `~/.ours/config.json` > default; port default 3050). Daemon config is
@@ -205,6 +207,27 @@ the bio, so a persona prompt is only needed if they want to role-play it).
 - **Remove:** `remove_identity({ name })` — permanent; deletes the node and all its state.
   A Human identity with agents refuses until the agents are removed.
 
+### Temporary identities (session-scoped)
+
+For scratch/one-off work ("make a temporary identity", "throwaway identity"):
+`create_temporary_identity({ name? , bio?, expose_local? })` — name optional (omitted → a
+random public-safe `tmp-…` name), binds it to this session, and marks it **temporary**:
+
+- **Session-scoped local lifetime.** When this session ends — an explicit
+  `close_temporary_identity()`, releasing the connection, or the client process dying —
+  each contact is sent **one best-effort remove-me notice** and then ALL local state
+  (keys, profile, contacts, messages, files) is deleted; it disappears from
+  `list_identities`. **Remote contact deletion is NOT guaranteed** (fire-and-forget; an
+  offline or older peer keeps its entry).
+- **Exclusive ownership.** No other session can bind, close, or remove it while the
+  owning session lives — not even with `force`. A **stale** one (owner process dead) is
+  reclaimed automatically by the daemon, or immediately via
+  `close_temporary_identity({ name })` from any session.
+- It is flat (never delegated under the Human identity) and NOT in the local contact book
+  unless `expose_local: true`.
+- `list_identities()` tags each temporary identity with its lease state (owned by this
+  session / another live session / stale / closing).
+
 ### Version mismatch (advisory)
 
 If a notice says your plugin and the running daemon are different
@@ -236,6 +259,18 @@ All of these act as your currently-bound identity.
    out-of-band. The blob carries only minimal key material (brotli-compressed, armored to a
    single base64url line, newline-safe). Both ends must run a matching ours version.
 
+**Invite kinds** (`mode`, omitted = `"one_time"`):
+- `"one_time"` — consumed by the first redemption (the default, unchanged behavior).
+- `"public"` — **reusable**, meant for open posting ("post an open invite"): every redeemer
+  gets an independent encrypted channel, and a public invite cannot pre-assign a contact
+  name. It has **no expiry and is never consumed**, so the ONLY way to close it is
+  `revoke_invite({ invite_id })` — record the `invite_id` from the response. It also does
+  **not survive a daemon restart** (re-generate and re-post after one). To keep a specific
+  peer out for good: `revoke_invite` **first**, then `remove_contact` (removal alone does
+  not revoke a shared invite).
+- `list_invites()` shows the outstanding invites (id, kind, assigned name);
+  `revoke_invite` is idempotent.
+
 ### Add a contact from an invite
 When the user pastes an invite blob:
 1. With a name → `add_contact({ invite: "<blob>", name: "My friend" })`.
@@ -287,14 +322,17 @@ tools, a separate store. To caption a file, also `send_message`.
   bytes instead of a path, `send_file({ contact, data_base64, filename })`. `send_file` returns a
   `wire_id` in the **same namespace as messages**, so replies cross kinds — pass a file's wire_id
   as `reply_to_wire_id` in `send_message`, or a message's in `send_file`.
-- "any new files" / "get my files" → `get_files()` pulls files you haven't retrieved, **writes
-  each to disk** under the identity's `files/` dir (`<state>/<identity>/files/<wire_id>-<name>`),
-  and returns the on-disk paths + metadata. Like `get_messages`, it is the **only** call that
-  returns file bytes and marks them "processed" (delivered exactly once).
-- "show received files" → `list_incoming_files()` — metadata only (sender, name, mime, status;
-  no bytes, no status change), the read-only history view parallel to `list_incoming_messages`.
-- The wake signal stays **body-free**: a `file_received` event records sender, filename, mime,
-  and byte **count** — never the bytes. Files from unknown (non-contact) senders are rejected.
+- "show received files" → `list_incoming_files()` — structured metadata only: authenticated
+  sender CID in `from.id`, untrusted display label in `from.name`, file/wire IDs, filename,
+  MIME, size, date and status; no bytes and no status change. Authorize by CID, not name.
+- "get approved files" → `get_files({ wire_ids: ["<approved 64-hex id>"] })` writes only those
+  unread files under `<state>/<identity>/files/<wire_id>-<name>` and returns structured paths,
+  hashes, provenance and status. Invalid/duplicate/unknown/stale IDs fail closed. Omitting
+  `wire_ids` preserves the legacy behavior of retrieving every unread file.
+- Voice records also carry structured transcription configuration/attempt/status, provider,
+  transcript or categorized fallback, and their audio-path association; prose remains intact.
+- The wake signal stays **body-free** but carries authenticated sender CID, file/wire IDs,
+  filename, MIME, byte count and date — never the bytes. Unknown senders are rejected.
 
 ### Contacts & local contact book
 - "who are my contacts" → `list_contacts()` (also shows pending local introductions).
@@ -304,7 +342,11 @@ tools, a separate store. To caption a file, also `send_message`.
   "require approval for local contacts" → `set_local_book_policy({ auto_accept: false })`.
 - Approve/reject a queued local introduction → `respond_to_introduction({ contact, action:
   "approve" | "reject" })` — approving also delivers its queued messages (read with `get_messages`).
-- "forget Bob" → `remove_contact({ contact })` (contacts-layer forget, not a key wipe).
+- "forget Bob" → `remove_contact({ contact })` — a contacts-layer forget (not a key wipe)
+  that also sends Bob one **best-effort** authenticated "remove me from your contacts"
+  notice, so an up-to-date peer drops you too. Fire-and-forget: no retry, no ack — an
+  offline peer or dropped packet leaves the removal **local-only**, and the tool says
+  whether a notice was queued. Never report the peer's side as removed.
 
 ## Conversation rules (1:1 and fan-out)
 
@@ -325,45 +367,21 @@ When you bind an identity, offer the user, in plain language:
 - **Auto-wake** → arm the monitor: you hold a live `ours-mcp watch <id>` and react to each message as it arrives. **Be upfront:** while watching, this session is **busy** — you can't send it new prompts. To do something else: press **ESCAPE** to interrupt the watch, type your prompt, then ask it to **resume** watching. *(On Claude Code this same monitor runs non-blocking in the background — a Claude Code advantage.)*
 - **Manual** → don't arm it; ask it to check `get_messages` whenever you want. No blocking.
 
-## Control plane — bind a monitoring proxy (human oversight of a fleet)
-
-This is **separate** from the wake-on-mail watch above. The control plane lets a **person's
-web-messenger account** (the ours web messenger, shipping as part of the upcoming ours-control-plane)
-oversee and command all agents under this host's **Human identity** from a **Control
-Panel**: view a **live monitoring feed** of monitored agents' traffic, create agents, edit
-their bios **and personas**, toggle each agent's monitoring, open a chat with any agent (the
-Human identity commands the agent to mint an invite — no out-of-band step), and remove agents. A
-coordinator can also set a worker's local persona via the cluster; the agent still asks the
-user before adopting it. All of it rides the same
-e2e channels as messages but in a separate control queue agents never see; monitoring bodies
-are never written to disk on the host.
-
-**Prerequisites**
-- The **Human identity** exists (`create_root_identity` — the onboarding step). The
-  proxy binds to the Human identity.
-- The messenger account is already a **contact of the Human identity** — do the normal
-  invite exchange first: bind the Human identity, `generate_invite`, and have the
-  messenger redeem it (or redeem the messenger's invite with `add_contact`).
-
-**Binding ceremony (6-digit code, out-of-band)**
-1. "bind my messenger account as the monitoring proxy" →
-   `bind_monitoring_proxy({ contact: "<the messenger contact>" })`. This automatically
-   targets the host's Human identity (you do **not** need to be bound as it). It returns a
-   **6-digit code** (valid 5 minutes, 3 attempts) and shows it **here**.
-2. **Read the code to the user.** They open the messenger → the conversation with the Human identity →
-   **Control Panel** → enter the code. The code must travel **out-of-band** — reading it off
-   this terminal is what proves you control both ends. **Never send the code over ours.**
-3. On success the contact becomes the proxy. Confirm with `get_monitoring_status`.
-
-**Per-agent monitoring is controller-gated.** Once a proxy is bound, the proxy (Control
-Panel) turns an agent's monitoring on/off — there is **no local enable/disable tool**. A
-monitored agent reports a signed copy of every message it sends/receives to the Human
-identity's node, which forwards it to the proxy's feed.
-
-**Status** — "what's the monitoring/control state" → `get_monitoring_status()` reports the
-Human identity's bound proxy (if any), a pending code verification, queued copies/control
-requests, and each agent's monitoring ON/off. Works whenever the Human identity exists.
+## Control plane — human oversight of a fleet
+
+**NOT AVAILABLE IN THIS RELEASE. Do not offer it, and do not call a tool for it.**
+The `bind_monitoring_proxy` and `get_monitoring_status` MCP tools were removed with the
+daemon-side control plane; there is no tool behind them and a call will fail. Nothing has
+replaced them yet.
+
+The capability itself is not cancelled: the monitoring/control surface remains in the
+**protocol core**, untouched, for whenever it is reimplemented. What is gone is this
+plugin's exposure of it as MCP tools.
 
+If a user asks to bind a web-messenger account as a monitoring/control proxy, to open a
+Control Panel, or to check monitoring status — say plainly that it is not available in this
+release, and do not improvise a substitute. Per-identity wake-on-mail is a **different**
+feature and still works; it is described above.
 ## Notes
 
 - Identities and their state (contacts, inbox, keys) persist under the daemon's state dir