From 4156b5b8c3986278a887d1dce4db265746e9155f Mon Sep 17 00:00:00 2001 From: Christophe Besson Date: Sat, 15 Aug 2026 00:30:29 +0200 Subject: docs: account deletion, notifications, and the APIs that no longer exist MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Account deletion is the headline, in the user guide and in draft-v5 §6.1, and the important half is what deletion does *not* do. It releases the username, clears the email and password hash, drops memberships, notifications, refresh tokens and node registrations, and refuses any access token still inside its hour. It does not touch a node: files, the pinned identity and the keypair bundle stay on machines the hub does not command, which is the same sovereignty §5.5 relies on — so deleting a hub account is not an erasure request to the operators hosting you. The IP log survives too, attributable, for its legal retention period. The claims table in §2 gets a row saying exactly this, adversary by adversary. Notifications get a section: one entry per conversation rather than per message, never one for your own message, invitations that clear when you join, muting that lives on the hub so it works from any browser. Then the corrections, which is most of the diff. The guide still described a node HTTP API — `GET /index`, `GET /file/{id}`, an HLS playlist, and a `player.js` that does not exist — with curl examples inviting the reader to expose port 19001. That surface was removed in 0.2.0 as findings C1 and C6, precisely because it served files outside the handshake that decides what a peer may see. Sections 6, 7 and the API reference now describe MNP message pairs, and the quickstart says the same in French. Also corrected: the JWT table advertised a `pk_user` claim that no longer exists (it was what let the token issuer decide who could delete a file), `/pubkeys` no longer returns identity keys, and the GEK-distribution endpoints are gone entirely rather than merely unused. draft-v5 §5.2 had uploads landing in `.uploads/{user_id}/`; they land in `uploads/`, chat attachments included. §6.1 now says the hub learns the author's user_id from chat_notify — a stable identifier, and a metadata leak worth naming rather than leaving as "by whom". CLAUDE.md records why the deployed hub broke this week: create_all() creates missing tables, never missing columns, so a schema change passes every test (fresh DB per run) and never reaches production. Co-Authored-By: Claude Opus 5 --- docs/QUICKSTART.md | 18 +-- docs/USERGUIDE.md | 291 +++++++++++++++++++++++++++++------------------ docs/meshbay-draft-v5.md | 40 ++++++- 3 files changed, 225 insertions(+), 124 deletions(-) (limited to 'docs') diff --git a/docs/QUICKSTART.md b/docs/QUICKSTART.md index ca3beee..2d59f1f 100644 --- a/docs/QUICKSTART.md +++ b/docs/QUICKSTART.md @@ -106,22 +106,24 @@ Fichiers disponibles : 1 fichier(s) indexé(s) -✓ Node actif sur http://127.0.0.1:19001 - Info: http://localhost:19001/ - Index: http://localhost:19001/index +✓ Node actif — MNP sur le port 19001 + Admin UI : meshbay-node ui (boucle locale, jeton requis) CTRL+C pour arrêter. ``` Vérification rapide dans un autre terminal : ```bash -curl http://localhost:19001/ -# {"node_version":"0.1.0","file_count":1,"group_name":"demo-group",...} - -curl http://localhost:19001/index -# {"entries":[{"name":"README.txt","size":93,...}],...} +meshbay-node status +# état du node, clés, groupes configurés, fichiers indexés ``` +> **Le node n'expose aucune API HTTP publique.** Les endpoints `/`, `/index` et +> `/file/{id}` ont été supprimés en 0.2.0 (findings C1 et C6) : ils servaient l'index +> et les fichiers en dehors du handshake qui décide de ce qu'un pair a le droit de +> voir. Le port 19001 est le listener MNP, pas un serveur web. La seule surface HTTP +> est l'UI d'administration, sur la boucle locale et protégée par un jeton. + **Ajouter vos propres fichiers :** ```bash cp ~/Videos/ma_video.mp4 QE/demo-v1/shared/ diff --git a/docs/USERGUIDE.md b/docs/USERGUIDE.md index 71b0060..a8991b1 100644 --- a/docs/USERGUIDE.md +++ b/docs/USERGUIDE.md @@ -141,14 +141,59 @@ The JWT payload contains: |---|---| | `iss` | Hub ID (`meshbay.org`) | | `sub` | Your `user_id` (UUID4) | -| `pk_user` | Your Ed25519 public key (base64) | | `hub_id` | `meshbay.org` | | `jti` | UUID4 — unique per token, enables revocation, prevents replay | +| `groups` | The `group_id`s you are a member of, for node-side authorization | +| `scope` | `user` for a browser, `node` for a daemon | | `iat` | Issued at (Unix timestamp) | | `exp` | Expires at (Unix timestamp, 1 hour from issue) | +The token carries **no public key of yours**. It used to carry `pk_user`, and a node +recorded that key as the uploader of a file — which meant the party issuing tokens +decided who was allowed to delete it. The hub certifies *accounts*; keys are generated +on each node and pinned there (§4). + Nodes verify this JWT locally using the hub's cached Ed25519 public key. No hub roundtrip is needed — verified at 884µs in testing. This means your files remain accessible even if the hub is temporarily unreachable. +### Deleting your account + +**Settings → Delete account.** You re-enter your passphrase: a live session may be a +borrowed laptop or a tab left open, and this cannot be undone. A hub administrator can +also delete an account, from Administration → Users. + +What deletion does: + +- Releases the username — someone else may register it afterwards +- Clears the email and password hash, and drops the node linking key +- Removes group memberships, notifications and refresh tokens +- Refuses any access token still in its hour of validity, immediately + +What deletion does **not** do: + +- **It does not touch anything on a node.** Your files stay where you uploaded them, and + so do the identity pinned in the node's roster and the keypair bundle it holds for you. + Nodes are other people's machines; the hub cannot command them. To be removed there, + ask the operator — `meshbay-node member unpin ` and deleting your files are + their commands to run (§4). +- **It does not erase the connection log.** IP records are kept for their legal retention + period and stay attributable; that is what they exist for. + +Deletion is refused while you still own a group. Hand the group over or delete it first — +otherwise its members would be stranded. The error names the groups blocking you. + +``` +DELETE /v1/users/me +Authorization: Bearer +{"auth_key": ""} +→ 200 {"status": "deleted", "username": "alice_test"} +→ 403 {"detail": "Passphrase does not match"} +→ 409 {"detail": "This account still owns groups: ..."} +``` + +Node registrations are removed as well, so a deleted operator's nodes stop being +announced. The daemons keep running and keep their data — again, the hub does not +command them. + --- ## 3. Groups @@ -226,6 +271,35 @@ Rotating the GEK (`meshbay-node gek-init`) makes the node encrypt new content wi A former member can still decrypt content they already received: there is no retroactive re-encryption, and there is no way to reach into someone's disk. Revocation controls what happens next, not what already happened. +### Notifications + +The bell in the top bar counts what you have not read. Clicking an entry takes you to +what it is about and dismisses it. + +- **Chat is one entry per group, not one per message.** A conversation that has been busy + all afternoon is a single line whose date moves to the last thing said and which turns + unread again each time. Opening the group clears it. +- **You are never notified of your own messages.** The node names the author when it + tells the hub a message was posted, and the hub skips them. +- **An invitation disappears once you have joined**, i.e. after you enter the pairing + code — not when you first look at it. +- **Muting a group works from anywhere.** The setting lives on the hub with your + membership, so a muted group creates no notification at all rather than hiding one + after the fact. It follows you to another browser. (It used to be a checkbox in the + browser's local storage that nothing read, so it did nothing.) +- **Clear all** empties the list in one action. + +``` +GET /v1/notifications → {"notifications": [{id, kind, group_id, title, link, read, created_at}], "unread": 3} +POST /v1/notifications/{id}/read → mark one read +POST /v1/notifications/read-all → mark every one read +DELETE /v1/notifications → delete them all +POST /v1/groups/{group_id}/mute {"muted": true} +``` + +`GET /v1/groups/mine` reports `muted` for each group, so the browser shows the checkbox +in the state the hub actually holds. + --- ## 4. Setting up a Node @@ -386,6 +460,25 @@ The node detects type by file extension and MIME sniffing: | `archive` | zip, tar, gz, bz2, xz, 7z | | `other` | everything else | +### Where uploaded files land + +Everything a member sends arrives in **`shared_dir/uploads/`** — both files uploaded from +the Files panel and attachments sent in the chat. One visible directory, so an operator can +look at what was sent, move it, or empty it without hunting through the tree. + +- Filenames are checked against a conservative allowlist and nothing is ever overwritten: + a colliding name gets a suffix, and the sender is told the name it was stored under. +- Chat thumbnails are scaled by the browser from the file itself. The node writes no + derived images, so nothing accumulates beside your files. +- Uploads are attributed to the identity the node pinned for that member, and that is what + decides who may delete the file later — not anything the hub says. + +### Creating a directory + +Any active member can create a directory from the Files panel (**New folder**). It is +created relative to the folder you are looking at, under `shared_dir`, and the same name +rules apply. Paths that try to leave the shared root are refused. + ### Files are stored in plaintext on disk The node holds your files in plaintext. Encryption happens at read time — the node encrypts each 1 MB chunk using a per-chunk key derived from the GEK before sending it over the wire. This means: @@ -398,134 +491,84 @@ The node holds your files in plaintext. Encryption happens at read time — the ## 6. Accessing Files -### Browse the index - -``` -GET /index -Authorization: Bearer +**There is no HTTP file API.** Files are requested over MNP — the node's authenticated +message channel, carried by WebRTC DataChannel or QUIC — and nothing on the node answers +an unauthenticated request. The `GET /index`, `GET /file/{id}` and `GET /stream/...` +endpoints documented before 0.2.0 were removed (findings C1 and C6): they served the index +and file bytes to anyone holding a token, outside the handshake that decides what a peer +is allowed to see. Port 19001 is the MNP listener, not a web server. -→ [ - {"id": "blake3hash", "name": "filename", "size": 1234, "type": "video"}, - ... - ] -``` - -```bash -curl -s -H "Authorization: Bearer $TOKEN" http://meshbay.org:19001/index | python3 -m json.tool -``` +The node's only HTTP surface is its admin UI, bound to loopback and requiring a token +(§4). It is for the operator, on the machine, over SSH. -### Download a full file +### Browse the index -``` -GET /file/{file_id} -Authorization: Bearer +After the handshake, ask for the index: -→ raw file bytes (Content-Type set by file type) ``` - -```bash -curl -s -H "Authorization: Bearer $TOKEN" \ - http://meshbay.org:19001/file/ \ - -o output.txt +→ {"type": "index_sync", "v": "0.1"} +← {"type": "index_sync", "entries": [{"id": "", "name": "...", "size": 1234, + "type": "video", "path": "uploads/"}, ...]} ``` -For private groups, the returned bytes are the concatenated encrypted chunks. You must decrypt them client-side using the GEK (see the Quickstart download script for the full decryption flow). +For a private group the index itself is encrypted with the GEK, so a peer that never +proved possession of the key is served nothing to read. -### Download an encrypted chunk +### Download a file, chunk by chunk ``` -GET /file/{file_id}/{chunk_index} -Authorization: Bearer - -→ { - "ct_b64": "base64 ChaCha20-Poly1305 ciphertext", - "nonce_b64": "base64 12-byte nonce", - "file_hash_b64": "base64 blake3 of full file (HKDF salt input)", - "chunk_index": 0, - "plaintext_size": 1048576 - } +→ {"type": "file_req", "v": "0.1", "file_id": "", "chunk_index": 0} +← {"type": "file_chunk", "file_id": ..., "chunk_index": 0, + "nonce": , "ct": , "plaintext_size": 1048576} ``` -Chunks are 1 MB. Chunk 0 is the first megabyte. For a 5 MB file, request chunks 0–4. +Chunks are 1 MB. Chunk 0 is the first megabyte; for a 5 MB file, request 0–4. -**Per-chunk key derivation:** +**Per-chunk key derivation** — each chunk has an independent key derived from the GEK and +the chunk's position, so a leaked chunk key opens exactly one chunk of one file, and a +player can seek without decrypting from the start: ```python chunk_key = HKDF( algorithm=hashes.SHA256(), length=32, salt=None, - info=b"file:" + file_hash_bytes + b":chunk:" + chunk_index.to_bytes(4, "big") + info=b"file:" + file_hash_bytes + b":chunk:" + chunk_index.to_bytes(4, "big"), ).derive(gek) plaintext = ChaCha20Poly1305(chunk_key).decrypt(nonce, ciphertext, None) ``` -Each chunk has an independent key derived from the GEK and the chunk's position. This enables seeking in media files without decrypting from the start. - -### Node info endpoint +The browser client derives the same key the same way but uses **AES-GCM**: WebCrypto has +no ChaCha20-Poly1305. The node picks the cipher from what the peer negotiated at +handshake; the key schedule above is identical in both. -``` -GET / -→ { - "file_count": 2, - "pk_node": "base64 Ed25519 public key", - "group_id": "uuid" - } -``` +### Identifying the node -The node's Ed25519 public key (`pk_node`) is also what nodes use for TLS certificate pinning. Clients retrieve it from the hub via `GET /v1/nodes/{node_id}` and validate the node's self-signed TLS cert against it. +The node's `pk_node` (Ed25519) comes from the hub — `GET /v1/nodes/{node_id}` — and the +client checks the handshake signature against it. A node that cannot sign the transcript +with the key the hub published for it is refused, so hub signaling can introduce you to a +node but cannot substitute one. --- ## 7. Video Streaming -The node generates HLS (HTTP Live Streaming) segments on the fly for video files. - -### HLS endpoint - -``` -GET /stream/{file_id}/index.m3u8 -Authorization: Bearer +Video is streamed over the same MNP channel and played through Media Source Extensions. +The node transcodes to fragmented MP4 on the fly and encrypts each segment exactly like a +file chunk, so a standard `