@nodatachat/mcp 1.3.22 → 1.3.24

package/README.md

@@ -32,11 +32,14 @@ That's it — **no flags**. Self‑serve: registering opens an instant free **sa
 Run the line above with no credential. The server still connects (it never fails the MCP handshake) and exposes two setup tools:
 
 - **`nodata_get_started`** — call it first. It explains what you get and the single next step.
-- **`nodata_connect`** — register once, autoload forever:
-  1. `nodata_connect` (no args) → opens the free signup in your browser (work email + company, ~30s). Your **12‑word recovery phrase** is generated **in your browser — NoData never sees it**. The page shows your org key **once**.
-  2. `nodata_connect` with `api_key: "<that key>"` → saved to `~/.nodata/credentials.json` (chmod 600).
-  3. Restart, or run `/mcp` → every later start loads your identity with nothing to retype. *Registration ≠ login.*
+- **`nodata_connect`** — connect this computer once, autoload forever. Nothing to copy:
+  1. `nodata_connect` (no args) → a page opens in your browser. Sign in (or create a free account), check the code it shows, and click **Approve**. Signing in with a work address sends this computer to your organisation: it joins at once, or waits for your admin, as the organisation chose.
+  2. On approval this computer gets its own device key, saved to `~/.nodata/credentials.json` (chmod 600). No org key is copied anywhere.
+  3. Run `/mcp` → the organisation tools appear, and every later start loads them with nothing to retype.
 
+  From a terminal it is the same: `npx -y @nodatachat/mcp@latest connect`. Only if you must use an org key: `connect --key` (or `nodata_connect` with `step: "key"`) asks for it in a terminal, not shown on screen. Never paste a key into a chat.
+
+If you create an account, its page generates a **12‑word recovery phrase in your browser — NoData never sees it**.
 Keep the 12‑word phrase somewhere safe — it is the only way back into your org, and NoData cannot reissue it.
 
 ---
@@ -126,6 +129,9 @@ The one-sentence version: **encrypt locally, send, revoke later, prove what happ
 | Say | Tool | What happens |
 |-----|------|--------------|
 | "send this file to …" | `nodata_send` | Encrypts on this machine (post‑quantum hybrid) and returns a `/lock/open/<id>#<key>` link. The key rides in the `#fragment`, which never reaches a server; NoData stores ciphertext only. Expiry (≤ 7 days) and max opens. Filed under your org with a signed receipt + `proof_url`. Preview first. |
+| "set rules for this folder" | `nodata_rules` | The rules board for files and folders on this computer: allowed · ask · clean copy only · not allowed, several per path, with conditions (action read/search/run/write, hour, weekday, file type). Enforced by the read gate on every read, search, command and write. Allowing, or removing a restriction, needs the user's own approval. |
+| "send it view-only" | `nodata_send` with `view_only` | The recipient sees it in the browser with no download, the same dial as Seal Studio's view-only switch. |
+| "send it with a code" | `nodata_send` with `code` | The same link, but it opens only with a code you send on another channel (`code: true` generates `XXXX-XXXX`, or give your own, 8+ characters). The link carries a salt; the key is PBKDF2(code, salt) in the recipient's browser, so a forwarded link alone opens nothing and the code never reaches NoData. Burn from the sending machine. |
 | "send it to <NoData address>" | `nodata_send` with `to` | Over the NoData road instead of a link: sealed here to that computer's key (X25519 sealed box), ciphertext only on the server, only the file's type travels unless `share_filename`. The recipient's plate decides — delivered, waiting for their approval, or refused — and the decision is on both organisations' proof chains before anything moves. Up to 10 MB. Preview first. |
 | "let our partner read the files in this folder" | `nodata_expose` | Access, not copies: a partner's computer may **ask** for files inside a folder you choose (`to`: their NoData addresses, `days`), and this computer answers on the road with the **verified clean copy** of each file asked for (`view: clean`, default) — or the original only if you say `view: original`. The request is sealed (NoData does not learn which file), your plate decides who may ask, and each answer is on both sides' proof chains. `list` shows answered/refused counts; `remove` stops it at once. Asks first. |
 | "what's my address / what arrived / who may reach me" | `nodata_inbox` | `address` (a key made on this computer, `~/.nodata/fabric-key.json`, only its fingerprint leaves), `list` (delivered + waiting, sender as their plate discloses it, never content), `open` (unsealed here into a folder, content not returned), `approve` / `block` a waiting sender, `policy` (open · verified · closed, allow/block lists, require purpose, what senders learn about you). Changes ask first. |