docs: add devel-phases-next.md — Phases 7-12 roadmap

Phase 7: Node v2 (multi-group, 0-RTT, HLS QUIC, chat)
Phase 8: Hub v2 (admin roles, MHP network, CSAM)
Phase 9: Android MVP (Kotlin, quiche JNI, STUN)
Phase 10: Web client v2 (private group AES-GCM, HLS player)
Phase 11: Network resilience (TURN relay, 0-RTT, CGNAT)
Phase 12: RPM/DEB CI/CD

Open questions per phase documented.

Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>

1 files changed, 149 insertions, 0 deletions

diff --git a/devel-phases-next.md b/devel-phases-next.md
new file mode 100644
index 0000000..96526a1
--- /dev/null
+++ b/devel-phases-next.md
@@ -0,0 +1,149 @@
+# 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ébloqueurs techniques :**
+- 0-RTT QUIC (aioquic le supporte) → handshake < 50ms en reconnexion
+- Coordination punch/connect via hub WebSocket (réduire le gap)
+- HLS via QUIC (pas seulement via HTTP)
+
+| # | Composant | Fichier(s) | Priorité |
+|---|---|---|---|
+| 7.1 | QUIC 0-RTT session resumption | `transport/quic_server.py` + `quic_client.py` | Haute |
+| 7.2 | Signaling punch/connect via hub WS | `hub/api/signaling.py` + `node/hub_client.py` | Haute |
+| 7.3 | Daemon multi-groupe | `node/daemon.py` — N DirectoryIndexers + N servers | Haute |
+| 7.4 | HLS streaming via QUIC | `node/transport/hls.py` — segments via QUIC stream | Moyenne |
+| 7.5 | Chat wire protocol (MNP) | `common/protocol.py` MNP.CHAT_* + `node/chat/` | Moyenne |
+| 7.6 | Chat UI (node web UI) | `node/ui/app.py` — fil de messages temps réel | Moyenne |
+| 7.7 | Calibration Argon2id CLI | `node/daemon.py` — `meshbay-node calibrate-argon2` | Basse |
+
+**Questions à clarifier avant 7.3 (multi-groupe) :**
+- Un groupe = un port dédié, ou multiplexage sur un port unique ?
+- Les groupes d'un même node partagent-ils la même clé Ed25519 de node ?
+- Interface UI : comment présenter plusieurs groupes dans localhost:18000 ?
+
+---
+
+## 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 ?