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