f9fe0e3419
**Motivations:** - Partie connectée du skeleton accessible seulement si pairing satisfait + relais OK, avec page type skeleton (avatar, notifications). - Éviter « Aucun service disponible » : contrat présent en dur dans la page, transmis à l’iframe ; navigation évidente ou automatique vers login. - Sécuriser postMessage (origine UserWallet uniquement) ; déployer data sur le proxy et certificat data.certificator.4nkweb.com. - Vulgariser cryptographie (ECDH, AES-GCM, Schnorr, workflow, collecte signatures) ; documenter correctifs et architecture. **Root causes:** - Section connectée affichée sans vérifier pairing/relay ; possibilité de forger pairing-relay-status depuis la console. - Iframe masquée ou /login chargé avant réception du contrat → graphe vide, redirection vers /services. - Pas de contrôle d’origine sur les messages reçus ; pas de projet website-data ni config Nginx/certificat pour data. **Correctifs:** - Vérification msg.origin === USERWALLET_ORIGIN dans handleMessage (skeleton). - Si session mais pas pairingRelayStatus : afficher iframe pour réception du statut, message « Vérification du statut… ». - Contrat envoyé dès load iframe (init iframe.src = USERWALLET_ORIGIN) ; au clic « Se connecter », envoi contract + navigate-login (service, membre). - UserWallet : écoute navigate-login → navigation /login?service=&membre= ; LoginScreen avec service+membre en URL ne redirige plus vers /services, dispatch E_SELECT_SERVICE / E_SELECT_MEMBER. **Evolutions:** - Message pairing-relay-status (iframe → parent) ; canShowConnectedSection exige login + pairing OK + relay OK ; page connectée avec header avatar + icône notifications. - Skeleton : getLoginContext, sendNavigateLoginToIframe, onIframeLoad, loginRequested/iframeLoaded ; contrat envoyé avec serviceUuid, membreUuid. - UserWallet : PairingRelayStatusMessage, envoi depuis HomeScreen/LoginScreen ; type navigate-login, handleNavigateLogin dans useChannel. - Page cryptographie.html (workflow, algorithmes, collecte signatures) ; liens nav, build. - website-data (Vite, channel, config), start/service/install ; configure-nginx-proxy + Certbot pour data.certificator.4nkweb.com. - fixKnowledge (postmessage-origin, section-connectee-non-affichee) ; features (partie-connectee-pairing-relay, userwallet-iframe-key-isolation). **Pages affectées:** - website-skeleton (index, main, config, serviceContract, cryptographie, technique, membre, contrat, vite.config, README). - userwallet (HomeScreen, LoginScreen, useChannel, iframeChannel, relay, crypto, iframe, Pairing*, RelaySettings, WordInputGrid, syncUpdateGraph, specs/synthese). - website-data (nouveau), configure-nginx-proxy, docs DOMAINS_AND_PORTS README, features, fixKnowledge, userwallet features/docs.
313 lines
16 KiB
HTML
313 lines
16 KiB
HTML
<!DOCTYPE html>
|
||
<html lang="fr">
|
||
<head>
|
||
<meta charset="UTF-8" />
|
||
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
|
||
<title>Réseau P2P – 4NK un nouveau web</title>
|
||
<style>
|
||
* { box-sizing: border-box; }
|
||
body {
|
||
font-family: system-ui, -apple-system, sans-serif;
|
||
max-width: 900px;
|
||
margin: 0 auto;
|
||
padding: 1rem;
|
||
line-height: 1.6;
|
||
color: #333;
|
||
}
|
||
h1 { font-size: 1.5rem; margin-bottom: 1rem; color: #222; }
|
||
h2 { font-size: 1.2rem; margin-top: 1.5rem; margin-bottom: 0.5rem; color: #333; }
|
||
h3 { font-size: 1rem; margin-top: 1rem; margin-bottom: 0.35rem; font-weight: 600; }
|
||
p { margin: 0.75rem 0; }
|
||
ul { margin: 0.5rem 0; padding-left: 1.5rem; }
|
||
li { margin: 0.4rem 0; }
|
||
a { color: #007bff; }
|
||
a:hover { text-decoration: underline; }
|
||
.highlight { background: #e8f4fd; padding: 1rem; border-radius: 8px; border-left: 4px solid #007bff; margin: 1rem 0; }
|
||
.info { background: #d4edda; padding: 1rem; border-radius: 8px; border-left: 4px solid #28a745; margin: 1rem 0; }
|
||
details { margin: 1rem 0; }
|
||
summary { cursor: pointer; font-weight: 600; color: #555; }
|
||
.meta { font-family: ui-monospace, monospace; font-size: 0.85rem; color: #666; background: #f5f5f5; padding: 0.2em 0.4em; border-radius: 4px; word-break: break-all; }
|
||
.relay-list { list-style: none; padding-left: 0; }
|
||
.relay-list > li { background: #f8f9fa; padding: 0.75rem 1rem; border-radius: 8px; border: 1px solid #e0e0e0; margin: 0.5rem 0; }
|
||
.relay-list > li > strong { color: #007bff; }
|
||
.endpoint-table { width: 100%; border-collapse: collapse; margin: 1rem 0; }
|
||
.endpoint-table th, .endpoint-table td { padding: 0.5rem; text-align: left; border-bottom: 1px solid #ddd; }
|
||
.endpoint-table th { background: #f5f5f5; font-weight: 600; }
|
||
.endpoint-table code { background: #f5f5f5; padding: 0.2em 0.4em; border-radius: 4px; font-size: 0.9em; }
|
||
@media (max-width: 768px) {
|
||
body { padding: 0.75rem; }
|
||
h1 { font-size: 1.25rem; }
|
||
.endpoint-table { font-size: 0.9rem; }
|
||
.endpoint-table th, .endpoint-table td { padding: 0.4rem; }
|
||
}
|
||
</style>
|
||
</head>
|
||
<body>
|
||
<h1>Réseau P2P</h1>
|
||
<p><a href="index.html">← Retour à l'accueil</a> · <a href="contrat.html">Le contrat</a> · <a href="membre.html">Qui êtes-vous ?</a> · <a href="cryptographie.html">Cryptographie</a></p>
|
||
|
||
<div class="highlight">
|
||
<strong>En résumé :</strong> Au lieu d'utiliser un seul serveur central (comme Gmail ou Facebook),
|
||
le système utilise plusieurs <strong>relais</strong> qui fonctionnent comme des boîtes aux lettres publiques.
|
||
Vos messages chiffrés sont stockés dans ces relais, et vous pouvez choisir lesquels utiliser.
|
||
</div>
|
||
|
||
<h2>Qu'est-ce qu'un réseau P2P ?</h2>
|
||
<p>
|
||
Imaginez que vous voulez envoyer une lettre. Dans un système classique (comme la poste traditionnelle),
|
||
tous les courriers passent par un seul bureau central. Si ce bureau tombe en panne, plus rien ne fonctionne.
|
||
</p>
|
||
<p>
|
||
Avec un réseau pair-à-pair (P2P), c'est différent : il y a plusieurs <strong>relais</strong> (comme plusieurs
|
||
boîtes aux lettres) répartis sur Internet. Vous pouvez choisir où déposer vos messages, et si un relais
|
||
ne fonctionne plus, vous pouvez utiliser un autre.
|
||
</p>
|
||
<p>
|
||
Les avantages de cette approche :
|
||
</p>
|
||
<ul>
|
||
<li><strong>Plus de robustesse</strong> : si un relais tombe en panne, d'autres continuent de fonctionner</li>
|
||
<li><strong>Pas de point unique de défaillance</strong> : personne ne contrôle tout le système</li>
|
||
<li><strong>Vous choisissez</strong> : vous décidez quels relais utiliser, comme choisir votre opérateur téléphonique</li>
|
||
<li><strong>Copies multiples</strong> : vos messages peuvent être copiés sur plusieurs relais pour plus de sécurité</li>
|
||
</ul>
|
||
|
||
<h2>Comment fonctionnent les relais ?</h2>
|
||
<p>
|
||
Un relais, c'est comme une boîte aux lettres publique sur Internet. Quand vous voulez communiquer avec quelqu'un,
|
||
vous déposez trois choses séparément dans cette boîte :
|
||
</p>
|
||
<ol>
|
||
<li><strong>Le message chiffré</strong> : votre message codé (comme une lettre dans une enveloppe scellée)</li>
|
||
<li><strong>La signature</strong> : une preuve que c'est bien vous qui avez envoyé le message (comme votre signature manuscrite)</li>
|
||
<li><strong>La clé de déchiffrement</strong> : la clé pour décoder le message (comme la clé de votre boîte aux lettres)</li>
|
||
</ol>
|
||
<div class="info">
|
||
<strong>Pourquoi séparer ces trois éléments ?</strong> C'est comme mettre votre lettre, votre signature et votre clé
|
||
dans trois enveloppes différentes. Même si quelqu'un trouve une enveloppe, il ne peut pas tout faire sans les autres.
|
||
C'est plus sûr !
|
||
</div>
|
||
|
||
<h3>Comment récupérer vos messages ?</h3>
|
||
<p>
|
||
Le système fonctionne comme une boîte aux lettres classique : vous allez vérifier régulièrement s'il y a du courrier.
|
||
C'est ce qu'on appelle le modèle <strong>"pull-only"</strong> (vous tirez les informations, elles ne vous sont pas poussées).
|
||
</p>
|
||
<ul>
|
||
<li>Votre appareil vérifie périodiquement les relais pour voir s'il y a de nouveaux messages</li>
|
||
<li>Pas de notification instantanée (comme une alerte SMS), mais une vérification régulière</li>
|
||
<li>Communication simple via Internet, comme consulter une page web</li>
|
||
</ul>
|
||
<p>
|
||
Cette méthode fonctionne partout, même dans les environnements les plus restrictifs, car elle utilise
|
||
simplement le protocole HTTP (comme quand vous visitez un site web).
|
||
</p>
|
||
|
||
<h3>Les relais se parlent entre eux</h3>
|
||
<p>
|
||
Les relais peuvent être configurés pour se copier mutuellement les messages :
|
||
</p>
|
||
<ul>
|
||
<li>Quand vous déposez un message sur un relais, il peut automatiquement le copier vers d'autres relais</li>
|
||
<li>Un système intelligent évite de copier plusieurs fois le même message (grâce à une empreinte unique)</li>
|
||
<li>Résultat : vos messages sont disponibles sur plusieurs relais, comme avoir plusieurs copies de sauvegarde</li>
|
||
</ul>
|
||
<p>
|
||
<em>Exemple :</em> Si vous déposez un message sur le relais A, et que A est configuré pour copier vers B et C,
|
||
votre message sera disponible sur les trois relais. Si A tombe en panne, vous pouvez toujours récupérer votre message depuis B ou C.
|
||
</p>
|
||
|
||
<h2>Quels relais utiliser ?</h2>
|
||
<p>
|
||
Par défaut, un relais principal est configuré. Vous pouvez en ajouter d'autres, jusqu'à <strong>8 relais au maximum</strong>.
|
||
L'application tente de se connecter à tous les relais activés pour déposer et récupérer les messages.
|
||
</p>
|
||
<ul class="relay-list">
|
||
<li>
|
||
<strong>Relais principal (configuré automatiquement)</strong>
|
||
<br>Adresse : <span class="meta">https://relay.certificator.4nkweb.com</span>
|
||
<br>Ce relais est déjà configuré quand vous utilisez le système pour la première fois.
|
||
</li>
|
||
</ul>
|
||
<div class="info">
|
||
<strong>Jusqu'à 8 relais :</strong> Dans les paramètres de UserWallet, vous pouvez ajouter vos propres relais
|
||
(comme plusieurs boîtes aux lettres). Maximum 8 au total. Vous activez ou désactivez chaque relais,
|
||
et choisissez l'ordre de priorité. L'application utilise tous les relais activés pour déposer et récupérer.
|
||
</div>
|
||
|
||
<h2>Pourquoi dupliquer les relais et les flux ?</h2>
|
||
<p>
|
||
Plus vous utilisez de relais, plus vos messages ont de chances d'être disponibles et de circuler.
|
||
</p>
|
||
<ul>
|
||
<li><strong>Déposer sur plusieurs relais</strong> : quand vous envoyez un message, l'application le dépose sur chaque relais activé.
|
||
Si un relais est indisponible, les autres reçoivent quand même le message. Comme poster la même lettre à plusieurs boîtes.</li>
|
||
<li><strong>Récupérer depuis plusieurs relais</strong> : pour lire vos messages, l'application interroge chaque relais.
|
||
Si un relais ne répond pas ou n'a pas le message, un autre peut l'avoir. Comme vérifier plusieurs boîtes aux lettres.</li>
|
||
<li><strong>Résultat</strong> : plus de robustesse (un relais en panne ne bloque pas tout), plus de chances que vos messages
|
||
soient bien livrés, et les relais peuvent se copier entre eux pour multiplier les copies.</li>
|
||
</ul>
|
||
<p>
|
||
En résumé : configurer jusqu'à 8 relais et tous les activer, c'est maximiser les chemins pour envoyer et recevoir,
|
||
sans dépendre d'un seul point.
|
||
</p>
|
||
|
||
<h2>Les actions possibles avec un relais</h2>
|
||
<p>
|
||
Un relais offre plusieurs "actions" (appelées endpoints) que vous pouvez utiliser. C'est comme une boîte aux lettres
|
||
avec plusieurs fonctions : déposer, récupérer, vérifier l'état, etc.
|
||
</p>
|
||
<p>
|
||
<em>Note technique :</em> Ces actions utilisent le protocole HTTP (comme les sites web) avec des méthodes GET (lire)
|
||
et POST (écrire).
|
||
</p>
|
||
<table class="endpoint-table">
|
||
<thead>
|
||
<tr>
|
||
<th>Méthode</th>
|
||
<th>Endpoint</th>
|
||
<th>Description</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td><code>GET</code></td>
|
||
<td><code>/health</code></td>
|
||
<td>Vérifier si le relais fonctionne correctement</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>GET</code></td>
|
||
<td><code>/messages?start=<ts>&end=<ts>&service=<uuid></code></td>
|
||
<td>Récupérer les messages entre deux dates (optionnel : filtrer par service)</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>POST</code></td>
|
||
<td><code>/messages</code></td>
|
||
<td>Déposer un message chiffré dans le relais</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>GET</code></td>
|
||
<td><code>/messages/:hash</code></td>
|
||
<td>Récupérer un message précis grâce à son identifiant unique (hash)</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>GET</code></td>
|
||
<td><code>/signatures/:hash</code></td>
|
||
<td>Récupérer les signatures associées à un message</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>POST</code></td>
|
||
<td><code>/signatures</code></td>
|
||
<td>Déposer une signature dans le relais</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>GET</code></td>
|
||
<td><code>/keys/:hash</code></td>
|
||
<td>Récupérer les clés pour déchiffrer un message</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>POST</code></td>
|
||
<td><code>/keys</code></td>
|
||
<td>Déposer une clé de déchiffrement dans le relais</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>GET</code></td>
|
||
<td><code>/metrics</code></td>
|
||
<td>Consulter les statistiques du relais (nombre de messages, signatures, clés stockées)</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>GET</code></td>
|
||
<td><code>/bloom</code></td>
|
||
<td>Obtenir une liste des messages déjà vus (pour éviter de demander plusieurs fois le même message)</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
|
||
<h2>Comment les relais stockent les données</h2>
|
||
<h3>Organisation du stockage</h3>
|
||
<p>
|
||
Les relais organisent les données comme une bibliothèque bien rangée :
|
||
</p>
|
||
<ul>
|
||
<li><strong>Messages</strong> : rangés par identifiant unique (hash) pour les retrouver rapidement</li>
|
||
<li><strong>Signatures</strong> : classées par message associé</li>
|
||
<li><strong>Clés</strong> : classées par message associé</li>
|
||
<li><strong>Éviter les doublons</strong> : le système se souvient des messages déjà vus pour ne pas les stocker plusieurs fois</li>
|
||
<li><strong>Indexation</strong> : un système de classement permet de retrouver rapidement les messages d'un service particulier</li>
|
||
</ul>
|
||
|
||
<h3>Protection contre les abus</h3>
|
||
<p>
|
||
Les relais sont protégés contre les utilisations abusives :
|
||
</p>
|
||
<ul>
|
||
<li><strong>Limitation des requêtes</strong> : chaque adresse IP ne peut faire qu'un nombre limité de requêtes par minute</li>
|
||
<li><strong>Contrôle d'accès</strong> : seuls les sites autorisés peuvent utiliser le relais</li>
|
||
<li><strong>Timeout</strong> : si une requête prend trop de temps, elle est annulée automatiquement</li>
|
||
<li><strong>Compression</strong> : les réponses sont compressées pour être plus rapides</li>
|
||
</ul>
|
||
|
||
<h3>Éviter les doublons</h3>
|
||
<p>
|
||
Chaque message a une empreinte unique (comme une empreinte digitale). Le système utilise cette empreinte
|
||
pour s'assurer qu'un même message n'est pas stocké plusieurs fois, même s'il arrive depuis plusieurs relais.
|
||
Cela évite aussi que les messages tournent en boucle entre les relais.
|
||
</p>
|
||
|
||
<details>
|
||
<summary>Détails techniques pour les développeurs</summary>
|
||
<h3>Configuration des relais pairs</h3>
|
||
<p>
|
||
Les administrateurs de relais peuvent configurer leurs relais pour se copier mutuellement les messages.
|
||
Cela se fait via une variable de configuration :
|
||
</p>
|
||
<pre class="meta">PEER_RELAYS=http://relay1:3019,http://relay2:3019</pre>
|
||
<p>
|
||
Quand un message arrive sur un relais, il est automatiquement copié vers tous
|
||
les relais pairs configurés (si le message n'a pas déjà été vu).
|
||
</p>
|
||
|
||
<h3>Bloom filter</h3>
|
||
<p>
|
||
Le endpoint <code>/bloom</code> retourne une liste compacte des messages déjà vus par le relais.
|
||
Les applications peuvent utiliser cette liste pour éviter de demander plusieurs fois le même message,
|
||
ce qui réduit la charge sur le réseau et améliore les performances.
|
||
</p>
|
||
|
||
<h3>Statistiques du relais</h3>
|
||
<p>
|
||
Le endpoint <code>/metrics</code> expose des statistiques au format Prometheus (pour le monitoring) :
|
||
</p>
|
||
<ul>
|
||
<li>Nombre de messages stockés</li>
|
||
<li>Nombre de signatures stockées</li>
|
||
<li>Nombre de clés stockées</li>
|
||
</ul>
|
||
|
||
<h3>Gestion des erreurs et timeouts</h3>
|
||
<p>
|
||
Les applications utilisent un délai d'attente de 15 secondes pour toutes les requêtes vers les relais.
|
||
Si une requête échoue ou prend trop de temps, l'application peut essayer un autre relais configuré,
|
||
ou réessayer plus tard avec un délai progressif (backoff exponentiel).
|
||
</p>
|
||
</details>
|
||
|
||
<h2>Pourquoi cette architecture ?</h2>
|
||
<p>
|
||
Cette façon de faire a été choisie pour plusieurs raisons importantes :
|
||
</p>
|
||
<ul>
|
||
<li><strong>Simplicité</strong> : utilise le protocole HTTP standard (comme les sites web), donc ça fonctionne partout</li>
|
||
<li><strong>Fiabilité</strong> : pas besoin de maintenir une connexion permanente, comme consulter une page web</li>
|
||
<li><strong>Capacité</strong> : chaque relais peut gérer de nombreux utilisateurs en même temps</li>
|
||
<li><strong>Contrôle</strong> : vous choisissez quels relais utiliser, personne ne vous impose un choix</li>
|
||
<li><strong>Sécurité</strong> : les messages, signatures et clés sont séparés, ce qui rend le système plus sûr</li>
|
||
</ul>
|
||
<p>
|
||
En résumé, c'est un système simple, fiable et qui vous donne le contrôle, tout en étant sécurisé.
|
||
</p>
|
||
|
||
<p><a href="index.html">← Retour à l'accueil</a> · <a href="contrat.html">Le contrat</a> · <a href="membre.html">Qui êtes-vous ?</a> · <a href="cryptographie.html">Cryptographie</a></p>
|
||
</body>
|
||
</html>
|