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
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
|
# 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 ?
|