Sprint 5 : integration et production -- securite, performance, API publique, documentation
Backend: rate limiter, security headers, blockchain cache service avec RPC, public API (7 endpoints read-only), WebSocket auth + heartbeat, DB connection pooling, structured logging, health check DB. Frontend: API retry/timeout, WebSocket auth + heartbeat + typed events, notifications toast, mobile hamburger + drawer, error boundary, offline banner, loading skeletons, dashboard enrichi. Documentation: guides utilisateur complets (demarrage, vote, sanctuaire, FAQ 30+), guide deploiement, politique securite. 123 tests, 155 fichiers. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
@@ -5,21 +5,76 @@ description: Guide de l'archivage immuable sur Glibredecision
|
||||
|
||||
# Sanctuaire
|
||||
|
||||
## Principe
|
||||
## Qu'est-ce que le Sanctuaire ?
|
||||
|
||||
Le Sanctuaire est la couche d'archivage immuable de Glibredecision. Chaque document adopte, resultat de vote ou decision finalisee est archive de maniere permanente grace a trois mecanismes :
|
||||
Le Sanctuaire est la couche d'**archivage immuable** de Glibredecision. C'est l'endroit ou les decisions adoptees, les documents archives et les resultats de vote sont preserves de maniere permanente et verifiable.
|
||||
|
||||
1. **Hash SHA-256** du contenu pour garantir l'integrite
|
||||
2. **Stockage IPFS** pour la distribution decentralisee
|
||||
3. **Ancrage on-chain** via `system.remark` sur la blockchain Duniter V2
|
||||
Le principe est simple : une fois qu'un contenu entre dans le Sanctuaire, il ne peut plus etre modifie ni supprime. Meme si la plateforme Glibredecision disparaissait, les preuves resteraient accessibles et verifiables de maniere independante.
|
||||
|
||||
## Triple preuve : SHA-256 + IPFS + Blockchain
|
||||
|
||||
Le Sanctuaire repose sur trois mecanismes complementaires qui forment une **triple preuve** d'integrite :
|
||||
|
||||
### 1. Hash SHA-256 -- Preuve d'integrite
|
||||
|
||||
Un hash SHA-256 est un empreinte numerique unique du contenu. Si ne serait-ce qu'un seul caractere du document change, le hash est completement different. En recalculant le hash et en le comparant a celui enregistre, on peut verifier que le contenu n'a pas ete modifie.
|
||||
|
||||
**Analogie** : C'est comme une empreinte digitale. Deux documents differents n'auront jamais la meme empreinte.
|
||||
|
||||
### 2. IPFS -- Stockage distribue et contenu adressable
|
||||
|
||||
IPFS (InterPlanetary File System) est un reseau de stockage distribue. Le contenu n'est pas stocke sur un seul serveur mais replique sur plusieurs noeuds du reseau. Chaque contenu est identifie par un **CID** (Content Identifier) qui est derive de son contenu meme.
|
||||
|
||||
**Analogie** : Au lieu de dire "le document est a l'adresse www.example.com/doc1" (localisation), on dit "le document dont l'empreinte est Qm1234..." (contenu). Peu importe ou il est stocke, tant que l'empreinte correspond, c'est le bon document.
|
||||
|
||||
**Avantages** :
|
||||
|
||||
- **Resilience** : le contenu reste accessible meme si un serveur tombe.
|
||||
- **Integritegarantie** : le CID change si le contenu change, toute falsification est detectable.
|
||||
- **Perennite** : tant qu'au moins un noeud heberge le contenu, il est accessible.
|
||||
|
||||
### Acceder au contenu via IPFS
|
||||
|
||||
Chaque entree du Sanctuaire possede un **CID IPFS** qui permet d'acceder au contenu :
|
||||
|
||||
- **Passerelle publique** : `https://ipfs.io/ipfs/{CID}`
|
||||
- **Passerelle locale** (si vous executez un noeud kubo) : `http://localhost:8080/ipfs/{CID}`
|
||||
|
||||
En cliquant sur le lien CID dans l'interface, le contenu s'ouvre directement dans votre navigateur.
|
||||
|
||||
Si vous avez un noeud IPFS local (kubo), vous pouvez aussi utiliser la ligne de commande :
|
||||
|
||||
```bash
|
||||
# Afficher le contenu
|
||||
ipfs cat {CID}
|
||||
|
||||
# Telecharger le contenu
|
||||
ipfs get {CID} -o document_archive.txt
|
||||
```
|
||||
|
||||
### 3. Ancrage on-chain -- Preuve horodatee et infalsifiable
|
||||
|
||||
L'ancrage on-chain consiste a enregistrer le hash SHA-256 du contenu sur la blockchain Duniter V2, via un appel `system.remark`. Cette transaction est incluse dans un bloc de la blockchain, ce qui fournit :
|
||||
|
||||
- **Horodatage** : la date du bloc prouve que le contenu existait a cette date.
|
||||
- **Immutabilite** : une fois inscrit dans la blockchain, le remark ne peut pas etre modifie.
|
||||
- **Independance** : la preuve est verifiable sur la blockchain, independamment de Glibredecision.
|
||||
|
||||
Le format du remark est :
|
||||
|
||||
```
|
||||
glibredecision:sanctuary:{hash_sha256_du_contenu}
|
||||
```
|
||||
|
||||
**Analogie** : C'est comme publier un hash dans un journal date et immuable. N'importe qui peut verifier que le hash etait bien la a cette date.
|
||||
|
||||
## Pourquoi le Sanctuaire ?
|
||||
|
||||
La gouvernance exige la transparence et la tracabilite. Le Sanctuaire garantit que :
|
||||
|
||||
- Aucune decision adoptee ne peut etre modifiee retroactivement
|
||||
- Tout membre peut verifier l'authenticite d'un document ou d'un resultat de vote
|
||||
- L'historique des decisions est preservee independamment de la plateforme
|
||||
- **Aucune decision adoptee ne peut etre modifiee retroactivement** : le hash et l'ancrage on-chain rendent toute falsification detectable.
|
||||
- **Tout membre peut verifier l'authenticite** d'un document ou d'un resultat de vote de maniere independante.
|
||||
- **L'historique des decisions est preserve** independamment de la plateforme : meme sans Glibredecision, les preuves restent sur IPFS et la blockchain.
|
||||
|
||||
## Types d'entrees
|
||||
|
||||
@@ -51,7 +106,7 @@ Pour retrouver toutes les entrees du Sanctuaire liees a un document, une decisio
|
||||
|
||||
Cette fonctionnalite permet de retracer l'historique complet d'archivage d'un document au fil de ses modifications adoptees.
|
||||
|
||||
## Verification d'integrite
|
||||
## Comment verifier une archive
|
||||
|
||||
### Verification automatique
|
||||
|
||||
@@ -69,44 +124,46 @@ Glibredecision propose une verification automatique d'integrite pour chaque entr
|
||||
Si les trois controles sont valides, le contenu est authentique et n'a pas ete modifie depuis son archivage.
|
||||
::
|
||||
|
||||
### Verification manuelle
|
||||
### Verification manuelle (independante de la plateforme)
|
||||
|
||||
Pour une verification independante de la plateforme :
|
||||
Pour une verification totalement independante de Glibredecision, suivez ces etapes :
|
||||
|
||||
1. Recuperez le contenu via IPFS en utilisant le CID affiche.
|
||||
2. Calculez le hash SHA-256 du contenu telecharge.
|
||||
3. Comparez avec le hash enregistre dans le Sanctuaire.
|
||||
4. Verifiez que le meme hash est present dans le remark on-chain (via un explorateur blockchain).
|
||||
#### Etape 1 : Recuperer le contenu via IPFS
|
||||
|
||||
Si les trois hash correspondent, le contenu est authentique et n'a pas ete modifie.
|
||||
|
||||
## Acces au contenu via IPFS
|
||||
|
||||
Chaque entree du Sanctuaire possede un **CID IPFS** (Content Identifier) qui permet d'acceder au contenu archive de maniere decentralisee.
|
||||
|
||||
### Utiliser le lien IPFS gateway
|
||||
|
||||
Le CID est affiche sous forme de lien cliquable pointant vers une passerelle IPFS publique :
|
||||
|
||||
- **Passerelle publique** : `https://ipfs.io/ipfs/{CID}`
|
||||
- **Passerelle locale** (si vous executez un noeud kubo) : `http://localhost:8080/ipfs/{CID}`
|
||||
|
||||
En cliquant sur le lien CID dans l'interface, le contenu archive s'ouvre directement dans votre navigateur.
|
||||
|
||||
### Recuperer le contenu via la CLI IPFS
|
||||
|
||||
Si vous avez un noeud IPFS local (kubo), vous pouvez recuperer le contenu directement :
|
||||
Utilisez le CID affiche sur l'entree du Sanctuaire pour telecharger le contenu :
|
||||
|
||||
```bash
|
||||
ipfs cat {CID}
|
||||
# Via un noeud IPFS local
|
||||
ipfs cat QmXyz... > document.txt
|
||||
|
||||
# Via une passerelle publique
|
||||
curl https://ipfs.io/ipfs/QmXyz... > document.txt
|
||||
```
|
||||
|
||||
Ou le telecharger :
|
||||
#### Etape 2 : Calculer le hash SHA-256
|
||||
|
||||
```bash
|
||||
ipfs get {CID} -o document_archive.txt
|
||||
sha256sum document.txt
|
||||
```
|
||||
|
||||
Comparez le hash obtenu avec le hash affiche dans le Sanctuaire. Ils doivent etre identiques.
|
||||
|
||||
#### Etape 3 : Verifier l'ancrage on-chain
|
||||
|
||||
1. Copiez le **hash de transaction** affiche sur l'entree du Sanctuaire.
|
||||
2. Ouvrez un explorateur de la blockchain Duniter V2 (par exemple Polkadot.js Apps connecte au reseau Duniter).
|
||||
3. Recherchez la transaction par son hash ou parcourez le **bloc** indique.
|
||||
4. Dans les extrinsics du bloc, reperez l'appel `system.remark` contenant le hash SHA-256.
|
||||
5. Verifiez que le hash dans le remark correspond a celui que vous avez calcule.
|
||||
|
||||
#### Resultat
|
||||
|
||||
Si les trois hash correspondent (calcul local, Sanctuaire, on-chain), le contenu est authentique, integre et horodate. La triple preuve est confirmee.
|
||||
|
||||
::callout{type="tip"}
|
||||
L'ancrage on-chain fournit une preuve horodatee et infalsifiable de l'existence du contenu a la date du bloc. Meme si la plateforme Glibredecision disparait, la preuve reste verifiable sur la blockchain.
|
||||
::
|
||||
|
||||
## Comprendre les informations d'ancrage on-chain
|
||||
|
||||
Chaque entree du Sanctuaire affiche des informations relatives a son ancrage sur la blockchain Duniter V2 :
|
||||
@@ -117,20 +174,6 @@ Chaque entree du Sanctuaire affiche des informations relatives a son ancrage sur
|
||||
| Numero de bloc | Le bloc de la blockchain dans lequel la transaction a ete incluse |
|
||||
| Date d'archivage | Horodatage de la creation de l'entree dans le Sanctuaire |
|
||||
|
||||
### Verifier sur un explorateur blockchain
|
||||
|
||||
Pour verifier l'ancrage on-chain de maniere independante :
|
||||
|
||||
1. Copiez le **hash de transaction** affiche sur l'entree du Sanctuaire.
|
||||
2. Ouvrez un explorateur de la blockchain Duniter V2 (par exemple Polkadot.js Apps connecte au reseau Duniter).
|
||||
3. Recherchez la transaction par son hash ou parcourez le **bloc** indique.
|
||||
4. Dans les extrinsics du bloc, reperer l'appel `system.remark` contenant le hash SHA-256 du contenu.
|
||||
5. Si le hash dans le remark correspond au hash SHA-256 affiche dans le Sanctuaire, l'ancrage est confirme.
|
||||
|
||||
::callout{type="tip"}
|
||||
L'ancrage on-chain fournit une preuve horodatee et infalsifiable de l'existence du contenu a la date du bloc. Meme si la plateforme Glibredecision disparait, la preuve reste verifiable sur la blockchain.
|
||||
::
|
||||
|
||||
## Automatisation
|
||||
|
||||
L'archivage dans le Sanctuaire est declenche automatiquement lorsqu'un processus decisionnel est finalise :
|
||||
@@ -139,3 +182,23 @@ L'archivage dans le Sanctuaire est declenche automatiquement lorsqu'un processus
|
||||
- Quand une session de vote est **cloturee**, le resultat detaille est archive.
|
||||
- Quand une decision est **executee**, l'ensemble de la decision est archive.
|
||||
- Quand un document est **archive** via le bouton d'archivage, l'integralite du document est archivee dans le Sanctuaire.
|
||||
|
||||
## Resume : la chaine de confiance
|
||||
|
||||
```
|
||||
Contenu adopte
|
||||
|
|
||||
v
|
||||
[Calcul SHA-256] --> hash = empreinte unique du contenu
|
||||
|
|
||||
+---> [Upload IPFS] --> CID = identifiant distribue du contenu
|
||||
|
|
||||
+---> [system.remark on-chain] --> preuve horodatee et immuable
|
||||
|
|
||||
v
|
||||
[Entree Sanctuaire] = hash + CID + tx_hash + block_number
|
||||
|
|
||||
v
|
||||
Verification : recalculer le hash, comparer avec IPFS et on-chain
|
||||
= Triple preuve d'integrite
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user