# MeshBay User Guide

This guide covers MeshBay in depth — architecture, configuration, security, and the full API. Read the [Quickstart](QUICKSTART.md) first if you have not set up a node yet.

---

## Table of Contents

1. [Architecture overview](#1-architecture-overview)
2. [Account management](#2-account-management)
3. [Groups](#3-groups)
4. [Setting up a node](#4-setting-up-a-node)
5. [Sharing files](#5-sharing-files)
6. [Accessing files](#6-accessing-files)
7. [Video streaming](#7-video-streaming)
8. [Security model](#8-security-model)
9. [Moderation and legal](#9-moderation-and-legal)
10. [Troubleshooting](#10-troubleshooting)
11. [API reference](#11-api-reference)

---

## 1. Architecture Overview

MeshBay has three components. Understanding which role each plays avoids a lot of confusion.

```
┌─────────────────────────────────────────────┐
│  Mesh Hub  (meshbay.org)                    │
│                                             │
│  • User accounts and public keys            │
│  • Group registry (name, membership)        │
│  • Encrypted GEK bundles (opaque blobs)     │
│  • JWT issuance and verification key        │
│  • Connection logs (legal compliance)       │
│  • No file content, no indexes, no GEKs    │
└──────────────┬──────────────────────────────┘
               │ HTTPS  (identity + routing only)
               │
    ┌──────────┴──────────┐
    │                     │
┌───▼────────┐     ┌──────▼───────┐
│ Mesh Node  │     │ Mesh Client  │
│            │     │              │
│ Your files │ MNP │ Browser or   │
│ Your keys  │◄───►│ Android app  │
│ TCP+TLS    │     │              │
└────────────┘     └──────────────┘
```

**Mesh Hub** — a lightweight registrar. Its job is to vouch for identities, track group membership, and store encrypted GEK bundles. After login, clients talk directly to nodes. The hub is never in the data path for file transfers.

**Mesh Node** — the program you run on your server or home machine. It watches a directory, maintains a group index, handles connections from clients, encrypts files at read time, and holds your private keys. You are the legal host of everything in your shared directory.

**Mesh Client** — a web browser or Android app. It authenticates with the hub, fetches the encrypted GEK bundle, and connects directly to nodes for file browsing and download.

**Protocol versioning:** MNP (Mesh Node Protocol) is currently at v0.1 over TCP+TLS 1.3. QUIC transport is planned for v2 with no protocol changes. Every wire message carries a `v` field; N-2 minor version backward compatibility is guaranteed.

---

## 2. Account Management

### Register

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 :**

**Mode CLI / native node** (`setup_demo.py`, `meshbay-node`) :
Les clés sont *dérivées* de votre username + password via Argon2id — pas besoin de
fichier de clés séparé. Même identifiants → mêmes clés sur n'importe quelle machine.
Implémenté dans `meshbay_common.keyderive.derive_keys_from_password()`.

```python
from meshbay_common.keyderive import derive_keys_from_password
sk_ed, sk_x = derive_keys_from_password("alice", "MonMotDePasse!")
```

**Mode navigateur** (interface web) :
Le navigateur génère des clés aléatoires via WebCrypto, les chiffre avec une clé
dérivée du mot de passe (PBKDF2-SHA512), et envoie le bundle chiffré au hub.
À la prochaine connexion, le hub retourne le bundle et le navigateur le déchiffre
localement. Le hub stocke le bundle mais ne peut pas le lire.
Implémenté dans `static/keyderive.js`.

```
POST /v1/users/register
{
  "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
```
POST /v1/users/login
{"username": "yourname", "password": "yourpassword"}
→ {
    "access_token":   "JWT (Ed25519, 1 hour validity)",
    "refresh_token":  "opaque 256-bit token (30 days)",
    "token_type":     "bearer",
    "expires_in":     3600,
  }
```

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 \
  -H "Content-Type: application/json" \
  -d '{"username":"alice_test","password":"AliceTest2026!"}'
```

### Token refresh

Access tokens are valid for 1 hour. When one expires, use the refresh token to get a new one without re-entering your password:

```
POST /v1/users/token/refresh
{"refresh_token": "your-refresh-token"}
→ {"access_token": "new JWT", "token_type": "bearer", "expires_in": 3600}
```

```bash
curl -s -X POST https://meshbay.org/v1/users/token/refresh \
  -H "Content-Type: application/json" \
  -d '{"refresh_token":"YOUR_REFRESH_TOKEN"}'
```

Refresh tokens are valid for 30 days and can be immediately invalidated by the hub on account compromise. Revoking the refresh token means the next access token renewal will fail; any active access token expires within 1 hour at most.

### Access token structure

The JWT payload contains:

| Claim | Value |
|---|---|
| `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 |
| `iat` | Issued at (Unix timestamp) |
| `exp` | Expires at (Unix timestamp, 1 hour from issue) |

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.

---

## 3. Groups

Groups are the primary unit of organization. Every file on a node belongs to a group.

### Create a group

```bash
TOKEN="your-access-token"

curl -s -X POST https://meshbay.org/v1/groups \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"name": "my-group"}'
```

Response:
```json
{"group_id": "uuid", "name": "my-group"}
```

Save `group_id` — you will need it in your `node.toml` and when adding members.

### Public vs. private groups

| | Public | Private |
|---|---|---|
| File index | Plaintext + Ed25519 signed | GEK-encrypted, members only |
| Content | TLS transport only (no application-layer encryption) | GEK-encrypted per chunk |
| Join | Open / approval-gated | By invitation only |
| GEK | Not applicable | Required |

For private groups the node holds a Group Encryption Key (GEK) — a random 32-byte key that is never sent over the wire in cleartext. Each member receives a copy wrapped for their own X25519 public key (ECIES: X25519 + HKDF + AEAD).

**The node does the wrapping, and it never asks the hub for anybody's key.** That matters: the hub is the account directory, so a hub that answered a key lookup with its own key would be handed the group key by an honest member following the protocol exactly (finding H3). Instead the recipient presents their own public keys over the authenticated P2P channel, signed by their identity key, and the node wraps for what it just verified.

### Add a member to a private group

The node operator issues a one-time code, from the server or from their browser:

```bash
# On the node, over SSH — no browser needed
meshbay-node member invite bob

INVITATION CODE  R3H8-TB6V
valid until      2026-08-21T12:00:00+00:00
```

Send the code to Bob however you already talk to him — it never passes through the hub, which is what stops the hub from claiming to be Bob. He enters it the first time he opens the group, and the node then wraps the group key for the key he proved he holds.

After that first time the pin is his credential: he is recognised on every later connection, and asked for nothing. You do not need to be online when he joins.

| | |
|---|---|
| Code lifetime | 7 days (`[node] invite_ttl_hours`) |
| Reuse | Single use; re-inviting supersedes the previous code |
| If it expires | Issue another one — nothing else is affected |
| Wrong code, repeatedly | Bounded per connection and node-wide, and logged in the node's audit log |

The same operation is available in the web app: the group's **Members** tab, if your browser is paired with the node (`meshbay-node operator pair`).

### Removing a member

```bash
meshbay-node member revoke bob
meshbay-node gek-init            # rotate: Bob still holds the old key
```

Revoking stops the node serving Bob the key from his next connection onward — there is no stored bundle left behind that could outlive the decision. It does **not** take back the key he already has, which is why the second command exists.

### What revocation does and does not do

Rotating the GEK (`meshbay-node gek-init`) makes the node encrypt new content with a new key, which every remaining member picks up automatically on their next connection — nothing has to be re-uploaded or re-wrapped by hand.

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.

---

## 4. Setting up a Node

### Configuration file

Full `~/.config/meshbay/node.toml` reference:

```toml
[hub]
url = "https://meshbay.org"

[auth]
username = "yourname"
password = "YourPassword123!"

# Each group this node hosts gets its own [[groups]] block
[[groups]]
group_id   = "uuid-of-your-group"
shared_dir = "/srv/meshbay/my-group"

[[groups]]
group_id   = "uuid-of-second-group"
shared_dir = "/srv/meshbay/second-group"

[node]
# MNP listener port (must be internet-reachable)
listen_port  = 19001

# Local web UI port (loopback only, not exposed externally)
ui_port      = 18000

# Announce this address to the hub (auto-detected via STUN if not set)
# endpoint_hint = "203.0.113.42:19001"

[keystore]
# "secure"    — password prompt at each startup
# "lazy_file" — password read from ~/.config/meshbay/unlock.key (chmod 600)
# "service"   — password read from MESHBAY_UNLOCK_KEY env var
unlock_mode = "secure"
path        = "~/.config/meshbay/keystore.enc"

[crypto]
# Argon2id parameters for keystore password derivation.
# Run `meshbay-node --calibrate-argon2` to tune for your hardware.
# Target: ~500ms on your machine.
argon2_iterations   = 4
argon2_memory_cost  = 262144  # 256 MB
argon2_parallelism  = 1
```

### Environment variables (alternative to node.toml)

| Variable | Equivalent config |
|---|---|
| `MESHBAY_HUB_URL` | `[hub] url` |
| `MESHBAY_USERNAME` | `[auth] username` |
| `MESHBAY_PASSWORD` | `[auth] password` |
| `MESHBAY_UNLOCK_KEY` | keystore unlock key (for `service` mode) |
| `MESHBAY_LISTEN_PORT` | `[node] listen_port` |

### Keystore unlock modes

The keystore is an Argon2id-derived AES-256-GCM encrypted file holding your Ed25519 and X25519 private keys plus GEK copies.

**secure (default):** prompts for a password at startup. Suitable for interactive use. The password is not stored anywhere.

**lazy_file:** reads the password from `~/.config/meshbay/unlock.key` (must be `chmod 600`). Use on a physically secure home server where you want unattended restarts.

```bash
echo -n "YourKeystorePassword" > ~/.config/meshbay/unlock.key
chmod 600 ~/.config/meshbay/unlock.key
```

**service:** reads the unlock key from the `MESHBAY_UNLOCK_KEY` environment variable. Standard practice for systemd deployments:

```ini
# /etc/systemd/system/meshbay-node.service
[Unit]
Description=MeshBay Node
After=network.target

[Service]
User=meshbay
EnvironmentFile=/etc/meshbay/unlock.env   # chmod 600, owned by meshbay
ExecStart=/usr/bin/meshbay-node --config /etc/meshbay/node.toml
Restart=on-failure

[Install]
WantedBy=multi-user.target
```

```bash
# /etc/meshbay/unlock.env  (chmod 600, owned by meshbay user)
MESHBAY_UNLOCK_KEY=YourKeystorePassword
```

### Argon2id calibration

The keystore password derivation is intentionally slow. Tune it to your hardware:

```bash
meshbay-node --calibrate-argon2
```

This prints the derivation time for several parameter combinations. Choose the set that gives ~500ms. The default (iterations=4, memory=256MB) is calibrated for a modern home server.

### Hardware sizing (upload bandwidth is the constraint)

| Scenario | Simultaneous users | Upload needed | RAM |
|---|---|---|---|
| Files + chat, no streaming | 10 | 20–50 Mbps | 512 MB |
| 1080p streaming, 5–6 streams | 10 | 50–80 Mbps | 1 GB |
| Mixed, light streaming | 50 | 200–300 Mbps | 2 GB |
| Heavy streaming | 50 | 400 Mbps | 2–4 GB |

A standard home fiber line (100–500 Mbps symmetric) handles 10–30 concurrent users. Beyond that, a dedicated server is needed.

---

## 5. Sharing Files

### How indexing works

The node watches `shared_dir` for file changes using filesystem events (`watchdog` library). When a file is added, modified, or removed:

1. The node computes `blake3(file)` as the file identifier
2. It builds or updates a Mesh Group Index entry for that file
3. The index entry is serialized as msgpack, compressed with zstd, then encrypted with the GEK (for private groups) or signed with the node's Ed25519 key (for public groups)
4. Connected members receive an index delta push; new connections receive the full index

### Index entry structure

```python
{
  "version":    1,
  "id":         "<blake3_hash_hex>",   # file identity and chunk key input
  "name":       "filename.mkv",
  "path":       "Movies/2024/",        # relative path within shared_dir
  "size":       4294967296,            # bytes
  "type":       "video",               # video | audio | image | document | archive | other
  "duration":   7245,                  # seconds (media files only)
  "thumb_hash": "<blake3>",            # thumbnail, also GEK-encrypted
  "added_at":   1720000000             # Unix timestamp
}
```

### Supported file types

The node detects type by file extension and MIME sniffing:

| Type | Extensions |
|---|---|
| `video` | mp4, mkv, avi, mov, webm |
| `audio` | mp3, flac, ogg, opus, m4a |
| `image` | jpg, jpeg, png, gif, webp, avif |
| `document` | pdf, txt, md, epub, doc, docx, odt |
| `archive` | zip, tar, gz, bz2, xz, 7z |
| `other` | everything else |

### 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:

- Disk-level encryption (LUKS, etc.) is your responsibility if you need at-rest protection
- Backups of the shared directory are plaintext
- Node compromise exposes all files in plaintext

---

## 6. Accessing Files

### Browse the index

```
GET /index
Authorization: Bearer <access_token>

→ [
    {"id": "blake3hash", "name": "filename", "size": 1234, "type": "video"},
    ...
  ]
```

```bash
curl -s -H "Authorization: Bearer $TOKEN" http://meshbay.org:19001/index | python3 -m json.tool
```

### Download a full file

```
GET /file/{file_id}
Authorization: Bearer <access_token>

→ raw file bytes (Content-Type set by file type)
```

```bash
curl -s -H "Authorization: Bearer $TOKEN" \
  http://meshbay.org:19001/file/<file_id> \
  -o output.txt
```

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).

### Download an encrypted chunk

```
GET /file/{file_id}/{chunk_index}
Authorization: Bearer <access_token>

→ {
    "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
  }
```

Chunks are 1 MB. Chunk 0 is the first megabyte. For a 5 MB file, request chunks 0–4.

**Per-chunk key derivation:**

```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")
).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

```
GET /
→ {
    "file_count": 2,
    "pk_node":    "base64 Ed25519 public key",
    "group_id":   "uuid"
  }
```

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.

---

## 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 <access_token>

→ M3U8 playlist with segment URLs
```

Each segment is a GEK-encrypted 1 MB chunk served as `application/octet-stream`. The browser-side player must decrypt segments before handing them to the media element.

### Play in a browser

Because segments are encrypted, a standard `<video>` tag cannot play them directly. Use the Media Source Extensions (MSE) API with a JavaScript decryption shim:

```html
<video id="player" controls></video>

<script type="module">
import { MeshBayPlayer } from "https://meshbay.org/static/player.js";

const player = new MeshBayPlayer({
  element:  document.getElementById("player"),
  nodeUrl:  "http://meshbay.org:19001",
  fileId:   "YOUR_FILE_ID",
  gek:      gek_bytes,          // Uint8Array(32), obtained from GEK unwrap
  token:    access_token,
});
player.load();
</script>
```

`player.js` handles:
- Fetching the M3U8 playlist
- Requesting encrypted chunks on demand
- Deriving per-chunk keys from the GEK
- Decrypting with WebCrypto (AES-256-GCM — see §8 for cipher choice)
- Feeding plaintext segments to MSE

### Seeking

Because each chunk uses an independently derived key, seeking jumps directly to the target chunk without decrypting preceding chunks. The HLS playlist embeds the `chunk_index` for each segment so the player computes the correct key immediately.

### Supported formats for streaming

The node can serve HLS for any container it can segment at 1 MB boundaries: MP4, MKV, WebM. The browser must support the codec in the file. For broad compatibility, H.264 + AAC in MP4 is recommended.

---

## 8. Security Model

Understanding what the hub knows — and does not know — is essential for evaluating MeshBay's threat model.

### Cipher choices — symmetric, not asymmetric

Clarification terminology : Ed25519 et X25519 sont des algorithmes **asymétriques** (paire clé publique/privée). Ils servent à la signature et à l'échange de clés. Les ciphers de chiffrement de contenu sont eux **symétriques** (une seule clé partagée, la GEK) :

| Cipher | Usage | Où |
|---|---|---|
| **ChaCha20-Poly1305** | Chiffrement contenu (MNP) | Node → client natif (Python, Android) |
| **AES-256-GCM** | Chiffrement contenu (navigateur) | Variante pour les groupes accessibles depuis un browser (WebCrypto ne supporte pas ChaCha20) |

Les deux sont des AEAD 256 bits avec authentification intégrée. ChaCha20 est le cipher **principal** — AES-GCM est une variante optionnelle pour la compat navigateur, pas un remplacement. Un groupe ne peut pas mélanger les deux : un groupe "browser-accessible" utilise AES-GCM pour tous ses membres.

### What the hub stores

| Data | Stored as |
|---|---|
| Username, email, optional phone | Encrypted at rest |
| Password | Argon2id hash (never cleartext) |
| Ed25519 and X25519 public keys | Plaintext (they are public) |
| GEK bundles (private groups) | Opaque ciphertext — hub cannot decrypt |
| Connection logs | IP + timestamp, retained ≥1 year (legal) |
| Node endpoint hints | Ephemeral (signaling only, not persisted) |

### What the hub never stores

- File content or any file metadata
- Private group indexes
- Message content
- The GEK in cleartext
- Your private keys

### GEK wrapping — why the hub cannot decrypt your files

When Alice adds Bob to a private group, she wraps the GEK with Bob's X25519 public key using an ECIES-like construction:

```
sk_eph, pk_eph  ← X25519.generate()             fresh ephemeral keypair per bundle
shared          ← X25519(sk_eph, pk_bob)
wrap_key        ← HKDF(shared, salt=pk_eph, info="meshbay:gek_wrap:v1")
bundle          ← ChaCha20-Poly1305(wrap_key).encrypt(nonce, GEK, aad=pk_bob)
```

The hub receives `{pk_eph, nonce, bundle}` and stores it opaquely. To decrypt it, an attacker would need `sk_bob` (Bob's X25519 private key), which never leaves Bob's device. The AAD (`pk_bob`) also binds the bundle to its intended recipient — a bundle cannot be repurposed for a different member.

Each call to `wrap_gek` uses a fresh `sk_eph`, so the same GEK wrapped for the same member twice produces different ciphertext. The hub sees only different random-looking blobs.

Wrap and unwrap operations each take ~0.5–1.2ms (measured in testing).

### Forward secrecy

Two layers:

1. **Per-connection session keys:** each MNP connection performs X25519 ECDH + HKDF to derive ephemeral session keys independent of the GEK. Compromise of the GEK does not expose historical session traffic.

2. **Per-chunk keys:** each 1 MB chunk uses a distinct key derived from the GEK + file hash + chunk index. Compromise of one chunk key does not compromise other chunks.

### JWT security properties

- `jti` (UUID4) is mandatory in every token — prevents replay (Ed25519 signing is deterministic; without `jti`, two tokens issued in the same second are byte-for-byte identical) and enables individual revocation
- Nodes verify JWTs offline using the hub's cached public key — no hub roundtrip, no hub downtime dependency
- Revocation: hub invalidates refresh token → next access token renewal fails → node access expires within 1 hour. For immediate revocation: hub adds `jti` to a denylist that nodes periodically fetch

### What node compromise exposes

If an attacker gains access to your node:
- All files in `shared_dir` (stored in plaintext)
- The keystore file (protected by Argon2id-derived AES-256-GCM; requires the keystore password to open)
- The GEK copies in the keystore (if the keystore is unlocked)

If the keystore password is not stored on the node (`unlock_mode = "secure"`), a node compromise does not immediately expose the GEK or private keys — the attacker gets the encrypted keystore and must break Argon2id. At the production parameters (iterations=4, memory=256MB, target=500ms), this is designed to limit offline attacks to a tractable rate.

---

## 9. Moderation and Legal

### Who is the legal host

**You, the node operator, are the legal host of all content you serve.** MeshBay is a protocol and a registrar service, not a content host. By running a node, you take full legal responsibility for what your node shares.

The hub (`meshbay.org`) is a registrar analogous to a domain registrar — it handles identity and routing, not content. Its legal exposure is similar to that of a registrar, not a hosting provider.

### Content reports (public groups)

```
Report #1 → public access suspended automatically
           → node operator notified via email
One republication allowed
Report #2 → escalated to hub moderators
Confirmed → group revoked on local hub
           → revocation token propagated to federated hubs
```

Mechanism: the file's `blake3` hash is added to the hub blocklist. A signed revocation token (Ed25519) is sent to the node. Nodes verify the revocation token offline.

### CSAM policy

All public content hashes are checked against the NCMEC and IWF databases at the time of indexing. Any match results in immediate revocation of the group and the account, and mandatory reporting to NCMEC. No scanning of private encrypted content is performed — it is technically infeasible.

This hash-matching step is mandatory for hub operators and reduces legal exposure under applicable law (NCMEC CyberTipline obligations).

### Copyright

Takedown on receipt of a valid DMCA notice or equivalent. The hub can revoke a group on confirmed legal request. No automated technical blocking (high false-positive risk, fair use concerns).

### Private content

Private group content is E2E encrypted. The hub cannot read it. Action available on a formal legal request: revoke the user or group at the hub level. The hub issues an Ed25519-signed revocation token verifiable offline by all member nodes. This terminates future access without retroactively decrypting past content.

### Connection logging

The hub logs the following events with timestamp and source IP for a minimum of one year (LCEN, EU e-Commerce Directive, DSA compliance):

| Event |
|---|
| Account creation |
| Login (success and failure) |
| Group creation |
| Group join / leave |
| Group deletion |
| Revocation actions |

These logs are not used for any purpose other than responding to legal requests. They are not exposed to users, group operators, or third parties without a legal order.

---

## 10. Troubleshooting

### JWT expired

**Symptom:** node returns 401, error says "expired" or "Token signature expired".

**Fix:** your access token is over 1 hour old. Refresh it:

```bash
curl -s -X POST https://meshbay.org/v1/users/token/refresh \
  -H "Content-Type: application/json" \
  -d '{"refresh_token":"YOUR_REFRESH_TOKEN"}'
```

If the refresh token is also expired (>30 days), log in again.

### GEK bundle not found (404 on `/v1/groups/{id}/gek`)

**Symptom:** `404 {"detail": "No GEK bundle for this user in this group"}`.

**Causes:**
- You are not a member of this group — the admin needs to add you and upload a GEK bundle for you
- Your public key registered on the hub differs from your current keypair — this happens if you regenerated your keys after registration (see below)

### GEK decryption fails (`InvalidTag`)

**Symptom:** `ChaCha20Poly1305.decrypt()` raises `cryptography.exceptions.InvalidTag`.

**Cause:** your local X25519 private key does not match the public key that was on the hub when the GEK bundle was created. This happens when:

- You ran the registration script more than once without persisting `my_keys.json`
- You deleted and recreated your keystore

**Fix:** contact the group admin. They need to fetch your current public key from the hub and re-wrap the GEK for you.

### Node is not reachable from outside

**Symptom:** curl to `http://YOUR-IP:19001/` times out from another machine.

**Checklist:**
1. Is the port open in your firewall? (`sudo ufw allow 19001/tcp` on Ubuntu)
2. If behind a home router: have you set up a port forward for `19001/tcp` to your machine's local IP?
3. Is the node actually listening? (`ss -tlnp | grep 19001`)
4. Is your ISP blocking inbound connections on that port? (Some mobile ISPs do this — use a VPS)

NAT traversal without manual port configuration (STUN/hole-punching for most residential connections) is coming in v2.

### `Connection refused` on port 19001

The node is not running, or it started on a different port. Check your `node.toml` `listen_port` and the node's startup log output.

### Hub returns 422 (Unprocessable Entity)

Usually a malformed request body. Check that:
- `Content-Type: application/json` header is present
- Your public keys are base64-encoded raw 32-byte values (not PEM, not hex)
- Password is at least 8 characters

### Node announces but no files appear in index

- Check that `shared_dir` exists and contains files
- Check the node log for indexing errors (permission denied, symlinks, etc.)
- The node re-indexes on startup and watches for changes. If a file was added while the node was down, restart the node or touch the file to trigger a watch event.

### `AEAD decryption failed` on chunk download

- Verify you fetched the GEK bundle for the correct group
- Verify `chunk_index` in the HKDF `info` matches the `chunk_index` field in the JSON response
- Verify `file_hash_b64` is decoded to bytes before use in HKDF `info`
- Verify the GEK itself is correct by re-fetching and re-unwrapping the bundle

---

## 11. API Reference

All hub endpoints are under `https://meshbay.org`. Node endpoints are under `http://<node-ip>:<port>`.

### Hub API

**Hub metadata**

| Method | Path | Auth | Description |
|---|---|---|---|
| GET | `/v1/hub/info` | None | Hub metadata: hub_id, MNP/MHP versions, user count, node count |
| GET | `/v1/hub/pubkey` | None | Hub Ed25519 public key (PEM) — cache this for offline JWT verification |

**User management**

| Method | Path | Auth | Description |
|---|---|---|---|
| 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). |

**Node management**

| Method | Path | Auth | Description |
|---|---|---|---|
| POST | `/v1/nodes/announce` | Access token | Register node. Body: `pk_node, endpoint_hint`. Returns `node_id`. |
| GET | `/v1/nodes/{node_id}` | Access token | Retrieve node record: `pk_node, endpoint_hint, username`. |

**Group management**

| Method | Path | Auth | Description |
|---|---|---|---|
| POST | `/v1/groups` | Access token | Create group. Body: `name`. Returns `group_id`. |
| GET | `/v1/groups` | None / Access token | List/search groups. Private groups require membership. |
| GET | `/v1/groups/{group_id}` | None / Access token | Group metadata. |
| DELETE | `/v1/groups/{group_id}` | Access token (admin) | Revoke and delete group. |

**GEK distribution (private groups)**

| Method | Path | Auth | Description |
|---|---|---|---|
| POST | `/v1/groups/{group_id}/members/{username}/gek` | Access token (admin) | Upload GEK bundle for a member. Body: `pk_eph_b64, nonce_b64, wrapped_b64`. |
| GET | `/v1/groups/{group_id}/gek` | Access token (member) | Retrieve your own GEK bundle. Returns `pk_eph_b64, nonce_b64, wrapped_b64`. |

**Revocation**

| Method | Path | Auth | Description |
|---|---|---|---|
| POST | `/v1/revoke/user/{user_id}` | Access token (hub admin) | Revoke a user account. |
| POST | `/v1/revoke/group/{group_id}` | Access token (hub admin) | Revoke a group. |
| GET | `/v1/revoke/denylist` | None | Current `jti` denylist for active access tokens. Nodes poll this to enable individual token revocation. |

### Node API

| Method | Path | Auth | Description |
|---|---|---|---|
| GET | `/` | None | Node info: `file_count, pk_node, group_id`. |
| GET | `/index` | Bearer token | Group file index. Returns array of `{id, name, size, type}`. |
| GET | `/file/{file_id}` | Bearer token | Download full file (encrypted bytes for private groups). |
| GET | `/file/{file_id}/{chunk_index}` | Bearer token | Download single 1 MB encrypted chunk as JSON: `ct_b64, nonce_b64, file_hash_b64, chunk_index, plaintext_size`. |
| GET | `/stream/{file_id}/index.m3u8` | Bearer token | HLS playlist for video streaming. |

**Auth:** all node endpoints that require a Bearer token verify the JWT offline using the hub's Ed25519 public key. The hub is not contacted during verification (~884µs).

---

*MeshBay protocol: MNP v0.1 over TCP+TLS 1.3. QUIC transport planned for v2.*
*Hub: https://meshbay.org — FastAPI + PostgreSQL + Caddy.*
*Packages: python3-meshbay-common, meshbay-hub, meshbay-node.*