1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
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 ?
|