2bdc731639
Backend: - CRUD complet documents/items/versions (update, delete, accept, reject, reorder) - Service IPFS (upload/retrieve/pin via kubo HTTP API) - Service sanctuaire : pipeline SHA-256 + IPFS + on-chain (system.remark) - Verification integrite des entrees sanctuaire - Recherche par reference (document -> entrees sanctuaire) - Serialisation deterministe des documents pour archivage - 14 tests unitaires supplementaires (document service) Frontend: - 9 composants : StatusBadge, MarkdownRenderer, DiffView, ItemCard, ItemVersionDiff, DocumentList, SanctuaryEntry, IPFSLink, ChainAnchor - Page detail item avec historique des versions et diff - Page detail sanctuaire avec verification integrite - Modal de creation de document + proposition de version - Archivage document vers sanctuaire depuis la page detail Documentation: - API reference mise a jour (9 nouveaux endpoints) - Guides utilisateur documents et sanctuaire enrichis Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
142 lines
6.0 KiB
Markdown
142 lines
6.0 KiB
Markdown
---
|
|
title: Sanctuaire
|
|
description: Guide de l'archivage immuable sur Glibredecision
|
|
---
|
|
|
|
# Sanctuaire
|
|
|
|
## Principe
|
|
|
|
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 :
|
|
|
|
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
|
|
|
|
## 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
|
|
|
|
## Types d'entrees
|
|
|
|
| Type | Description |
|
|
| ------------ | ------------------------------------------------ |
|
|
| Document | Version adoptee d'un document de reference |
|
|
| Decision | Decision finalisee avec son resultat |
|
|
| Vote result | Resultat detaille d'une session de vote |
|
|
|
|
## Consulter le Sanctuaire
|
|
|
|
1. Rendez-vous dans la section **Sanctuaire**.
|
|
2. Filtrez par type d'entree si necessaire.
|
|
3. Chaque entree affiche :
|
|
- Le titre
|
|
- Le hash SHA-256 du contenu
|
|
- Le CID IPFS (lien vers le contenu sur IPFS)
|
|
- Le hash de la transaction on-chain
|
|
- Le numero de bloc
|
|
- La date d'archivage
|
|
|
|
## Consulter les entrees par document de reference
|
|
|
|
Pour retrouver toutes les entrees du Sanctuaire liees a un document, une decision ou une session de vote specifique :
|
|
|
|
1. Depuis la fiche du document (ou de la decision), cliquez sur **Voir dans le Sanctuaire**.
|
|
2. La liste affiche toutes les entrees archivees associees a cette entite source.
|
|
3. Vous pouvez aussi acceder directement a cette vue via l'URL : `/sanctuaire/par-reference/{id}`.
|
|
|
|
Cette fonctionnalite permet de retracer l'historique complet d'archivage d'un document au fil de ses modifications adoptees.
|
|
|
|
## Verification d'integrite
|
|
|
|
### Verification automatique
|
|
|
|
Glibredecision propose une verification automatique d'integrite pour chaque entree du Sanctuaire :
|
|
|
|
1. Ouvrez l'entree a verifier dans le Sanctuaire.
|
|
2. Cliquez sur **Verifier l'integrite**.
|
|
3. Le systeme effectue automatiquement trois controles :
|
|
- **Hash SHA-256** : le hash est recalcule a partir du contenu source et compare avec le hash enregistre.
|
|
- **IPFS** : le contenu est recupere via le CID IPFS et verifie (si le CID est renseigne).
|
|
- **On-chain** : le hash est recherche dans le `system.remark` du bloc reference sur la blockchain Duniter V2 (si le hash de transaction est renseigne).
|
|
4. Le resultat affiche pour chaque controle un indicateur **valide** ou **invalide**.
|
|
|
|
::callout{type="info"}
|
|
Si les trois controles sont valides, le contenu est authentique et n'a pas ete modifie depuis son archivage.
|
|
::
|
|
|
|
### Verification manuelle
|
|
|
|
Pour une verification independante de la plateforme :
|
|
|
|
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).
|
|
|
|
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 :
|
|
|
|
```bash
|
|
ipfs cat {CID}
|
|
```
|
|
|
|
Ou le telecharger :
|
|
|
|
```bash
|
|
ipfs get {CID} -o document_archive.txt
|
|
```
|
|
|
|
## Comprendre les informations d'ancrage on-chain
|
|
|
|
Chaque entree du Sanctuaire affiche des informations relatives a son ancrage sur la blockchain Duniter V2 :
|
|
|
|
| Information | Description |
|
|
| -------------------- | -------------------------------------------------------- |
|
|
| Hash de transaction | Identifiant unique de la transaction `system.remark` contenant le hash du contenu |
|
|
| 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 :
|
|
|
|
- Quand une version d'item de document est **acceptee**, le nouveau texte est archive.
|
|
- 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.
|