# MeshBay — Phases d'implémentation suivantes

> Base : Phases 1-6 terminées. demo-v2 NAT QUIC validée.
> Référence architecture : docs/meshbay-draft-v3.md

---

## Phase 7 — Node v2 : production, streaming, chat

**Objectif :** un node utilisable quotidiennement — multi-groupe, streaming fluide,
chat intégré, reconnexion rapide.

### Décisions architecturales (arrêtées)

**Multi-groupe → multiplexage sur un seul port QUIC**
Un node expose un seul port QUIC (ex. 19010). Tous les groupes hébergés
partagent ce port. Le groupe est identifié dans le handshake MNP par le `group_id`
contenu dans le JWT. Avantages : un seul trou NAT à maintenir, une seule redirection
de port manuelle si nécessaire. Le serveur QUIC route chaque connexion vers
l'IndexGroup/GEK du bon groupe après vérification du JWT.

**Signaling punch/connect (via hub WebSocket)**
Actuellement, le node punchs aveuglément au démarrage → 12.7s de handshake
(trou NAT vieillit avant que le client arrive). Solution :
```
Client → Hub (HTTPS) : "je vais connecter node X, je viens de IP:PORT"
Hub → Node  (WS)     : message "client_incoming: {peer_ip, peer_port}"
Node → NAT  (UDP)    : punch_nat(peer_ip, peer_port) immédiat
Node → Hub  (WS)     : "punch_ready"
Hub → Client (HTTPS) : "connecte-toi maintenant"
Client → Node (QUIC) : < 2s après le probe → trou frais → < 200ms
```
Le canal hub→node WebSocket existe déjà (`hub/api/revocation.py`).
Il suffit d'ajouter le type de message `client_incoming` / `punch_ready`.
Ce mécanisme s'appuie sur l'ICE simplifié (Interactive Connectivity Establishment).

