docs: user guide and conventions catch up with per-node identity

USERGUIDE said registration submits your public keys "so other members can wrap
GEK bundles for you". Both halves are wrong now: registration creates an account
and nothing else, and nobody wraps anything for a key fetched from the hub. The
API reference and the register body followed the same correction.

CLAUDE.md gains the block a future session needs before touching registration or
anything shaped like a user's public key: keys are born at first contact with a
node and stay there, the hub publishes none, tokens carry no pk_user, and a
scripted signup is now a real account.

Left alone deliberately: first-review.md, docs/poc-v1*.md and poc/spike-results.md
still describe the old JWT and registration. They are records of what was true on
their date, like second-review's verdict table, and draft-v5 is what states the
present.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

1 files changed, 10 insertions, 17 deletions

diff --git a/docs/USERGUIDE.md b/docs/USERGUIDE.md
index f5c10b8..71b0060 100644
--- a/docs/USERGUIDE.md
+++ b/docs/USERGUIDE.md
@@ -62,7 +62,9 @@ MeshBay has three components. Understanding which role each plays avoids a lot o
 
 ### Register
 
-Registration submits your Ed25519 (signing) and X25519 (key agreement) public keys. These let other members wrap GEK bundles for you and let nodes verify your JWT offline.
+Registration creates an account and nothing else: a username, an email, and a value derived from your passphrase that lets the hub check it without ever seeing it.
+
+**No keys are generated here.** An identity keypair belongs to a *node*, not to the hub: one is created the first time you join a given node, encrypted under your passphrase, and left with that node. So an operator who takes their own disk holds a key that is worthless on anyone else's, and the hub has no key directory to publish — which is what finding H3 read.
 
 **Deux modes de génération de clés :**
 
@@ -86,22 +88,13 @@ Implémenté dans `static/keyderive.js`.
 ```
 POST /v1/users/register
 {
-  "username":        "string",
-  "password":        "string (min 8 chars)",
-  "pk_user_ed25519": "base64 raw 32-byte Ed25519 public key",
-  "pk_user_x25519":  "base64 raw 32-byte X25519 public key",
-  "keypair_bundle":  "base64 AES-256-GCM encrypted bundle (web clients only, optional)"
+  "username": "string",
+  "email":    "string",
+  "auth_key": "base64 (PBKDF2-SHA512 of your passphrase — the hub never sees the passphrase itself)"
 }
 → 201 {"user_id": "uuid"}
 → 409 if username is taken
 ```
-
-Passwords are hashed with Argon2id (iterations=3, memory=64 MB in dev;
-target 256 MB / ~500ms in production). Intentionally slow to resist offline attacks.
-
-### Login
-
-```
 POST /v1/users/login
 {"username": "yourname", "password": "yourpassword"}
 → {
@@ -109,12 +102,12 @@ POST /v1/users/login
     "refresh_token":  "opaque 256-bit token (30 days)",
     "token_type":     "bearer",
     "expires_in":     3600,
-    "keypair_bundle": "base64 AES-GCM blob (présent uniquement si enregistré via web)"
   }
 ```
 
-Les clients web utilisent `keypair_bundle` pour récupérer leurs clés privées
-sur un nouvel appareil : déchiffrement local avec le mot de passe via `keyderive.js`.
+Le trousseau ne vient pas d'ici : chaque nœud conserve celui qui lui est propre,
+chiffré par votre phrase de passe, et un nouveau navigateur le récupère auprès du
+nœud auquel il se connecte.
 
 ```bash
 curl -s -X POST https://meshbay.org/v1/users/login \
@@ -754,7 +747,7 @@ All hub endpoints are under `https://meshbay.org`. Node endpoints are under `htt
 
 | Method | Path | Auth | Description |
 |---|---|---|---|
-| POST | `/v1/users/register` | None | Register account. Body: `username, password, pk_user_ed25519, pk_user_x25519`. Returns `user_id`. |
+| POST | `/v1/users/register` | None | Register account. Body: `username, email, auth_key`. No keys — identity keypairs are per node. Returns `user_id`. |
 | POST | `/v1/users/login` | None | Authenticate. Body: `username, password`. Returns `access_token, refresh_token`. |
 | POST | `/v1/users/token/refresh` | Refresh token | Issue new access token. Body: `refresh_token`. |
 | GET | `/v1/users/{username}/pubkeys` | Access token | Fetch `pk_ed25519` and `pk_x25519` for any user (used by group admins for GEK wrapping). |