v3 : socle Rust (moteur pur, accès trustinWallet, serveur) ; maquette Nuxt rangée dans maquette/
- crates/ld-engine : formule inertielle (parité avec la maquette, garde C), coquille / changement de fond, assistant d'édition à règles, composition d'un document sous vote permanent (adoptions, aperçus, rivales). - crates/trustin-access : qui voit, qui ouvre, qui gère les accès. - crates/ld-server : API axum + SQLite, connexion Ğ1 (client OAuth2 de connect.monnaie-libre.fr), invitations, entrée en vigueur automatique, signalements de contradiction, traductions éditoriales, publication git, taille de la toile lue sur la chaîne. - seeds/acte-engagement-certification.json : 33 articles, fr + en + es ; en vigueur : préambule, E1, E2 (seed a minima). - maquette/ : frontend, backend et docker v2 déplacés tels quels. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
@@ -0,0 +1,49 @@
|
||||
---
|
||||
title: Documentation utilisateur
|
||||
description: Guide d'utilisation de la plateforme libreDecision
|
||||
---
|
||||
|
||||
# Documentation utilisateur
|
||||
|
||||
Bienvenue dans la documentation utilisateur de libreDecision, la plateforme de decisions collectives pour la communaute Duniter/G1.
|
||||
|
||||
## Qu'est-ce que libreDecision ?
|
||||
|
||||
libreDecision est une plateforme de gouvernance decentralisee qui permet aux membres de la Toile de Confiance (WoT) Duniter de :
|
||||
|
||||
- Gerer des **documents de reference** modulaires (Licence G1, Engagements Forgeron, Reglement du Comite Technique, etc.) sous vote permanent
|
||||
- Prendre des **decisions collectives** via des processus multi-etapes (qualification, examen, vote, execution, rapport)
|
||||
- **Voter** avec un systeme de seuil adaptatif base sur la participation : plus la participation est faible, plus le seuil est exigeant (mecanisme d'inertie)
|
||||
- Attribuer des **mandats** a des membres de la communaute via des elections formelles
|
||||
- **Archiver de maniere immuable** les decisions adoptees via IPFS et la blockchain Duniter (triple preuve SHA-256 + IPFS + on-chain)
|
||||
|
||||
La plateforme est entierement transparente : tous les votes sont publics, signes cryptographiquement et verifiables par quiconque.
|
||||
|
||||
## Guides disponibles
|
||||
|
||||
| Guide | Description |
|
||||
| ----- | ----------- |
|
||||
| [Premiers pas](/user/getting-started) | Prerequis, premiere connexion, tour de l'interface, premier vote |
|
||||
| [Documents](/user/documents) | Consulter les documents de reference, proposer des modifications, vote permanent |
|
||||
| [Decisions](/user/decisions) | Comprendre et participer aux processus decisionnels multi-etapes |
|
||||
| [Vote](/user/voting) | Types de vote, formule de seuil expliquee, comment voter, jauge de seuil, simulateur |
|
||||
| [Mandats](/user/mandates) | Elections, candidatures, assignation, reporting, revocation |
|
||||
| [Sanctuaire](/user/sanctuary) | Archivage immuable, triple preuve, verification d'integrite |
|
||||
| [FAQ](/user/faq) | Reponses aux questions frequentes sur l'authentification, le vote, les documents, la securite |
|
||||
|
||||
## Par ou commencer ?
|
||||
|
||||
1. **Nouveau sur libreDecision ?** Commencez par le guide [Premiers pas](/user/getting-started) pour vous connecter et decouvrir l'interface.
|
||||
2. **Vous voulez voter ?** Consultez le guide [Vote](/user/voting) pour comprendre les types de vote et la formule de seuil.
|
||||
3. **Vous voulez proposer une modification ?** Le guide [Documents](/user/documents) explique comment proposer des modifications aux textes fondateurs.
|
||||
4. **Une question ?** La [FAQ](/user/faq) repond aux questions les plus courantes.
|
||||
|
||||
## Contribuer a la documentation
|
||||
|
||||
Cette documentation est elle-meme un document en evolution. Si vous constatez une erreur, une imprecision ou un manque, vous pouvez :
|
||||
|
||||
- Ouvrir une issue sur le [depot Git](https://git.duniter.org/tools/libredecision) de libreDecision
|
||||
- Proposer une modification directement via une merge request
|
||||
- En discuter sur le [forum Duniter](https://forum.duniter.org)
|
||||
|
||||
La documentation est redigee en Markdown et fait partie du code source du projet (dossier `docs/`). Les contributions suivent le meme processus que le code : branche, merge request, revue.
|
||||
@@ -0,0 +1,181 @@
|
||||
---
|
||||
title: Premiers pas
|
||||
description: Connexion et prise en main de libreDecision
|
||||
---
|
||||
|
||||
# Premiers pas
|
||||
|
||||
Ce guide vous accompagne de votre premiere visite jusqu'a votre premier vote sur libreDecision.
|
||||
|
||||
## Prerequis
|
||||
|
||||
Avant de commencer, assurez-vous de disposer de :
|
||||
|
||||
| Prerequis | Description | Ou l'obtenir |
|
||||
| --------- | ----------- | ------------ |
|
||||
| **Navigateur moderne** | Chrome, Firefox, Edge ou Safari a jour | Mis a jour automatiquement |
|
||||
| **Extension Polkadot.js** | Extension de signature pour Substrate/Duniter V2 | [polkadot.js.org/extension](https://polkadot.js.org/extension/) |
|
||||
| **Identite Duniter V2** | Adresse SS58 avec une identite confirmee dans la Toile de Confiance | Via Cesium2 ou directement sur la blockchain Duniter V2 |
|
||||
|
||||
::callout{type="info"}
|
||||
Vous pouvez **consulter** les documents, decisions et resultats de vote sans aucune authentification. Seules les actions de participation (voter, proposer, creer) necessitent une identite Duniter.
|
||||
::
|
||||
|
||||
### Installer l'extension Polkadot.js
|
||||
|
||||
1. Rendez-vous sur [polkadot.js.org/extension](https://polkadot.js.org/extension/).
|
||||
2. Installez l'extension pour votre navigateur (Chrome ou Firefox).
|
||||
3. Creez ou importez votre compte Duniter V2 dans l'extension.
|
||||
4. Assurez-vous que votre adresse SS58 est bien celle liee a votre identite Duniter.
|
||||
|
||||
## Qui peut utiliser libreDecision ?
|
||||
|
||||
libreDecision est ouvert a tous les membres de la Toile de Confiance (WoT) Duniter V2. Pour utiliser pleinement la plateforme, vous devez posseder une identite Duniter avec une adresse SS58 valide.
|
||||
|
||||
- **Consultation** : tout visiteur peut consulter les documents, decisions et resultats de vote.
|
||||
- **Participation** (voter, proposer) : reservee aux membres authentifies via leur identite Duniter.
|
||||
|
||||
## Premiere connexion
|
||||
|
||||
La connexion utilise votre identite Duniter sans jamais transmettre votre cle privee. Le mecanisme est un **challenge-response** cryptographique :
|
||||
|
||||
### Comment ca marche (en termes simples)
|
||||
|
||||
Imaginez que la plateforme vous montre une phrase aleatoire et vous demande de la signer avec votre cle privee. C'est comme signer un document avec un stylo que vous seul possedez. La plateforme peut verifier que c'est bien votre signature grace a votre cle publique, sans jamais voir votre cle privee.
|
||||
|
||||
### Etape par etape
|
||||
|
||||
1. Cliquez sur **Se connecter** dans la barre de navigation.
|
||||
2. Saisissez votre **adresse Duniter** (format SS58, par exemple `5GrwvaEF...`).
|
||||
3. La plateforme vous envoie un **challenge** : un texte aleatoire de 64 caracteres hexadecimaux.
|
||||
4. Votre extension Polkadot.js (ou votre portefeuille Cesium) vous demande d'autoriser la signature du challenge avec votre cle privee Ed25519.
|
||||
5. Signez le challenge. Votre cle privee ne quitte jamais votre appareil.
|
||||
6. Soumettez la signature. La plateforme verifie que vous etes bien le proprietaire de l'adresse.
|
||||
7. Vous etes connecte. Un jeton de session est stocke localement (valable 24 heures).
|
||||
|
||||
::callout{type="tip"}
|
||||
Votre cle privee n'est **jamais** transmise au serveur. Seule la signature du challenge est envoyee. C'est le principe fondamental de l'authentification par challenge-response Ed25519.
|
||||
::
|
||||
|
||||
## Tour de l'interface
|
||||
|
||||
### Barre de navigation
|
||||
|
||||
La barre de navigation en haut de page contient :
|
||||
|
||||
- **Logo libreDecision** : retour a l'accueil
|
||||
- **Menu principal** : acces aux cinq sections
|
||||
- **Bouton de connexion** / **Votre profil** (si connecte)
|
||||
- **Indicateur temps reel** : point colore indiquant l'etat de la connexion WebSocket
|
||||
|
||||
### Sidebar (menu lateral)
|
||||
|
||||
La sidebar sur la gauche donne acces aux cinq sections principales :
|
||||
|
||||
| Section | Icone | Description |
|
||||
| ------------ | ----- | ---------------------------------------------------- |
|
||||
| Documents | -- | Documents de reference de la communaute |
|
||||
| Decisions | -- | Processus decisionnels en cours et archives |
|
||||
| Votes | -- | Sessions de vote actives et resultats |
|
||||
| Mandats | -- | Mandats attribues aux membres |
|
||||
| Sanctuaire | -- | Archives immuables (IPFS + blockchain) |
|
||||
|
||||
### Dashboard (tableau de bord)
|
||||
|
||||
Apres connexion, le tableau de bord affiche un apercu rapide de :
|
||||
|
||||
- **Votes en cours** : les sessions de vote ouvertes auxquelles vous pouvez participer
|
||||
- **Vos derniers votes** : historique de vos votes recents
|
||||
- **Decisions actives** : les processus decisionnels en cours
|
||||
- **Mandats** : les mandats actifs et en cours d'election
|
||||
- **Activite recente** : flux des dernieres actions sur la plateforme
|
||||
|
||||
## Votre profil
|
||||
|
||||
Apres connexion, votre profil affiche :
|
||||
|
||||
- Votre **adresse Duniter** SS58
|
||||
- Votre **nom d'affichage** (si configure)
|
||||
- Votre **statut WoT** : membre, en attente, revoque
|
||||
- Vos **roles** : membre Smith (forgeron) et/ou membre du Comite Technique
|
||||
|
||||
Ces informations sont synchronisees depuis la blockchain Duniter V2 et determinent vos droits de vote.
|
||||
|
||||
## Premier vote : voter sur un item de document
|
||||
|
||||
Voici comment participer a votre premier vote en quelques minutes :
|
||||
|
||||
### 1. Trouver un vote ouvert
|
||||
|
||||
- Depuis le tableau de bord, consultez la section **Votes en cours**.
|
||||
- Ou rendez-vous dans la section **Votes** du menu et filtrez par statut "En cours".
|
||||
- Les sessions ouvertes sont signalees par un badge vert.
|
||||
|
||||
### 2. Lire le sujet
|
||||
|
||||
- Cliquez sur la session de vote qui vous interesse.
|
||||
- Lisez attentivement le texte soumis au vote (document, decision, modification d'item).
|
||||
- Consultez le diff si c'est une modification : les ajouts sont en vert, les suppressions en rouge.
|
||||
|
||||
### 3. Voter
|
||||
|
||||
- **Vote binaire** : cliquez sur **Pour** (vert) ou **Contre** (rouge).
|
||||
- **Vote nuance** : choisissez un niveau de 0 (CONTRE) a 5 (TOUT A FAIT) sur l'echelle proposee.
|
||||
- Ajoutez un **commentaire** si vous souhaitez expliquer votre choix (optionnel mais recommande).
|
||||
|
||||
### 4. Signer votre vote
|
||||
|
||||
- Apres avoir choisi, la plateforme genere un payload contenant votre vote, l'identifiant de la session et un horodatage.
|
||||
- Votre extension Polkadot.js vous demande de signer ce payload.
|
||||
- Signez, puis cliquez sur **Soumettre**.
|
||||
|
||||
### 5. Verification
|
||||
|
||||
- Un message de confirmation apparait.
|
||||
- Votre vote est visible dans la liste des votes de la session.
|
||||
- La jauge de seuil se met a jour en temps reel pour refleter votre vote.
|
||||
|
||||
::callout{type="info"}
|
||||
Vous pouvez modifier votre vote a tout moment tant que la session est ouverte. L'ancien vote est conserve pour l'audit mais seul le dernier compte.
|
||||
::
|
||||
|
||||
## Premiers pas avec les decisions
|
||||
|
||||
Au-dela du vote, vous pouvez participer activement a la gouvernance :
|
||||
|
||||
### Proposer une modification de document
|
||||
|
||||
1. Ouvrez un document de reference dans la section **Documents**.
|
||||
2. Selectionnez l'item (clause, regle, article) que vous souhaitez modifier.
|
||||
3. Cliquez sur **Proposer une modification**.
|
||||
4. Redigez votre nouveau texte et justifiez votre proposition.
|
||||
5. Soumettez : un diff est genere automatiquement.
|
||||
|
||||
Votre proposition sera examinee et soumise au vote par la communaute.
|
||||
|
||||
### Creer une decision
|
||||
|
||||
1. Rendez-vous dans la section **Decisions**.
|
||||
2. Cliquez sur **Nouvelle decision**.
|
||||
3. Renseignez le titre, la description et le contexte.
|
||||
4. Choisissez le type de decision et le protocole de vote.
|
||||
5. Definissez les etapes du processus.
|
||||
|
||||
### Consulter le Sanctuaire
|
||||
|
||||
Le Sanctuaire contient les archives immuables de toutes les decisions adoptees, documents archives et resultats de vote. Rendez-vous dans la section **Sanctuaire** pour explorer l'historique verifiable de la communaute.
|
||||
|
||||
## Deconnexion
|
||||
|
||||
Cliquez sur votre profil puis **Se deconnecter**. La session est invalidee cote serveur et le jeton local est supprime.
|
||||
|
||||
## Pour aller plus loin
|
||||
|
||||
| Guide | Description |
|
||||
| ----- | ----------- |
|
||||
| [Documents](/user/documents) | Tout savoir sur les documents de reference et leurs modifications |
|
||||
| [Decisions](/user/decisions) | Comprendre les processus decisionnels multi-etapes |
|
||||
| [Vote](/user/voting) | Comprendre les types de vote, la formule de seuil et le simulateur |
|
||||
| [Mandats](/user/mandates) | Elections et responsabilites au sein de la communaute |
|
||||
| [Sanctuaire](/user/sanctuary) | Archivage immuable et verification d'integrite |
|
||||
| [FAQ](/user/faq) | Reponses aux questions frequentes |
|
||||
@@ -0,0 +1,233 @@
|
||||
---
|
||||
title: Documents
|
||||
description: Guide des documents de reference sur libreDecision
|
||||
---
|
||||
|
||||
# Documents de reference
|
||||
|
||||
## Qu'est-ce qu'un document de reference ?
|
||||
|
||||
Un document de reference est un **texte fondateur** de la communaute Duniter/G1. Il peut s'agir d'une licence monetaire, d'un engagement que les membres s'engagent a respecter, d'un reglement interieur ou d'un texte constitutif. Ces documents definissent les regles, les valeurs et le fonctionnement de la communaute.
|
||||
|
||||
Ce qui rend libreDecision unique, c'est que ces documents sont **modulaires** et sous **vote permanent** : chaque document est compose d'items individuels (clauses, regles, verifications, preambules, sections) qui peuvent etre modifies independamment par proposition et vote. La communaute peut faire evoluer ses textes de maniere continue, sans procedure lourde ni periode speciale.
|
||||
|
||||
## Types de documents
|
||||
|
||||
| Type | Description | Exemples |
|
||||
| -------------- | --------------------------------------------------- | -------------------------------- |
|
||||
| Licence | Licence monetaire definissant les regles de la monnaie | Licence G1 |
|
||||
| Engagement | Engagement des membres a respecter des regles | Engagement Forgeron v2.0.0 |
|
||||
| Reglement | Reglement interieur d'un organe | Reglement du Comite Technique |
|
||||
| Constitution | Texte constitutif fondamental | -- |
|
||||
|
||||
## Structure : Document, Items et Versions
|
||||
|
||||
Un document est organise selon une structure a trois niveaux :
|
||||
|
||||
```
|
||||
Document (ex: Licence G1 v2.0.0)
|
||||
|
|
||||
+-- Item 1 (clause 1 : Preambule)
|
||||
| |-- Version 1.0 (texte courant)
|
||||
| |-- Version 1.1 (proposition en attente)
|
||||
|
|
||||
+-- Item 2 (regle 2.1 : Conditions d'adhesion)
|
||||
| |-- Version 1.0 (texte courant)
|
||||
|
|
||||
+-- Item 3 (verification 3.1 : Distance rule)
|
||||
|-- Version 1.0 (texte courant)
|
||||
|-- Version 1.1 (proposition rejetee)
|
||||
|-- Version 1.2 (proposition en vote)
|
||||
```
|
||||
|
||||
### Document
|
||||
|
||||
Le document est le conteneur. Il possede un titre, un type, un numero de version semantique (ex: `2.0.0`), un statut et une description.
|
||||
|
||||
### Item
|
||||
|
||||
Chaque item est une unite modulaire du document : une clause, une regle, une verification, un preambule ou une section. Chaque item a une position hierarchique (ex: "1", "1.1", "3.2") et un texte courant.
|
||||
|
||||
### Version
|
||||
|
||||
Chaque modification proposee a un item cree une nouvelle version. La version contient le texte propose, un diff automatique par rapport au texte courant, et la justification de l'auteur. Les versions suivent un cycle de vie : proposee, en vote, acceptee ou rejetee.
|
||||
|
||||
## Consulter un document
|
||||
|
||||
1. Rendez-vous dans la section **Documents**.
|
||||
2. Utilisez les filtres (type, statut) pour trouver le document souhaite.
|
||||
3. Cliquez sur le document pour voir la liste de ses items.
|
||||
4. Chaque item affiche son texte courant, son type et sa position dans le document.
|
||||
|
||||
### Voir un item en detail
|
||||
|
||||
Pour consulter un item specifique avec tout son historique :
|
||||
|
||||
1. Depuis la liste des items du document, cliquez sur l'item souhaite.
|
||||
2. La vue detaillee affiche :
|
||||
- Le **texte courant** de l'item.
|
||||
- Le **type** (clause, regle, verification, preambule, section) et la **position** hierarchique.
|
||||
- Le **protocole de vote** specifique a cet item (s'il en a un).
|
||||
- L'**historique des versions** proposees, avec pour chacune son statut (proposee, en vote, acceptee, rejetee).
|
||||
3. Pour chaque version, vous pouvez consulter le **diff** (differences entre le texte courant et le texte propose) ainsi que la **justification** de l'auteur.
|
||||
|
||||
## Proposer une modification (version)
|
||||
|
||||
Tout membre authentifie peut proposer une modification a un item de document :
|
||||
|
||||
1. Ouvrez le document et selectionnez l'item a modifier.
|
||||
2. Cliquez sur **Proposer une modification**.
|
||||
3. Redigez le **nouveau texte propose**.
|
||||
4. Ajoutez une **justification** expliquant pourquoi cette modification est necessaire.
|
||||
5. Soumettez. Un diff automatique est genere entre le texte courant et votre proposition.
|
||||
|
||||
La proposition cree une nouvelle **version** de l'item. Cette version passe ensuite par un processus de decision (examen, vote) avant d'etre acceptee ou rejetee.
|
||||
|
||||
::callout{type="info"}
|
||||
Plusieurs versions peuvent etre proposees simultanement pour un meme item. Lorsqu'une version est acceptee, toutes les autres versions en attente sont automatiquement rejetees.
|
||||
::
|
||||
|
||||
## Vote permanent sur les items
|
||||
|
||||
Les documents actifs sont sous **vote permanent** : il n'y a pas de periode speciale pour proposer des changements. A tout moment, un membre authentifie peut proposer une modification a n'importe quel item.
|
||||
|
||||
Chaque item peut avoir un **protocole de vote specifique** qui definit les parametres de seuil (duree, majorite, gradient, criteres Smith/TechComm). Si aucun protocole specifique n'est defini, le protocole par defaut du document s'applique.
|
||||
|
||||
Le vote permanent garantit que les textes fondateurs peuvent evoluer de maniere continue et organique, en refletant en permanence la volonte de la communaute.
|
||||
|
||||
## Examiner et accepter/rejeter une version
|
||||
|
||||
Les membres habilites (selon le protocole de vote associe) peuvent examiner les versions proposees :
|
||||
|
||||
### Consulter les versions en attente
|
||||
|
||||
1. Ouvrez le document et selectionnez l'item concerne.
|
||||
2. Consultez la liste des **versions proposees** dans l'onglet historique.
|
||||
3. Chaque version affiche :
|
||||
- Le **texte propose** et le **diff** par rapport au texte courant.
|
||||
- La **justification** fournie par l'auteur.
|
||||
- Le **statut** actuel (proposee, en vote, acceptee, rejetee).
|
||||
- L'**identite** du proposant.
|
||||
|
||||
### Accepter une version
|
||||
|
||||
1. Selectionnez la version a accepter.
|
||||
2. Cliquez sur **Accepter cette version**.
|
||||
3. Le texte propose **remplace automatiquement** le texte courant de l'item.
|
||||
4. Toutes les autres versions en statut `proposee` ou `en vote` pour cet item sont **automatiquement rejetees**.
|
||||
|
||||
### Rejeter une version
|
||||
|
||||
1. Selectionnez la version a rejeter.
|
||||
2. Cliquez sur **Rejeter cette version**.
|
||||
3. Le texte courant de l'item **reste inchange**.
|
||||
4. La version est archivee avec le statut `rejetee`.
|
||||
|
||||
## Cycle de vie d'une proposition
|
||||
|
||||
```
|
||||
Proposee --> En vote --> Acceptee --> Texte courant mis a jour
|
||||
--> Rejetee --> Archivee
|
||||
```
|
||||
|
||||
## Cycle de vie d'un document
|
||||
|
||||
Un document suit un cycle de vie en trois etapes :
|
||||
|
||||
```
|
||||
Brouillon --> Actif --> Archive
|
||||
```
|
||||
|
||||
### Brouillon (draft)
|
||||
|
||||
Le document est en cours de redaction. Les items peuvent etre ajoutes, modifies, supprimes et reordonnes librement. Le document n'est pas encore soumis au vote permanent.
|
||||
|
||||
### Actif (active)
|
||||
|
||||
Le document est en vigueur et sous **vote permanent**. Tout membre authentifie peut proposer des modifications aux items via le systeme de versions. Les modifications sont soumises au processus de decision (qualification, examen, vote) avant d'etre appliquees.
|
||||
|
||||
### Archive (archived)
|
||||
|
||||
Le document a ete archive dans le **Sanctuaire**. Son contenu est fige et preserve de maniere immuable via :
|
||||
|
||||
- Un hash SHA-256 pour garantir l'integrite.
|
||||
- Un stockage sur IPFS pour la distribution decentralisee.
|
||||
- Un ancrage on-chain via `system.remark` sur Duniter V2.
|
||||
|
||||
Un document archive ne peut plus etre modifie. Pour le consulter, rendez-vous dans la section Sanctuaire.
|
||||
|
||||
## Statuts des documents
|
||||
|
||||
| Statut | Description |
|
||||
| --------- | ------------------------------------------------ |
|
||||
| Brouillon | En cours de redaction, non soumis au vote |
|
||||
| Actif | Document en vigueur, sous vote permanent |
|
||||
| Archive | Document archive dans le Sanctuaire, plus modifiable |
|
||||
|
||||
## Archiver un document dans le Sanctuaire
|
||||
|
||||
Pour archiver un document actif (necessite une authentification) :
|
||||
|
||||
1. Ouvrez le document actif a archiver.
|
||||
2. Cliquez sur **Archiver dans le Sanctuaire**.
|
||||
3. Le systeme effectue automatiquement :
|
||||
- La serialisation complete du document (metadonnees + tous les items).
|
||||
- Le calcul du hash SHA-256 du contenu.
|
||||
- L'envoi du contenu sur IPFS.
|
||||
- L'ancrage du hash on-chain.
|
||||
4. Le statut du document passe a **Archive**.
|
||||
5. Les champs **CID IPFS** et **ancrage on-chain** sont renseignes sur le document.
|
||||
|
||||
::callout{type="warning"}
|
||||
L'archivage est une operation irreversible. Une fois archive, le document ne peut plus etre modifie.
|
||||
::
|
||||
|
||||
## Versionnage
|
||||
|
||||
Chaque document possede un numero de version semantique (ex: `2.0.0`). Chaque modification adoptee peut entrainer une mise a jour de version selon l'importance du changement.
|
||||
|
||||
## Exemple concret : modifier un article de la Licence G1
|
||||
|
||||
Prenons un exemple complet de bout en bout. Vous souhaitez modifier la regle de distance (item 3.1) de la Licence G1 pour preciser une condition supplementaire.
|
||||
|
||||
### 1. Trouver l'item
|
||||
|
||||
- Rendez-vous dans **Documents** et ouvrez la **Licence G1**.
|
||||
- Faites defiler jusqu'a l'item **3.1 -- Distance rule** et cliquez dessus.
|
||||
|
||||
### 2. Consulter le texte courant
|
||||
|
||||
- Lisez le texte en vigueur et l'historique des versions precedentes.
|
||||
- Verifiez que votre modification n'a pas deja ete proposee par quelqu'un d'autre.
|
||||
|
||||
### 3. Proposer votre modification
|
||||
|
||||
- Cliquez sur **Proposer une modification**.
|
||||
- Redigez votre nouveau texte. Par exemple, ajoutez une precision sur le nombre de pas de distance autorise.
|
||||
- Dans le champ **Justification**, expliquez pourquoi : "La regle actuelle ne precise pas le cas ou un membre est a la limite exacte de la distance maximale. Cette modification clarifie que la distance est inclusive."
|
||||
- Soumettez votre proposition.
|
||||
|
||||
### 4. Le diff est genere
|
||||
|
||||
Le systeme genere automatiquement un diff montrant les differences :
|
||||
|
||||
```diff
|
||||
- Le membre doit respecter la regle de distance WoT.
|
||||
+ Le membre doit respecter la regle de distance WoT. La distance
|
||||
+ maximale est inclusive : un membre a exactement 5 pas est conforme.
|
||||
```
|
||||
|
||||
### 5. Examen et vote
|
||||
|
||||
- La communaute peut consulter votre proposition, lire votre justification et examiner le diff.
|
||||
- Si un processus de decision est lance, une session de vote est creee.
|
||||
- Les membres votent selon le protocole de vote associe a cet item.
|
||||
|
||||
### 6. Resultat
|
||||
|
||||
- **Si acceptee** : votre texte remplace le texte courant de l'item 3.1. Toutes les autres propositions en attente pour cet item sont automatiquement rejetees. Le numero de version du document peut etre mis a jour.
|
||||
- **Si rejetee** : le texte courant reste inchange. Votre proposition est archivee avec le statut "rejetee" pour transparence.
|
||||
|
||||
### 7. Archivage
|
||||
|
||||
Si la modification est suffisamment importante, le document mis a jour peut etre archive dans le Sanctuaire, creant une trace immuable de cette evolution.
|
||||
@@ -0,0 +1,142 @@
|
||||
---
|
||||
title: Decisions
|
||||
description: Guide des processus decisionnels sur libreDecision
|
||||
---
|
||||
|
||||
# Decisions
|
||||
|
||||
## Principe
|
||||
|
||||
Une decision est un processus structure qui conduit a un choix collectif. Chaque decision suit un ensemble d'etapes definies, de la qualification a l'execution. Le systeme garantit la tracabilite de chaque etape et l'integration avec le systeme de vote WoT.
|
||||
|
||||
## Types de decisions
|
||||
|
||||
| Type | Description | Cas d'usage |
|
||||
| ------------------ | ------------------------------------------------------ | -------------------------------------------------------- |
|
||||
| `runtime_upgrade` | Mise a jour du runtime de la blockchain Duniter | Upgrade du reseau, changement de parametres consensus |
|
||||
| `document_change` | Modification d'un item de document de reference | Amendement de la Licence G1, modification d'un engagement |
|
||||
| `mandate_vote` | Vote pour l'attribution d'un mandat | Election d'un membre du Comite Technique |
|
||||
| `parameter_change` | Modification de parametres systeme | Changement de duree de vote, seuil de majorite |
|
||||
| `custom` | Decision personnalisee | Tout autre type de decision collective |
|
||||
|
||||
## Cycle de vie d'une decision
|
||||
|
||||
Une decision progresse a travers six statuts successifs :
|
||||
|
||||
```
|
||||
Brouillon --> Qualification --> Examen --> Vote --> Executee --> Cloturee
|
||||
|
|
||||
+--> Rejetee (si le vote echoue)
|
||||
```
|
||||
|
||||
| Statut | Description |
|
||||
| ----------------- | ---------------------------------------------------------------- |
|
||||
| `draft` | Brouillon initial. La decision est en cours de redaction et peut etre modifiee librement ou supprimee. |
|
||||
| `qualification` | Phase de verification. On s'assure que la proposition est recevable (forme, competence, pertinence). |
|
||||
| `review` | Periode d'examen et de discussion par la communaute. Les membres peuvent commenter et suggerer des amendements. |
|
||||
| `voting` | Session de vote formelle. Le seuil de validation WoT s'applique. Une session de vote est creee et liee a l'etape correspondante. |
|
||||
| `executed` | La decision a ete adoptee et est en cours de mise en oeuvre. |
|
||||
| `closed` | La decision est cloturee. Le resultat est archive dans le sanctuaire. |
|
||||
|
||||
Si le vote echoue (seuil non atteint), la decision passe en statut "rejetee" et ne peut plus avancer.
|
||||
|
||||
## Etapes d'une decision (decision_steps)
|
||||
|
||||
Chaque decision est composee d'etapes ordonnees qui definissent le workflow concret. Les types d'etapes disponibles sont :
|
||||
|
||||
| Type d'etape | Description |
|
||||
| --------------- | ---------------------------------------------------------------- |
|
||||
| `qualification` | Verification que la proposition est recevable |
|
||||
| `review` | Periode d'examen et de discussion par la communaute |
|
||||
| `vote` | Session de vote formelle avec seuil de validation WoT |
|
||||
| `execution` | Mise en oeuvre de la decision adoptee |
|
||||
| `reporting` | Compte-rendu de l'execution et archivage des resultats |
|
||||
|
||||
Chaque etape possede un statut individuel :
|
||||
|
||||
| Statut | Description |
|
||||
| ----------- | ---------------------------------------------------------- |
|
||||
| `pending` | L'etape n'a pas encore commence |
|
||||
| `active` | L'etape est en cours |
|
||||
| `completed` | L'etape est terminee avec succes |
|
||||
| `skipped` | L'etape a ete ignoree (non applicable pour ce type de decision) |
|
||||
|
||||
## Comment le workflow avance
|
||||
|
||||
Le workflow d'une decision avance via l'action **"Avancer"** (endpoint `POST /decisions/{id}/advance`). A chaque appel :
|
||||
|
||||
1. **S'il y a une etape active** : elle est marquee `completed`, et la prochaine etape `pending` est activee.
|
||||
2. **S'il n'y a pas d'etape active** : la premiere etape `pending` est activee. Si la decision est en `draft`, elle passe automatiquement en `qualification`.
|
||||
3. **Si toutes les etapes sont terminees** : le statut global de la decision avance au statut suivant dans le cycle de vie.
|
||||
|
||||
Ce mecanisme garantit que les etapes sont parcourues dans l'ordre defini (`step_order`) et qu'aucune etape ne peut etre sautee involontairement.
|
||||
|
||||
## Creation d'une session de vote
|
||||
|
||||
Quand une etape de type `vote` est active, il faut creer une session de vote liee a cette etape. Cela se fait via l'action **"Creer une session de vote"** (endpoint `POST /decisions/{id}/steps/{step_id}/create-vote-session`).
|
||||
|
||||
La session de vote :
|
||||
- Est automatiquement liee au protocole de vote de la decision
|
||||
- Prend un snapshot des tailles WoT, Smith et TechComm au moment de la creation
|
||||
- Calcule la date de fin en fonction de la duree definie dans la formule du protocole
|
||||
- Est rattachee a l'etape via le champ `vote_session_id`
|
||||
|
||||
Une fois la session de vote cloturee (manuellement ou par expiration), l'etape peut etre completee et le workflow peut avancer.
|
||||
|
||||
## Creer une decision
|
||||
|
||||
Les membres authentifies peuvent creer une decision :
|
||||
|
||||
1. Cliquez sur **Nouvelle decision**.
|
||||
2. Renseignez le **titre** : un intitule clair et concis de la proposition.
|
||||
3. Renseignez la **description** : le detail de ce qui est propose.
|
||||
4. Renseignez le **contexte** : pourquoi cette decision est necessaire (cadrage).
|
||||
5. Choisissez le **type de decision** : `runtime_upgrade`, `document_change`, `mandate_vote`, `parameter_change` ou `custom`.
|
||||
6. Selectionnez un **protocole de vote** qui definit les parametres de la formule de seuil WoT (duree, majorite, gradient, criteres Smith/TechComm).
|
||||
7. **Ajoutez les etapes** necessaires dans l'ordre souhaite (qualification, examen, vote, execution, reporting).
|
||||
8. Soumettez. La decision est creee en statut `draft`.
|
||||
9. Utilisez l'action **"Avancer"** pour lancer la premiere etape et demarrer le processus.
|
||||
|
||||
## Supprimer une decision
|
||||
|
||||
Les decisions en statut `draft` peuvent etre supprimees via l'action **"Supprimer"** (endpoint `DELETE /decisions/{id}`). Une fois le processus demarre (statut `qualification` ou au-dela), la decision reste dans le systeme pour tracabilite.
|
||||
|
||||
## Suivre une decision
|
||||
|
||||
1. Rendez-vous dans la section **Decisions**.
|
||||
2. Filtrez par type ou statut pour trouver la decision qui vous interesse.
|
||||
3. La page de detail affiche toutes les etapes avec leur statut (en attente, active, terminee, ignoree).
|
||||
4. Si une etape de vote est active et qu'une session de vote est ouverte, vous pouvez voter directement depuis la page de decision.
|
||||
5. Le resultat du vote (seuil, participation, criteres Smith/TechComm) est affiche en temps reel.
|
||||
|
||||
## Exemple : Processus de Runtime Upgrade
|
||||
|
||||
Un Runtime Upgrade suit un processus en 5 etapes strictement definies :
|
||||
|
||||
```
|
||||
1. Qualification -> Verification technique par le Comite Technique
|
||||
2. Examen -> Review du code par les forgerons, discussion communautaire
|
||||
3. Vote -> Vote WoT avec criteres Smith et TechComm obligatoires
|
||||
4. Execution -> Deploiement du runtime sur le reseau
|
||||
5. Reporting -> Compte-rendu post-deploiement, verification de stabilite
|
||||
```
|
||||
|
||||
**Deroulement concret :**
|
||||
|
||||
1. Un membre cree une decision de type `runtime_upgrade` avec le contexte technique (version, changelog, hash du wasm).
|
||||
2. Il ajoute les 5 etapes dans l'ordre.
|
||||
3. Il avance la decision : l'etape "Qualification" devient active. Le Comite Technique verifie le build.
|
||||
4. Une fois la qualification validee, il avance : l'etape "Examen" devient active. Les forgerons reviewent le code.
|
||||
5. Il avance : l'etape "Vote" devient active. Une session de vote est creee avec le protocole incluant les criteres Smith et TechComm.
|
||||
6. Les membres votent. Le seuil WoT s'applique avec inertie. Les criteres Smith (`ceil(SmithWotSize^S)`) et TechComm (`ceil(CoTecSize^T)`) doivent aussi etre atteints.
|
||||
7. Si adopte, il avance : l'etape "Execution" devient active. Le runtime est deploye.
|
||||
8. Il avance : l'etape "Reporting" devient active. Le compte-rendu est redige.
|
||||
9. Il avance une derniere fois : la decision passe en statut `closed`.
|
||||
|
||||
## Lien avec les documents
|
||||
|
||||
Quand une decision de type `document_change` est adoptee, la modification proposee est automatiquement appliquee a l'item du document concerne. L'ancienne version est conservee dans l'historique des versions (`item_versions`).
|
||||
|
||||
## Lien avec les mandats
|
||||
|
||||
Les decisions de type `mandate_vote` sont utilisees pour les elections de mandats. La decision contient une etape de vote qui determine le resultat de l'election. Voir la section [Mandats](/user/mandates) pour plus de details.
|
||||
@@ -0,0 +1,411 @@
|
||||
---
|
||||
title: Vote
|
||||
description: Guide du systeme de vote sur libreDecision
|
||||
---
|
||||
|
||||
# Vote
|
||||
|
||||
## Principe
|
||||
|
||||
Le systeme de vote de libreDecision est concu pour adapter le seuil d'adoption a la participation reelle. Quand peu de membres votent, une quasi-unanimite est exigee. Quand la participation est elevee, une majorite simple suffit. Ce mecanisme d'**inertie** protege contre les decisions prises par un petit groupe.
|
||||
|
||||
## Types de vote
|
||||
|
||||
### Vote binaire
|
||||
|
||||
Chaque votant choisit **Pour** ou **Contre**. Le seuil est calcule par la formule WoT.
|
||||
|
||||
### Vote nuance
|
||||
|
||||
Chaque votant exprime son opinion sur une echelle a 6 niveaux :
|
||||
|
||||
| Niveau | Label | Signification | Comptage |
|
||||
| ------ | ------------- | --------------------------------------------------- | -------- |
|
||||
| 0 | CONTRE | Opposition totale et ferme | Negatif |
|
||||
| 1 | PAS DU TOUT | Desaccord fort, points essentiels non remplis | Negatif |
|
||||
| 2 | PAS D'ACCORD | Desaccord modere, des reserves importantes | Negatif |
|
||||
| 3 | NEUTRE | Ni pour ni contre, ou acceptation sans enthousiasme | Positif |
|
||||
| 4 | D'ACCORD | Approbation avec eventuellement des reserves mineures | Positif |
|
||||
| 5 | TOUT A FAIT | Approbation totale et enthousiaste | Positif |
|
||||
|
||||
Le vote nuance est adopte si les niveaux positifs (3, 4, 5) representent au moins **80%** des votes et qu'un nombre minimum de participants est atteint (par defaut 59).
|
||||
|
||||
### Quand utiliser le vote nuance ?
|
||||
|
||||
Le vote nuance est recommande pour :
|
||||
|
||||
- Les textes longs comportant de nombreux articles (les votants peuvent exprimer un accord partiel).
|
||||
- Les decisions ou la nuance est importante (budget, parametre technique).
|
||||
- Les cas ou il est utile de mesurer le degre d'adhesion, pas seulement le resultat binaire.
|
||||
|
||||
## La formule de seuil expliquee simplement
|
||||
|
||||
### L'analogie de l'inertie
|
||||
|
||||
Imaginez un gros rocher pose au sommet d'une colline. Pour le deplacer, il faut une force considerable : c'est l'**inertie**. Dans libreDecision, le rocher represente le statu quo et la force necessaire represente le nombre de votes favorables.
|
||||
|
||||
- **Quand peu de personnes poussent** (faible participation) : il faut que presque tout le monde pousse dans la meme direction. Si seulement 10 personnes sur 7000 votent, il faut que 9 sur 10 soient pour.
|
||||
- **Quand beaucoup de personnes poussent** (forte participation) : la majorite simple suffit. Si 7000 personnes votent, il suffit que 3500 soient pour (50%).
|
||||
|
||||
Ce mecanisme empeche qu'un petit groupe prenne des decisions engageant toute la communaute, tout en permettant une gouvernance efficace quand la participation est large.
|
||||
|
||||
### La formule
|
||||
|
||||
La formule exacte est :
|
||||
|
||||
```
|
||||
Seuil = C + B^W + (M + (1-M) * (1 - (T/W)^G)) * max(0, T-C)
|
||||
```
|
||||
|
||||
Ou :
|
||||
|
||||
| Symbole | Signification | Exemple |
|
||||
| ------- | ------------- | ------- |
|
||||
| C | Base constante (plancher minimum) | 0 |
|
||||
| B | Exposant de base (negligeable pour grandes communautes) | 0.1 |
|
||||
| W | Taille de la Toile de Confiance (membres eligibles) | 7224 |
|
||||
| T | Nombre total de votes exprimes | 120 |
|
||||
| M | Ratio de majorite cible a pleine participation | 0.50 (50%) |
|
||||
| G | Gradient : vitesse de convergence vers la majorite | 0.2 |
|
||||
|
||||
### Exemple concret
|
||||
|
||||
Pour le vote de l'**Engagement Forgeron v2.0.0** :
|
||||
|
||||
- WoT = 7224 membres, 120 votes (1.7% de participation)
|
||||
- Parametres : M=50%, B=0.1, G=0.2, C=0
|
||||
- **Seuil calcule : 94 votes favorables requis** (soit 78% des votants)
|
||||
- Resultat : 97 pour, 23 contre -- **Adopte** (97 >= 94)
|
||||
|
||||
La faible participation a rendu le seuil exigeant : 78% au lieu de 50%. C'est l'inertie en action.
|
||||
|
||||
### Tableau d'inertie
|
||||
|
||||
Le tableau suivant montre comment l'exigence evolue avec la participation, pour les parametres de reference `M50 G.2` avec une WoT de 7224 :
|
||||
|
||||
| Participation | % de la WoT | % favorables requis |
|
||||
| ------------: | ----------: | ------------------: |
|
||||
| 10 | 0.1% | 87.4% |
|
||||
| 50 | 0.7% | 82.3% |
|
||||
| 100 | 1.4% | 80.1% |
|
||||
| 120 | 1.7% | 79.5% |
|
||||
| 200 | 2.8% | 77.7% |
|
||||
| 500 | 6.9% | 74.4% |
|
||||
| 1000 | 13.8% | 71.2% |
|
||||
| 2000 | 27.7% | 67.7% |
|
||||
| 5000 | 69.2% | 62.6% |
|
||||
| 7224 | 100% | 50.0% |
|
||||
|
||||
On constate que meme a 500 votants (6.9%), il faut encore 74.4% de votes favorables. L'inertie ne descend en dessous de 66% qu'au-dela de 2000 votants.
|
||||
|
||||
## Criteres additionnels
|
||||
|
||||
### Critere Smith (Forgerons)
|
||||
|
||||
Certaines decisions exigent un nombre minimum de votes favorables de la part des **forgerons** (membres Smith de la WoT). Ce critere garantit que les decisions qui affectent le reseau sont soutenues par ceux qui le maintiennent.
|
||||
|
||||
Le seuil Smith est calcule par : `ceil(SmithWotSize^S)` ou `S` est l'exposant Smith.
|
||||
|
||||
**Exemple** : Avec 20 forgerons et S=0.1, le seuil est `ceil(20^0.1) = ceil(1.35) = 2`. Il faut au minimum 2 votes favorables de forgerons.
|
||||
|
||||
### Critere TechComm (Comite Technique)
|
||||
|
||||
De maniere similaire, certaines decisions exigent un nombre minimum de votes favorables du **Comite Technique**. Cela concerne les decisions techniques (runtime upgrades, modifications d'infrastructure).
|
||||
|
||||
Le seuil TechComm est calcule par : `ceil(CoTecSize^T)` ou `T` est l'exposant TechComm.
|
||||
|
||||
**Exemple** : Avec 5 membres TechComm et T=0.1, le seuil est `ceil(5^0.1) = ceil(1.17) = 2`. Il faut au minimum 2 votes favorables du Comite Technique.
|
||||
|
||||
### Adoption finale
|
||||
|
||||
Un vote n'est adopte que si **les trois conditions** sont remplies simultanement :
|
||||
|
||||
1. Les votes favorables atteignent le seuil WoT (formule principale)
|
||||
2. Les votes favorables des forgerons atteignent le seuil Smith (si actif)
|
||||
3. Les votes favorables du Comite Technique atteignent le seuil TechComm (si actif)
|
||||
|
||||
## Mode params : decoder les parametres
|
||||
|
||||
Les parametres de formule sont encodes dans une chaine compacte pour faciliter la lecture. Voici comment decoder `"D30M50B.1G.2T.1"` :
|
||||
|
||||
| Code | Valeur | Signification |
|
||||
| ---- | ------ | ------------- |
|
||||
| D30 | 30 | Duree du vote : **30 jours** |
|
||||
| M50 | 50% | Majorite cible : **50%** (majorite simple a pleine participation) |
|
||||
| B.1 | 0.1 | Exposant de base : **0.1** (negligeable pour grandes WoT) |
|
||||
| G.2 | 0.2 | Gradient : **0.2** (convergence rapide vers la majorite) |
|
||||
| T.1 | 0.1 | Exposant TechComm : **0.1** (critere TechComm actif) |
|
||||
|
||||
Autres codes possibles :
|
||||
|
||||
| Code | Parametre | Exemple | Signification |
|
||||
| ---- | --------- | ------- | ------------- |
|
||||
| C | Base constante | C3 | Minimum 3 votes favorables quelle que soit la formule |
|
||||
| S | Exposant Smith | S.1 | Critere Smith actif avec exposant 0.1 |
|
||||
| N | Multiplicateur ratio | N1.5 | Multiplicateur 1.5 en mode ratio |
|
||||
| R | Mode ratio | R1 | Mode ratio active |
|
||||
|
||||
### Exemples de configurations
|
||||
|
||||
- `"D30M50B.1G.2"` : 30 jours, majorite 50%, configuration standard
|
||||
- `"D30M50B.1G.2S.1T.1"` : idem avec criteres Smith et TechComm
|
||||
- `"D60M66B.05G.3"` : 60 jours, super-majorite 66%, gradient plus strict
|
||||
- `"D14M50B.1G.1"` : 14 jours, gradient rapide (decisions urgentes)
|
||||
|
||||
## Comment voter : etapes concretes
|
||||
|
||||
### Vote binaire
|
||||
|
||||
1. **Acceder a la session de vote** : Rendez-vous dans la section **Votes** depuis le menu principal, ou accedez directement a la page d'une decision en cours. Les sessions ouvertes sont signalees par un badge vert "En cours".
|
||||
|
||||
2. **Consulter le sujet** : Lisez attentivement le document ou la decision soumise au vote. Le texte complet est affiche au-dessus du panneau de vote. Vous pouvez deployer chaque article pour consulter le detail.
|
||||
|
||||
3. **Choisir votre vote** : Le panneau de vote affiche deux boutons :
|
||||
- **Pour** (bouton vert) : Vous approuvez la proposition.
|
||||
- **Contre** (bouton rouge) : Vous rejetez la proposition.
|
||||
|
||||
4. **Ajouter un commentaire** (optionnel) : Un champ de texte sous les boutons vous permet d'expliquer votre choix. Le commentaire est public et visible par tous les membres.
|
||||
|
||||
5. **Signer votre vote** : Apres avoir clique sur votre choix, la plateforme genere un payload contenant votre vote, l'identifiant de la session et un horodatage. Votre extension de cle ou votre portefeuille Duniter vous demande de **signer ce payload** avec votre cle privee Ed25519.
|
||||
|
||||
6. **Confirmer la soumission** : Une fois la signature effectuee, cliquez sur **Soumettre**. Un message de confirmation apparait avec le resume de votre vote.
|
||||
|
||||
### Vote nuance
|
||||
|
||||
1. **Acceder a la session** : Meme procedure que pour le vote binaire. Les sessions de vote nuance sont identifiees par un badge "Nuance" en plus du badge de statut.
|
||||
|
||||
2. **Consulter le sujet** : Lisez le document ou la decision soumise au vote.
|
||||
|
||||
3. **Choisir votre niveau** : Le panneau de vote nuance affiche une echelle a 6 niveaux sous forme de curseur ou de boutons. Les niveaux 3, 4 et 5 sont comptes comme **positifs**. Les niveaux 0, 1 et 2 sont comptes comme **negatifs**.
|
||||
|
||||
4. **Ajouter un commentaire** (optionnel) : Particulierement utile pour les niveaux intermediaires (1, 2, 3, 4), afin d'expliquer vos reserves ou vos attentes.
|
||||
|
||||
5. **Signer et soumettre** : Meme procedure que pour le vote binaire.
|
||||
|
||||
### Modifier son vote
|
||||
|
||||
Tant que la session est ouverte, vous pouvez changer votre vote :
|
||||
|
||||
1. Retournez sur la page de la session de vote.
|
||||
2. Votre vote actuel est affiche avec un badge "Votre vote".
|
||||
3. Cliquez sur **Modifier mon vote**.
|
||||
4. Selectionnez votre nouveau choix et signez a nouveau.
|
||||
5. L'ancien vote est desactive (conserve dans l'historique pour audit) et remplace par le nouveau.
|
||||
|
||||
## Comprendre les resultats : la jauge de seuil
|
||||
|
||||
La page de chaque session de vote affiche une **jauge de seuil** qui represente visuellement l'etat du vote en temps reel.
|
||||
|
||||
### Elements de la jauge
|
||||
|
||||
```
|
||||
[|||||||||||||||||||||||||||-----] 97 / 94 Adopte
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^
|
||||
Votes Pour (vert) Seuil requis (trait vertical)
|
||||
```
|
||||
|
||||
| Element | Description |
|
||||
| --------------------------- | ------------------------------------------------------------ |
|
||||
| **Barre verte** | Nombre de votes favorables actuels |
|
||||
| **Barre rouge** | Nombre de votes defavorables actuels |
|
||||
| **Trait vertical** | Position du seuil requis (calcule par la formule d'inertie) |
|
||||
| **Compteur numerique** | `votes_pour / seuil` affiche a droite de la jauge |
|
||||
| **Badge de resultat** | "Adopte" (vert) ou "Non atteint" (gris) ou "Rejete" (rouge) |
|
||||
| **Pourcentage de participation** | `total_votes / wot_size` affiche sous la jauge |
|
||||
|
||||
### Comportement dynamique
|
||||
|
||||
La jauge se **met a jour en temps reel** : a chaque nouveau vote soumis, la barre et le seuil sont recalcules instantanement. Le seuil peut augmenter legerement a mesure que de nouveaux votes arrivent (car la participation $T$ change, ce qui modifie le facteur d'inertie). Le resultat affiche est donc toujours provisoire tant que la session est ouverte.
|
||||
|
||||
### Detail du calcul
|
||||
|
||||
En cliquant sur le bouton **Voir le detail** sous la jauge, une modale s'ouvre avec :
|
||||
- Les parametres de la formule utilises (`mode_params`).
|
||||
- Les valeurs intermediaires du calcul (ratio de participation, facteur d'inertie, etc.).
|
||||
- Les criteres Smith et TechComm si applicables.
|
||||
- Un lien vers le simulateur de formules pour experimenter d'autres scenarios.
|
||||
|
||||
### Page de resultat
|
||||
|
||||
La page de resultat affiche :
|
||||
|
||||
| Information | Description |
|
||||
| ------------------- | ---------------------------------------------------- |
|
||||
| Votes pour | Nombre de votes favorables |
|
||||
| Votes contre | Nombre de votes defavorables |
|
||||
| Total | Nombre total de votes exprimes |
|
||||
| Taille WoT | Nombre de membres WoT eligibles (snapshot au debut) |
|
||||
| Seuil requis | Seuil calcule par la formule d'inertie |
|
||||
| Critere Smith | Seuil et validation des votes Smith (si applicable) |
|
||||
| Critere TechComm | Seuil et validation des votes TechComm (si applicable) |
|
||||
| Resultat | **Adopte** ou **Rejete** |
|
||||
|
||||
## Simulateur de formules
|
||||
|
||||
Le simulateur de formules vous permet de tester le comportement du seuil d'adoption avec differentes configurations, sans creer de session de vote.
|
||||
|
||||
### Acceder au simulateur
|
||||
|
||||
1. Depuis le menu principal, selectionnez **Outils** puis **Simulateur de formules**.
|
||||
2. Vous pouvez aussi y acceder depuis le detail du calcul de seuil d'une session de vote (bouton **Ouvrir le simulateur**).
|
||||
|
||||
### Utiliser le simulateur
|
||||
|
||||
Le simulateur presente un formulaire avec les parametres ajustables :
|
||||
|
||||
| Parametre | Description | Curseur/Champ |
|
||||
| ----------------------- | ---------------------------------------------- | ------------- |
|
||||
| Taille WoT ($W$) | Nombre de membres eligibles | Curseur |
|
||||
| Total votes ($T$) | Nombre de votes exprimes | Curseur |
|
||||
| Majorite ($M$) | Pourcentage de majorite cible | Curseur |
|
||||
| Base ($B$) | Exposant de base | Champ |
|
||||
| Gradient ($G$) | Vitesse de convergence | Curseur |
|
||||
| Base constante ($C$) | Plancher minimum de votes | Champ |
|
||||
| Votes Pour | Nombre de votes favorables (pour tester l'adoption) | Curseur |
|
||||
|
||||
En ajustant les curseurs, le resultat se met a jour en temps reel :
|
||||
- Le **seuil calcule** est affiche.
|
||||
- Un graphique montre la courbe du seuil en fonction de la participation.
|
||||
- Le resultat **Adopte** / **Rejete** s'affiche en fonction des votes pour saisis.
|
||||
|
||||
### Exemple de scenario
|
||||
|
||||
Vous souhaitez comparer deux configurations pour un vote attendu avec environ 200 participants sur une WoT de 7224 :
|
||||
|
||||
1. Configuration actuelle `M50 G.2` : Seuil = 156 (77.7% requis).
|
||||
2. Configuration proposee `M50 G.4` : Seuil = 171 (85.5% requis).
|
||||
|
||||
Le simulateur montre visuellement l'impact : avec un gradient plus eleve, l'exigence est sensiblement plus forte a faible participation.
|
||||
|
||||
## Mises a jour en temps reel
|
||||
|
||||
libreDecision utilise une connexion **WebSocket** pour diffuser les mises a jour de vote en temps reel a tous les utilisateurs qui consultent une session de vote.
|
||||
|
||||
### Ce qui est mis a jour en direct
|
||||
|
||||
| Evenement | Effet sur l'interface |
|
||||
| ---------------------------- | ---------------------------------------------------- |
|
||||
| Nouveau vote soumis | La jauge de seuil est recalculee et reaffichee |
|
||||
| Vote modifie | La jauge reflette le changement immediatement |
|
||||
| Session cloturee | Le badge passe a "Cloture" et le resultat final s'affiche |
|
||||
| Critere Smith/TechComm atteint | L'indicateur de critere passe au vert |
|
||||
|
||||
### Indicateur de connexion
|
||||
|
||||
Un petit indicateur en bas a droite de la page de vote affiche l'etat de la connexion temps reel :
|
||||
- **Point vert** : Connexion active, mises a jour en direct.
|
||||
- **Point orange** : Reconnexion en cours.
|
||||
- **Point rouge** : Connexion perdue. Les donnees affichees peuvent etre obsoletes. Rechargez la page.
|
||||
|
||||
## Historique des votes
|
||||
|
||||
### Consulter ses propres votes
|
||||
|
||||
1. Cliquez sur votre avatar ou votre adresse Duniter dans la barre de navigation.
|
||||
2. Selectionnez **Mon historique de votes**.
|
||||
3. La liste affiche tous vos votes passes, avec pour chacun :
|
||||
- Le titre de la session / decision.
|
||||
- Votre choix (Pour/Contre ou niveau nuance).
|
||||
- La date et l'heure du vote.
|
||||
- Le resultat final de la session (Adopte/Rejete) si cloturee.
|
||||
|
||||
### Consulter les votes d'une session
|
||||
|
||||
Sur la page d'une session de vote, l'onglet **Votes** affiche la liste de tous les votes soumis :
|
||||
- L'adresse Duniter du votant.
|
||||
- Le choix exprime.
|
||||
- Le commentaire (s'il y en a un).
|
||||
- L'horodatage.
|
||||
- Un lien pour verifier la signature Ed25519.
|
||||
|
||||
Les votes sont publics et verifiables par tous. Il n'y a pas de vote secret dans libreDecision : la transparence est un principe fondamental.
|
||||
|
||||
## Meta-gouvernance : voter sur les regles du vote
|
||||
|
||||
La meta-gouvernance est la capacite de **modifier les regles du systeme de vote en utilisant le systeme de vote lui-meme**. C'est le mecanisme par lequel la communaute garde le controle sur les parametres fondamentaux de la prise de decision.
|
||||
|
||||
### Qu'est-ce qui peut etre modifie par meta-gouvernance ?
|
||||
|
||||
| Element modifiable | Exemple de modification |
|
||||
| ------------------------------- | ---------------------------------------------------------- |
|
||||
| Duree de vote | Passer de 30 jours a 60 jours |
|
||||
| Majorite cible ($M$) | Passer de 50% a 66% (super-majorite) |
|
||||
| Gradient ($G$) | Augmenter de 0.2 a 0.4 (plus exigeant a faible participation) |
|
||||
| Critere Smith | Activer ou desactiver, changer l'exposant |
|
||||
| Critere TechComm | Activer ou desactiver, changer l'exposant |
|
||||
| Type de vote | Passer d'un vote binaire a un vote nuance |
|
||||
|
||||
### Comment ca fonctionne ?
|
||||
|
||||
1. **Proposition** : Un membre propose une modification d'un protocole ou d'une formule via l'interface (bouton **Proposer une modification** sur la page du protocole).
|
||||
|
||||
2. **Verification** : Le systeme detecte que le protocole ou la formule est **actif** (lie a au moins une session de vote ouverte).
|
||||
|
||||
3. **Creation automatique d'un vote** : Une session de vote est automatiquement creee pour valider ou rejeter la modification. Cette session utilise les **regles actuelles** (pas les regles proposees).
|
||||
|
||||
4. **Vote de la communaute** : Les membres votent sur la proposition de modification selon les regles en vigueur.
|
||||
|
||||
5. **Application conditionnelle** :
|
||||
- Si le vote est **adopte** : les nouvelles regles s'appliquent aux futures sessions de vote. Les sessions en cours ne sont pas affectees.
|
||||
- Si le vote est **rejete** : le protocole reste inchange.
|
||||
|
||||
### Exemple concret
|
||||
|
||||
Un membre estime que le gradient $G = 0.2$ est trop permissif et propose de passer a $G = 0.4$ :
|
||||
|
||||
1. Il se rend sur la page du protocole actif et clique sur **Proposer une modification**.
|
||||
2. Il modifie la valeur du gradient de 0.2 a 0.4 dans le formulaire.
|
||||
3. Il soumet la proposition. Le systeme cree une session de vote intitulee "Modification du gradient de seuil : G.2 vers G.4".
|
||||
4. Les membres votent pendant 30 jours (duree du protocole actuel).
|
||||
5. Avec 97 votes pour et 23 contre sur une WoT de 7224, le seuil calcule est de 94. Le vote est adopte (97 >= 94).
|
||||
6. Le gradient passe a 0.4 pour toutes les futures sessions de vote.
|
||||
|
||||
### Pourquoi la meta-gouvernance est importante
|
||||
|
||||
- **Aucun parametre n'est grave dans le marbre** : la communaute peut toujours adapter les regles.
|
||||
- **Protection contre les modifications unilaterales** : personne ne peut changer les regles seul.
|
||||
- **Transparence** : toute modification de regle est tracable et soumise au vote.
|
||||
- **Coherence** : les regles de modification sont les memes que les regles de decision (le systeme s'applique a lui-meme).
|
||||
|
||||
## Preuve cryptographique
|
||||
|
||||
Chaque vote est accompagne d'une signature Ed25519 qui garantit :
|
||||
|
||||
- **Authenticite** : seul le proprietaire de l'adresse Duniter peut voter en son nom
|
||||
- **Integrite** : le vote ne peut pas etre modifie apres soumission
|
||||
- **Non-repudiation** : le votant ne peut pas nier avoir vote
|
||||
|
||||
Les votes signes peuvent etre verifies independamment par quiconque possede la cle publique du votant.
|
||||
|
||||
## Protocoles de vote
|
||||
|
||||
Chaque session de vote est liee a un **protocole de vote** qui definit :
|
||||
|
||||
- Le type de vote (binaire ou nuance)
|
||||
- La duree du vote (en jours)
|
||||
- Les parametres de la formule de seuil (majorite, exposants, etc.)
|
||||
- Les criteres Smith et TechComm eventuels
|
||||
|
||||
Les protocoles sont reutilisables et peuvent eux-memes etre soumis a meta-gouvernance.
|
||||
|
||||
## FAQ Vote
|
||||
|
||||
### Le seuil peut-il changer pendant le vote ?
|
||||
|
||||
Oui. Le seuil depend du nombre total de votes exprimes ($T$). A chaque nouveau vote, le seuil est recalcule. Il augmente legerement a mesure que la participation croit, mais converge vers la majorite simple. C'est pourquoi le resultat affiche est toujours provisoire tant que la session est ouverte.
|
||||
|
||||
### Que se passe-t-il si le seuil n'est pas atteint a la cloture ?
|
||||
|
||||
Le vote est **rejete**. La proposition n'est pas adoptee et le statu quo est maintenu. Le resultat detaille est archive dans le Sanctuaire pour transparence.
|
||||
|
||||
### Un vote en cours peut-il etre annule ?
|
||||
|
||||
Seul le createur de la session ou un membre du Comite Technique peut cloturer une session de maniere anticipee. La cloture anticipee calcule le resultat avec les votes exprimes a ce moment.
|
||||
|
||||
### Comment sont geres les ex aequo ?
|
||||
|
||||
Il n'y a pas d'ex aequo possible avec la formule d'inertie. Le seuil est un nombre entier (arrondi inferieur) et le nombre de votes favorables est un entier. Si `votes_pour >= seuil`, le vote est adopte. Sinon, il est rejete.
|
||||
|
||||
### Puis-je voter si mon statut WoT change pendant le vote ?
|
||||
|
||||
Votre statut WoT est enregistre au moment de votre vote. Si vous perdez votre statut de membre apres avoir vote, votre vote reste comptabilise car le snapshot de la taille WoT est pris au debut de la session.
|
||||
@@ -0,0 +1,172 @@
|
||||
---
|
||||
title: Mandats
|
||||
description: Guide des mandats sur libreDecision
|
||||
---
|
||||
|
||||
# Mandats
|
||||
|
||||
## Principe
|
||||
|
||||
Un mandat est une responsabilite attribuee a un membre de la communaute pour une duree determinee, apres validation par vote collectif. Les mandats permettent de formaliser les roles au sein de la gouvernance Duniter et d'assurer la redevabilite des mandataires.
|
||||
|
||||
## Types de mandats
|
||||
|
||||
| Type | Description | Cas d'usage |
|
||||
| ---------- | ------------------------------------------------------- | --------------------------------------------------------- |
|
||||
| `techcomm` | Mandat de membre du Comite Technique | Administration du reseau, validation des runtime upgrades |
|
||||
| `smith` | Mandat lie au role de forgeron (Smith) | Production de blocs, maintenance de la blockchain |
|
||||
| `custom` | Mandat personnalise pour tout autre role | Tresorier, secretaire, moderateur, etc. |
|
||||
|
||||
Chaque type de mandat peut avoir des criteres de vote specifiques. Par exemple, un mandat `techcomm` peut exiger un critere TechComm (`ceil(CoTecSize^T)`), tandis qu'un mandat `smith` peut exiger un critere Smith (`ceil(SmithWotSize^S)`).
|
||||
|
||||
## Cycle de vie d'un mandat
|
||||
|
||||
Un mandat progresse a travers les statuts suivants :
|
||||
|
||||
```
|
||||
Brouillon --> Candidature --> Vote --> Actif --> Rapport --> Termine
|
||||
| |
|
||||
+--> Rejet (si le +--> Revoque (revocation
|
||||
vote echoue) anticipee)
|
||||
```
|
||||
|
||||
| Statut | Description |
|
||||
| ------------ | ------------------------------------------------------------ |
|
||||
| `draft` | Brouillon initial. Le mandat est en cours de definition et peut etre modifie ou supprime. |
|
||||
| `candidacy` | Periode de depot des candidatures. Les membres interesses se declarent candidats. |
|
||||
| `voting` | Vote collectif pour designer le mandataire. Une session de vote est ouverte. |
|
||||
| `active` | Le mandat est en cours. Le mandataire exerce ses responsabilites. |
|
||||
| `reporting` | Periode de reporting. Le mandataire rend compte de ses actions. |
|
||||
| `completed` | Fin normale du mandat a echeance. Le bilan est archive. |
|
||||
| `revoked` | Fin anticipee du mandat suite a une revocation. |
|
||||
|
||||
## Etapes d'un mandat (mandate_steps)
|
||||
|
||||
Chaque mandat est compose d'etapes ordonnees qui definissent le processus complet. Les types d'etapes disponibles sont :
|
||||
|
||||
| Type d'etape | Description |
|
||||
| -------------- | ------------------------------------------------------------ |
|
||||
| `formulation` | Definition du mandat, de ses objectifs et de sa duree |
|
||||
| `candidacy` | Periode de depot et d'examen des candidatures |
|
||||
| `vote` | Vote collectif pour designer le mandataire |
|
||||
| `assignment` | Attribution formelle du mandat au candidat elu |
|
||||
| `reporting` | Periode de reporting sur l'execution du mandat |
|
||||
| `completion` | Fin normale du mandat a echeance |
|
||||
| `revocation` | Fin anticipee du mandat (en cas de manquement) |
|
||||
|
||||
Chaque etape possede un statut individuel :
|
||||
|
||||
| Statut | Description |
|
||||
| ----------- | ---------------------------------------------------------- |
|
||||
| `pending` | L'etape n'a pas encore commence |
|
||||
| `active` | L'etape est en cours |
|
||||
| `completed` | L'etape est terminee avec succes |
|
||||
| `skipped` | L'etape a ete ignoree (non applicable) |
|
||||
|
||||
## Comment le workflow avance
|
||||
|
||||
Le workflow d'un mandat avance via l'action **"Avancer"** (endpoint `POST /mandates/{id}/advance`). Le fonctionnement est identique a celui des decisions :
|
||||
|
||||
1. **S'il y a une etape active** : elle est marquee `completed`, et la prochaine etape `pending` est activee.
|
||||
2. **S'il n'y a pas d'etape active** : la premiere etape `pending` est activee. Si le mandat est en `draft`, il passe automatiquement en `candidacy`.
|
||||
3. **Si toutes les etapes sont terminees** : le statut global du mandat avance au statut suivant dans le cycle de vie.
|
||||
|
||||
Les statuts terminaux (`completed` et `revoked`) bloquent tout avancement ulterieur.
|
||||
|
||||
## Creer un mandat
|
||||
|
||||
Les membres authentifies peuvent proposer un nouveau mandat :
|
||||
|
||||
1. Cliquez sur **Nouveau mandat**.
|
||||
2. Renseignez le **titre** : intitule du role ou de la mission.
|
||||
3. Renseignez la **description** : objectifs, responsabilites, criteres de reussite.
|
||||
4. Choisissez le **type de mandat** : `techcomm`, `smith` ou `custom`.
|
||||
5. Optionnellement, liez le mandat a une **decision** existante de type `mandate_vote`.
|
||||
6. **Ajoutez les etapes** dans l'ordre souhaite (formulation, candidature, vote, assignation, reporting, completion).
|
||||
7. Soumettez. Le mandat est cree en statut `draft`.
|
||||
8. Utilisez l'action **"Avancer"** pour demarrer le processus.
|
||||
|
||||
## Candidatures
|
||||
|
||||
Pendant la phase de candidature (`candidacy`), les membres de la communaute peuvent se declarer candidats. La page du mandat affiche la liste des candidats avec leur profil Duniter (adresse SS58, statut WoT, statut Smith/TechComm).
|
||||
|
||||
## Vote pour un mandat
|
||||
|
||||
Quand l'etape de type `vote` est active, une session de vote doit etre creee via l'action **"Creer une session de vote"** (endpoint `POST /mandates/{id}/steps/{step_id}/create-vote-session`).
|
||||
|
||||
La session de vote fonctionne exactement comme pour les decisions :
|
||||
- Snapshot des tailles WoT, Smith, TechComm
|
||||
- Application de la formule de seuil avec inertie
|
||||
- Criteres supplementaires Smith/TechComm selon le protocole choisi
|
||||
- Cloture automatique ou manuelle
|
||||
|
||||
Le resultat du vote determine si le mandat est attribue au candidat elu.
|
||||
|
||||
## Assignation du mandataire
|
||||
|
||||
Apres un vote reussi, le mandataire est assigne au mandat via l'action **"Assigner"** (endpoint `POST /mandates/{id}/assign`). Cette action :
|
||||
|
||||
- Definit le `mandatee_id` : l'identite Duniter du membre elu
|
||||
- Definit les dates de debut et de fin du mandat
|
||||
- Fait passer le mandat en statut `active`
|
||||
|
||||
Le corps de la requete contient l'identifiant de l'identite Duniter du mandataire :
|
||||
|
||||
```json
|
||||
{
|
||||
"mandatee_id": "uuid-de-l-identite-duniter"
|
||||
}
|
||||
```
|
||||
|
||||
## Reporting et redevabilite
|
||||
|
||||
Pendant la phase active du mandat, le mandataire est tenu de rendre compte de ses actions. Quand l'etape de `reporting` est active :
|
||||
|
||||
- Le mandataire peut publier des comptes-rendus via le champ `outcome` de l'etape
|
||||
- Les membres de la communaute peuvent consulter les rapports
|
||||
- Le bilan est archive dans le sanctuaire a la fin du mandat
|
||||
|
||||
## Revocation
|
||||
|
||||
Un mandat actif peut etre revoque de maniere anticipee via l'action **"Revoquer"** (endpoint `POST /mandates/{id}/revoke`). La revocation :
|
||||
|
||||
- Passe le statut du mandat a `revoked`
|
||||
- Met fin immediatement aux responsabilites du mandataire
|
||||
- Archive le motif de revocation
|
||||
|
||||
La revocation est une action de gouvernance qui peut necessiter un vote prealable (decision de type `mandate_vote` avec motif de revocation).
|
||||
|
||||
## Suppression
|
||||
|
||||
Seuls les mandats au statut `draft` peuvent etre supprimes via l'action **"Supprimer"** (endpoint `DELETE /mandates/{id}`). Une fois le processus de candidature lance, le mandat reste dans le systeme pour tracabilite.
|
||||
|
||||
## Consulter les mandats
|
||||
|
||||
1. Rendez-vous dans la section **Mandats**.
|
||||
2. Filtrez par type (`techcomm`, `smith`, `custom`) ou par statut.
|
||||
3. Chaque mandat affiche le titulaire, les dates, les etapes et leur statut.
|
||||
4. La page de detail montre le workflow complet avec l'historique des etapes.
|
||||
|
||||
## Exemple : Election d'un membre du Comite Technique
|
||||
|
||||
```
|
||||
1. Formulation -> Definition du poste : responsabilites, duree (1 an), competences requises
|
||||
2. Candidature -> Les membres Smith se declarent candidats pendant 14 jours
|
||||
3. Vote -> Vote WoT avec critere TechComm obligatoire, duree 30 jours
|
||||
4. Assignation -> Attribution du mandat au candidat elu
|
||||
5. Reporting -> Rapport d'activite trimestriel
|
||||
6. Completion -> Fin du mandat apres 1 an, bilan final archive
|
||||
```
|
||||
|
||||
**Deroulement concret :**
|
||||
|
||||
1. Un membre cree un mandat de type `techcomm` avec la description du poste.
|
||||
2. Il ajoute les 6 etapes dans l'ordre.
|
||||
3. Il avance le mandat : l'etape "Formulation" est activee, puis completee.
|
||||
4. Il avance : la phase de candidature s'ouvre. Les candidats se declarent.
|
||||
5. Il avance : l'etape "Vote" est activee. Une session de vote est creee.
|
||||
6. Les membres votent. Le seuil WoT et le critere TechComm doivent etre atteints.
|
||||
7. Si adopte, il avance : l'etape "Assignation" est activee. Le mandataire est designe via l'action "Assigner".
|
||||
8. Il avance : le mandat passe en phase active. Le mandataire exerce ses fonctions.
|
||||
9. A l'echeance, l'etape "Reporting" est activee pour le bilan.
|
||||
10. Il avance une derniere fois : le mandat passe en statut `completed`.
|
||||
@@ -0,0 +1,204 @@
|
||||
---
|
||||
title: Sanctuaire
|
||||
description: Guide de l'archivage immuable sur libreDecision
|
||||
---
|
||||
|
||||
# Sanctuaire
|
||||
|
||||
## Qu'est-ce que le Sanctuaire ?
|
||||
|
||||
Le Sanctuaire est la couche d'**archivage immuable** de libreDecision. C'est l'endroit ou les decisions adoptees, les documents archives et les resultats de vote sont preserves de maniere permanente et verifiable.
|
||||
|
||||
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 libreDecision 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 libreDecision.
|
||||
|
||||
Le format du remark est :
|
||||
|
||||
```
|
||||
libredecision: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** : 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 libreDecision, les preuves restent sur IPFS et la blockchain.
|
||||
|
||||
## 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.
|
||||
|
||||
## Comment verifier une archive
|
||||
|
||||
### Verification automatique
|
||||
|
||||
libreDecision 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 (independante de la plateforme)
|
||||
|
||||
Pour une verification totalement independante de libreDecision, suivez ces etapes :
|
||||
|
||||
#### Etape 1 : Recuperer le contenu via IPFS
|
||||
|
||||
Utilisez le CID affiche sur l'entree du Sanctuaire pour telecharger le contenu :
|
||||
|
||||
```bash
|
||||
# Via un noeud IPFS local
|
||||
ipfs cat QmXyz... > document.txt
|
||||
|
||||
# Via une passerelle publique
|
||||
curl https://ipfs.io/ipfs/QmXyz... > document.txt
|
||||
```
|
||||
|
||||
#### Etape 2 : Calculer le hash SHA-256
|
||||
|
||||
```bash
|
||||
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 libreDecision 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 :
|
||||
|
||||
| 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 |
|
||||
|
||||
## 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.
|
||||
|
||||
## 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
|
||||
```
|
||||
@@ -0,0 +1,258 @@
|
||||
---
|
||||
title: FAQ
|
||||
description: Questions frequentes sur libreDecision
|
||||
---
|
||||
|
||||
# Questions frequentes
|
||||
|
||||
## Acces et authentification
|
||||
|
||||
### Ai-je besoin d'un compte Duniter pour utiliser libreDecision ?
|
||||
|
||||
Pour **consulter** les documents, decisions et resultats de vote, aucune authentification n'est necessaire. Pour **voter**, **proposer des modifications** ou **creer des decisions**, vous devez posseder une identite Duniter V2 avec une adresse SS58.
|
||||
|
||||
### Comment fonctionne la connexion sans mot de passe ?
|
||||
|
||||
libreDecision utilise un systeme challenge-response base sur la cryptographie Ed25519. Voici le processus :
|
||||
|
||||
1. Vous fournissez votre adresse Duniter SS58.
|
||||
2. Le serveur genere un texte aleatoire (le "challenge") de 64 caracteres hexadecimaux.
|
||||
3. Votre extension Polkadot.js ou votre portefeuille Cesium signe ce challenge avec votre cle privee Ed25519.
|
||||
4. Le serveur verifie la signature avec votre cle publique.
|
||||
5. Si la verification reussit, un jeton de session vous est attribue.
|
||||
|
||||
Votre cle privee n'est **jamais** transmise au serveur. Seule la signature du challenge est envoyee.
|
||||
|
||||
### Quels portefeuilles sont compatibles ?
|
||||
|
||||
Tout portefeuille supportant la signature Ed25519 sur Substrate est compatible :
|
||||
|
||||
- **Extension Polkadot.js** (recommandee) : disponible sur Chrome et Firefox
|
||||
- **Cesium2** : l'application officielle de la communaute Duniter
|
||||
- **Tout portefeuille Substrate** supportant Ed25519
|
||||
|
||||
### Ma session a expire, que faire ?
|
||||
|
||||
Les sessions durent 24 heures. Reconnectez-vous en suivant le meme processus (challenge + signature). Vos votes et propositions precedents ne sont pas affectes.
|
||||
|
||||
### Que se passe-t-il si je perds l'acces a ma cle privee ?
|
||||
|
||||
libreDecision ne stocke jamais votre cle privee. Si vous perdez l'acces a votre cle, vous ne pourrez plus vous authentifier avec cette adresse. Vos votes passes restent enregistres et comptabilises. Contactez la communaute Duniter pour les procedures de recuperation d'identite si necessaire.
|
||||
|
||||
### Puis-je me connecter depuis plusieurs appareils ?
|
||||
|
||||
Oui. Chaque connexion genere un jeton de session independant. Vous pouvez etre connecte simultanement depuis plusieurs appareils. Chaque session est independante et expire apres 24 heures.
|
||||
|
||||
## Vote
|
||||
|
||||
### Comment voter sur un item de document ?
|
||||
|
||||
1. Rendez-vous dans la section **Votes** ou accedez a une decision en cours.
|
||||
2. Lisez le sujet soumis au vote.
|
||||
3. Choisissez **Pour** ou **Contre** (vote binaire) ou un niveau de 0 a 5 (vote nuance).
|
||||
4. Optionnellement, ajoutez un commentaire.
|
||||
5. Signez le payload avec votre cle privee (votre extension de portefeuille vous le demandera).
|
||||
6. Cliquez sur **Soumettre**.
|
||||
|
||||
### Puis-je changer mon vote ?
|
||||
|
||||
Oui, tant que la session de vote est ouverte, vous pouvez modifier votre vote autant de fois que necessaire. L'ancien vote est conserve en base de donnees pour l'audit mais marque comme inactif. Seul le dernier vote est pris en compte dans le decompte.
|
||||
|
||||
### Pourquoi le seuil est-il si eleve quand peu de personnes votent ?
|
||||
|
||||
C'est le mecanisme d'**inertie**. Quand la participation est faible, le seuil est eleve pour empecher qu'un petit groupe prenne des decisions engageant toute la communaute. A mesure que la participation augmente, le seuil converge vers la majorite simple. Cela incite a la participation large.
|
||||
|
||||
Par exemple, avec 120 votes sur une WoT de 7224 membres (1.7% de participation), il faut 78% de votes favorables. Si toute la WoT votait, 50% suffiraient.
|
||||
|
||||
### Comment comprendre le seuil affiche sur la jauge ?
|
||||
|
||||
La jauge de seuil montre :
|
||||
|
||||
- **La barre verte** : nombre de votes favorables actuels
|
||||
- **La barre rouge** : nombre de votes defavorables
|
||||
- **Le trait vertical** : position du seuil requis (calcule par la formule d'inertie)
|
||||
- **Le compteur** : `votes_pour / seuil` (par exemple "97 / 94")
|
||||
- **Le badge** : "Adopte" si votes_pour >= seuil, sinon "Non atteint"
|
||||
|
||||
Le seuil est recalcule en temps reel a chaque nouveau vote.
|
||||
|
||||
### Qu'est-ce que le critere Smith ?
|
||||
|
||||
Certaines decisions exigent un nombre minimum de votes favorables de la part des **forgerons** (membres Smith de la WoT). Le seuil est calcule par `ceil(SmithWotSize^S)` ou S est l'exposant configure. Cela garantit que les decisions techniques sont soutenues par ceux qui maintiennent le reseau.
|
||||
|
||||
### Qu'est-ce que le critere TechComm ?
|
||||
|
||||
De maniere similaire, certaines decisions exigent un nombre minimum de votes favorables du **Comite Technique**. Le seuil est calcule par `ceil(CoTecSize^T)`. Cela concerne les decisions qui affectent le runtime ou l'infrastructure technique.
|
||||
|
||||
### Comment fonctionnent les votes nuances ?
|
||||
|
||||
Au lieu de "pour" ou "contre", vous choisissez un niveau de 0 (CONTRE) a 5 (TOUT A FAIT). Les niveaux 3, 4 et 5 comptent comme positifs. Pour que le vote soit adopte, il faut que les votes positifs representent au moins 80% du total et qu'un nombre minimum de participants soit atteint (par defaut 59).
|
||||
|
||||
### Que signifie "D30M50B.1G.2S.1T.1" ?
|
||||
|
||||
C'est le codage compact des parametres de formule :
|
||||
|
||||
- **D30** : duree de 30 jours
|
||||
- **M50** : majorite cible de 50%
|
||||
- **B.1** : exposant de base 0.1
|
||||
- **G.2** : gradient 0.2
|
||||
- **S.1** : critere Smith avec exposant 0.1
|
||||
- **T.1** : critere TechComm avec exposant 0.1
|
||||
|
||||
### Les votes sont-ils secrets ?
|
||||
|
||||
Non. Les votes et leurs signatures cryptographiques sont **publics**, conformement au principe de transparence de la gouvernance. Chaque vote peut etre verifie independamment par quiconque possede la cle publique du votant. Il n'y a pas de vote secret dans libreDecision.
|
||||
|
||||
### Le seuil peut-il changer pendant le vote ?
|
||||
|
||||
Oui. Le seuil depend du nombre total de votes exprimes. A chaque nouveau vote, le seuil est recalcule. Il augmente legerement a mesure que la participation croit, mais converge vers la majorite simple. C'est pourquoi le resultat affiche est toujours provisoire tant que la session est ouverte.
|
||||
|
||||
## Documents
|
||||
|
||||
### Qu'est-ce qu'un document de reference ?
|
||||
|
||||
Un document de reference est un texte fondateur de la communaute Duniter (Licence G1, Engagement Forgeron, Reglement du Comite Technique, etc.). Il est compose d'items modulaires sous vote permanent.
|
||||
|
||||
### Qu'est-ce qu'un item ?
|
||||
|
||||
Un item est une unite modulaire d'un document : une clause, une regle, une verification, un preambule ou une section. Chaque item a une position hierarchique (ex: "1", "1.1", "3.2"), un texte courant et un historique de versions.
|
||||
|
||||
### Comment proposer une modification ?
|
||||
|
||||
1. Ouvrez le document dans la section **Documents**.
|
||||
2. Selectionnez l'item a modifier.
|
||||
3. Cliquez sur **Proposer une modification**.
|
||||
4. Redigez le nouveau texte avec une justification.
|
||||
5. Soumettez.
|
||||
|
||||
Un diff automatique est genere. La proposition sera soumise a examen et vote par la communaute.
|
||||
|
||||
### Que signifie "vote permanent" ?
|
||||
|
||||
Les documents actifs sont toujours ouverts aux propositions de modification. Il n'y a pas de periode speciale pour proposer des changements. Cela permet une evolution continue et organique des textes.
|
||||
|
||||
### Puis-je proposer plusieurs modifications a la fois ?
|
||||
|
||||
Oui. Vous pouvez proposer des modifications a differents items d'un meme document, ou a des items de documents differents. Chaque proposition est independante et suit son propre cycle de vie (proposition, examen, vote).
|
||||
|
||||
### Que se passe-t-il si ma proposition est rejetee ?
|
||||
|
||||
Le texte courant de l'item reste inchange. Votre proposition est archivee avec le statut "rejetee" pour transparence. Vous pouvez proposer une nouvelle modification a tout moment, eventuellement amelioree suite aux retours de la communaute.
|
||||
|
||||
### Comment consulter le diff d'une proposition ?
|
||||
|
||||
Sur la page de detail d'une version proposee, le diff est affiche automatiquement. Les ajouts sont surlignees en vert, les suppressions en rouge. Vous pouvez basculer entre la vue diff et la vue texte complet.
|
||||
|
||||
## Decisions et mandats
|
||||
|
||||
### Quelle est la difference entre un document et une decision ?
|
||||
|
||||
Un **document** est un texte fondateur sous vote permanent (Licence, Engagement, Reglement). Une **decision** est un processus ponctuel multi-etapes (qualification, examen, vote, execution, rapport) pour prendre un choix collectif specifique (runtime upgrade, attribution de mandat, changement de parametre).
|
||||
|
||||
### Comment creer une decision ?
|
||||
|
||||
1. Rendez-vous dans la section **Decisions**.
|
||||
2. Cliquez sur **Nouvelle decision**.
|
||||
3. Renseignez le titre, la description, le contexte et le type.
|
||||
4. Choisissez un protocole de vote.
|
||||
5. Ajoutez les etapes necessaires (qualification, examen, vote, execution, reporting).
|
||||
6. Soumettez, puis utilisez **Avancer** pour demarrer le processus.
|
||||
|
||||
### Qu'est-ce qu'un mandat ?
|
||||
|
||||
Un mandat est une responsabilite formelle attribuee a un membre de la communaute pour une duree determinee, apres validation par vote collectif. Les types de mandats sont : `techcomm` (Comite Technique), `smith` (forgeron) et `custom` (personnalise).
|
||||
|
||||
### Comment fonctionne l'election d'un mandataire ?
|
||||
|
||||
Le processus suit un cycle : formulation du mandat, periode de candidature, vote collectif, assignation du mandataire, exercice du mandat, reporting et completion. Le vote utilise le meme systeme de seuil WoT avec inertie.
|
||||
|
||||
### Un mandat peut-il etre revoque ?
|
||||
|
||||
Oui. Un mandat actif peut etre revoque de maniere anticipee via l'action "Revoquer". La revocation est une action de gouvernance qui peut necessiter un vote prealable.
|
||||
|
||||
## Sanctuaire et archivage
|
||||
|
||||
### Pourquoi archiver sur IPFS et la blockchain ?
|
||||
|
||||
**IPFS** fournit un stockage distribue : le contenu est accessible meme si la plateforme libreDecision est hors ligne. L'**ancrage on-chain** via `system.remark` cree une preuve horodatee immuable sur la blockchain Duniter V2. Le **hash SHA-256** garantit l'integrite du contenu. Ensemble, ils forment une **triple preuve** que le contenu n'a pas ete modifie depuis son archivage.
|
||||
|
||||
### Comment verifier qu'un document n'a pas ete modifie ?
|
||||
|
||||
Trois methodes :
|
||||
|
||||
1. **Verification automatique** : cliquez sur **Verifier l'integrite** sur l'entree du Sanctuaire. Le systeme recalcule le hash et verifie IPFS et on-chain automatiquement.
|
||||
2. **Verification manuelle** : telechargez le contenu depuis IPFS via son CID, calculez le hash SHA-256 avec `sha256sum`, puis comparez avec le hash enregistre dans le Sanctuaire et le remark on-chain.
|
||||
3. **Verification blockchain** : consultez le bloc reference dans un explorateur Duniter V2 et verifiez le `system.remark`.
|
||||
|
||||
### L'archivage est-il automatique ?
|
||||
|
||||
Oui. L'archivage est declenche automatiquement :
|
||||
|
||||
- Quand une version d'item de document est acceptee
|
||||
- Quand une session de vote est cloturee
|
||||
- Quand une decision est executee
|
||||
- Quand un document est archive manuellement
|
||||
|
||||
### Puis-je acceder aux archives sans libreDecision ?
|
||||
|
||||
Oui. Les contenus archives sont accessibles via :
|
||||
|
||||
- **IPFS** : utilisez le CID pour recuperer le contenu depuis n'importe quelle passerelle IPFS publique ou un noeud local
|
||||
- **Blockchain** : le hash SHA-256 est enregistre dans un `system.remark` sur la blockchain Duniter V2, verifiable via tout explorateur compatible
|
||||
|
||||
## Questions techniques
|
||||
|
||||
### Sur quelle blockchain libreDecision fonctionne-t-il ?
|
||||
|
||||
libreDecision se connecte a la blockchain **Duniter V2** (basee sur Substrate). En environnement de developpement, il se connecte au reseau de test GDev (`wss://gdev.p2p.legal/ws`).
|
||||
|
||||
### Que se passe-t-il si la blockchain Duniter est indisponible ?
|
||||
|
||||
L'essentiel des fonctionnalites (consultation des documents, votes, decisions) reste accessible car les donnees sont stockees dans la base PostgreSQL locale. Seules les fonctions dependant de la blockchain sont affectees :
|
||||
|
||||
- L'authentification peut temporairement echouer si la verification WoT n'est pas en cache
|
||||
- L'ancrage on-chain des entrees du Sanctuaire est differe jusqu'au retablissement
|
||||
- Les snapshots de taille WoT/Smith/TechComm utilisent le cache
|
||||
|
||||
### Que se passe-t-il si le noeud IPFS est indisponible ?
|
||||
|
||||
L'upload sur IPFS est differe si le noeud est temporairement indisponible. Le hash SHA-256 et les metadonnees sont enregistres dans la base de donnees. L'upload peut etre relance ulterieurement. Le contenu deja uploade reste accessible via les passerelles IPFS publiques.
|
||||
|
||||
### Les donnees de vote sont-elles publiques ?
|
||||
|
||||
Oui. Les votes et leurs signatures cryptographiques sont publics, conformement au principe de transparence de la gouvernance. Chaque vote peut etre verifie independamment.
|
||||
|
||||
### Les mises a jour sont-elles en temps reel ?
|
||||
|
||||
Oui. libreDecision utilise une connexion WebSocket pour diffuser les mises a jour en temps reel :
|
||||
|
||||
- Nouveaux votes soumis : la jauge de seuil est recalculee instantanement
|
||||
- Votes modifies : la jauge reflette le changement immediatement
|
||||
- Sessions cloturees : le resultat final s'affiche
|
||||
- Un indicateur de connexion (point vert/orange/rouge) en bas a droite indique l'etat de la connexion temps reel
|
||||
|
||||
### Ou est heberge libreDecision ?
|
||||
|
||||
La plateforme est hebergee sur une infrastructure geree par la communaute, avec deploiement automatise via Docker et Woodpecker CI. Le code source est ouvert et disponible sur le depot Git Duniter.
|
||||
|
||||
## Securite
|
||||
|
||||
### Ma cle privee est-elle transmise au serveur ?
|
||||
|
||||
Non. Jamais. L'authentification utilise un mecanisme challenge-response : vous signez un texte aleatoire avec votre cle privee, et seule la signature est envoyee au serveur. La cle privee reste exclusivement dans votre portefeuille (extension Polkadot.js, Cesium, etc.).
|
||||
|
||||
### Comment la signature Ed25519 protege-t-elle mon vote ?
|
||||
|
||||
Chaque vote est accompagne d'une signature Ed25519 qui garantit :
|
||||
|
||||
- **Authenticite** : seul le proprietaire de l'adresse Duniter peut voter en son nom
|
||||
- **Integrite** : le payload signe contient le vote, l'identifiant de la session et un horodatage. Toute modification du vote apres signature est detectable.
|
||||
- **Non-repudiation** : le votant ne peut pas nier avoir vote
|
||||
|
||||
### Mes votes peuvent-ils etre falsifies ?
|
||||
|
||||
Non. Chaque vote est signe cryptographiquement avec votre cle privee Ed25519. Le payload signe contient le vote, l'identifiant de la session et un horodatage. Toute modification du vote apres signature est detectable car la verification de la signature echouerait. De plus, les votes sont publics et verifiables par n'importe qui.
|
||||
|
||||
### Comment verifier la signature d'un vote ?
|
||||
|
||||
Sur la page d'une session de vote, chaque vote affiche un lien **Verifier la signature**. En cliquant, le systeme utilise la cle publique du votant (derivee de son adresse SS58) pour verifier que la signature correspond bien au payload affiche. Vous pouvez aussi effectuer cette verification de maniere independante avec n'importe quelle bibliotheque Ed25519.
|
||||
Reference in New Issue
Block a user