**Chat — entre forum et Signal**
Pas un chat temps-réel éphémère (Signal) ni un forum lourd.
Modèle : **fil de discussion chiffré E2E, persistant sur le node**.
- Messages courts + pièces jointes (comme Signal groupe)
- Fils/topics optionnels pour structurer (comme un forum léger)
- Historique stocké sur le node (pas éphémère)
- Push pour membres connectés, pull pour hors-ligne
- Double Ratchet (déjà implémenté) pour le chiffrement
- Scope : par groupe (pas par paire d'utilisateurs)
- Pas de suppression automatique (l'admin du groupe gère la rétention)

### Milestones

| # | Composant | Fichier(s) | Priorité |
|---|---|---|---|
| 7.1 | QUIC 0-RTT session resumption | `transport/quic_server.py` + `quic_client.py` | Haute |
| 7.2 | Signaling `client_incoming`/`punch_ready` | `hub/api/revocation.py` + `node/hub_client.py` | Haute |
| 7.3 | Daemon multi-groupe (multiplexage 1 port) | `node/daemon.py` — N IndexGroups, 1 QuicChunkServer | Haute |
| 7.4 | HLS streaming via QUIC | `node/transport/hls.py` — segments en QUIC streams | Moyenne |
| 7.5 | Chat : stockage + wire protocol MNP | `node/chat/store.py` + `common/protocol.py` | Moyenne |
| 7.6 | Chat : UI web locale + push WS members | `node/ui/app.py` WebSocket pour notifications | Moyenne |
| 7.7 | Calibration Argon2id CLI | `node/daemon.py` — `meshbay-node calibrate-argon2` | Basse |

**Questions ouvertes restantes :**
- Les groupes d'un même node partagent-ils la même clé Ed25519 de node ? (probable oui)
- UI multi-groupe localhost:18000 : onglets par groupe ou liste unifiée ?

---

## Phase 8 — Hub v2 : admin, federation, sécurité production

**Objectif :** hub prêt pour opération publique — rôles admin, MHP réseau,
CSAM intégré, monitoring.

| # | Composant | Fichier(s) | Priorité |
|---|---|---|---|
| 8.1 | Rôles admin (hub_admin flag sur User) | `hub/db/models.py` + `hub/api/admin.py` | Haute |
| 8.2 | MHP inter-hub réseau (pas juste en mémoire) | `hub/api/federation.py` + Alembic migration | Haute |
| 8.3 | federated_groups DB persistance | `hub/db/models.py` FederatedGroup already defined | Haute |
| 8.4 | CSAM DB réelle (import NCMEC/IWF) | `hub/csam.py` — import CLI + API update | Haute |
| 8.5 | Signaling endpoint WS (pour punch coordination) | `hub/api/signaling.py` | Haute |
| 8.6 | Métriques / healthcheck | `hub/api/health.py` | Moyenne |
| 8.7 | Cleanup IP logs (purge > 1 an) | `hub/tasks/cleanup.py` — APScheduler | Moyenne |
| 8.8 | Alembic migration Argon2id params | Bump migration + `hub/auth.py` | Basse |

**Questions à clarifier :**
- Qui peut être hub_admin ? Premier user inscrit ? Config toml ?
- MHP : authentification inter-hubs via JWT ou mutual TLS ?
- Signaling : hub WebSocket pour coordonner punch → connect en < 2s

---

## Phase 9 — Android client MVP

**Objectif :** app Android permettant de créer un compte, rejoindre un groupe,
télécharger des fichiers depuis un node.

**Stack technique à décider :**
- **Kotlin natif** : plus de contrôle, accès direct aux APIs Android (WebRTC, QUIC via fork)
- **Flutter** : cross-platform (iOS futur), Dart, mais bindings aioquic inexistants
- **React Native** : JS, même problème de bindings natifs QUIC

**Recommandation :** Kotlin natif. La partie critique (QUIC/UDP + crypto) est en C/Rust via
des bindings JNI. La couche UI peut être Jetpack Compose.

| # | Composant | Tech | Priorité |
|---|---|---|---|
| 9.1 | Hub client (auth, groups, GEK) | Kotlin + Retrofit | Haute |
| 9.2 | Crypto (Ed25519, X25519, ChaCha20) | Bouncy Castle JVM | Haute |
| 9.3 | QUIC client | quiche (Cloudflare, Rust JNI) ou QUIC4J | Haute |
| 9.4 | NAT traversal (STUN + punch) | Kotlin native UDP | Haute |
| 9.5 | File browser + download | Kotlin + streaming IO | Haute |
| 9.6 | Chat UI | Jetpack Compose | Moyenne |
| 9.7 | Node UI pairing (QR code) | Android camera + hub API | Moyenne |

**Préalable à clarifier :** quels bindings QUIC existent sur Android ?
`quiche` de Cloudflare (en Rust, JNI) est le plus mature.

---

## Phase 10 — Web client v2 : groupes privés + streaming

**Objectif :** navigateur peut décoder le contenu privé (AES-GCM) et streamer des vidéos.

| # | Composant | Fichier(s) | Priorité |
|---|---|---|---|
| 10.1 | Web client : décryptage privé (AES-GCM + SubtleCrypto) | `static/crypto.js` MeshBayCrypto | Haute |
| 10.2 | Web client : groupe-type "browser" (AES-GCM GEK) | Hub : `cipher` field sur Group | Haute |
| 10.3 | Player HLS dans browser (hls.js + déchiffrement) | `static/app.js` + hls.js | Haute |
| 10.4 | Chat browser (Double Ratchet JS via WASM ou port) | `static/ratchet.js` | Moyenne |
| 10.5 | PWA / Service Worker | offline + cache | Basse |

**Question clé :** pour le streaming privé en browser, deux approches :
- **AES-GCM GEK** (actuel) : browser-native mais nécessite un groupe dédié
- **ChaCha20 via WASM** : même GEK que les clients natifs, plus complexe

---

## Phase 11 — Résilience réseau : TURN relay, 0-RTT, CGNAT

**Objectif :** fonctionner même derrière les NAT les plus restrictifs (mobile 4G/5G CGNAT).

| # | Composant | Notes | Priorité |
|---|---|---|---|
| 11.1 | Mesh Relay TURN server | Node Python serveur UDP relay chiffré | Haute |
| 11.2 | Relay registration MHP | Hub : `/v1/relays/` + annonce aux nodes | Haute |
| 11.3 | Node : fallback automatique → relay | Après échec STUN dans discover_nat() | Haute |
| 11.4 | Punch coordination signaling | Hub WS → node punch → client connect < 2s | Haute |
| 11.5 | QUIC 0-RTT (aioquic session tickets) | Node stocke ticket → reconnexion < 50ms | Moyenne |
| 11.6 | Test CGNAT mobile 4G | Spike dédié : node mobile → node fixe | Moyenne |
| 11.7 | Connection pool (1 QUIC conn = N requêtes) | Node : réutilisation de stream par user | Moyenne |

---

## Phase 12 — RPM/DEB packaging production + CI

**Objectif :** packages installables, CI qui tourne les tests, releases signées.

| # | Composant | Notes |
|---|---|---|
| 12.1 | RPM build pipeline (Fedora, RHEL) | rpmbuild + spec files déjà écrits |
| 12.2 | DEB build pipeline (Ubuntu, Debian) | dpkg-deb + control déjà écrits |
| 12.3 | GitHub Actions CI | pytest + ruff sur PR |
| 12.4 | Release signing | GPG key pour les packages |
| 12.5 | Repo apt/dnf auto-hébergé | meshbay.org/packages/ |

---

## Ordre recommandé

```
Phase 7 (Node v2)     ← débloque l'usage réel au quotidien
Phase 8 (Hub v2)      ← stabilisation, admin, CSAM
Phase 11 (Relay+0-RTT)← résout le handshake 12.7s et CGNAT mobile
Phase 9 (Android)     ← client mobile, long chantier
Phase 10 (Web v2)     ← streaming privé browser
Phase 12 (Packaging)  ← distribution
```

**Prochaine décision structurante :**
La Phase 7 nécessite de clarifier 3 points avant de coder :
1. Architecture multi-groupe sur un node (ports partagés ou dédiés ?)
2. Mécanisme de signaling punch/connect (nouveau endpoint WS sur le hub ?)
3. Le chat est-il un module (Phase 7.5) ou une feature core du protocole ?