# Pallets instanciables et vérifications d'adhésion
**URL:** https://forum.duniter.org/t/pallets-instanciables-et-verifications-dadhesion/11699
**Category:** Duniter-v2s
**Created:** [15 November 2023 10:39 UTC](https://forum.duniter.org/t/pallets-instanciables-et-verifications-dadhesion/11699 "2023-11-15T10:39:17Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [15 November 2023 10:39 UTC](https://forum.duniter.org/t/pallets-instanciables-et-verifications-dadhesion/11699/1 "2023-11-15T10:39:17Z")
Duniter v2 utilise des pallets instanciables comme :
- la pallet wot
- la pallet membership
- la pallet certifications
Les deux instances de ces pallets sont :
- toile principale
- toile forgeron
Cela veut dire qu’il y a :
```rust
// une seule pallet identity (pas instanciable)
Identity: pallet_identity::{Pallet, Call, Config, Storage, Event} = 41,
// Web Of Trust
Wot: pallet_duniter_wot::::{Pallet} = 40,
Membership: pallet_membership::::{Pallet, Call, Config, Storage, Event} = 42,
Cert: pallet_certification::::{Pallet, Call, Config, Storage, Event} = 43,
// une seule pallet distance (pas instanciable)
Distance: pallet_distance::{Pallet, Call, Storage, Inherent} = 44,
// Smith Sub-Wot
SmithSubWot: pallet_duniter_wot::::{Pallet} = 50,
SmithMembership: pallet_membership::::{Pallet, Call, Config, Storage, Event} = 52,
SmithCert: pallet_certification::::{Pallet, Call, Config, Storage, Event} = 53,
```
C’est pratique, parce que ça permet de découper en petit composants testables et réutilisables des fonctionnalités très similaires.
Mais jusque là, les traits comme `CheckCertAllowed` et `CheckMembershipCallAllowed` étaient définis sans prendre en compte les instances, avec `I: 'static` :
```rust
impl, I: 'static> /* [...] */ for Pallet
```
Et les seules vérifications faites l’étaient sur une pallet non instanciable (en l’occurence `pallet_identity`).
Cela empêche par exemple :
- de vérifier que l’émetteur d’une certification est bien membre
- de vérifier que le destinataire d’une certification a bien une adhésion ou une demande d’adhésion en cours
Pour contourner ça, elois a utilisé le statut d’identité ([Demande d'adhésion et statut d'identité](https://forum.duniter.org/t/demande-dadhesion-et-statut-didentite/11698)), ce qui fonctionnait à peu près pour la toile principale, mais :
- causait un comportement étrange pour la toile forgeron ([Becoming smith (request\_membership, claim\_membership)](https://forum.duniter.org/t/becoming-smith-request-membership-claim-membership/10571))
- limitait les possibilités de perte de statut membre (expiration d’adhésion, passage sous le seuil de certifications, ou évaluation négative du critère de distance)
Je pense que elois n’avait pas totalement conscience de ça et que c’était la raison secrète qui le poussait à vouloir [Proposition de supprimer la notion d'identité désactivée mais non révoquée et la notion d'adhésion](https://forum.duniter.org/t/proposition-de-supprimer-la-notion-didentite-desactivee-mais-non-revoquee-et-la-notion-dadhesion/9051).
* * *
La bonne manière de faire (selon moi) serait de donner les instances `Cert` et `Membership` à `Wot` (et `SmithCert` et `SmithMembership` à `SmithSubWot`) pour pouvoir implémenter les traits sur des instances, et non pas de manière statique.
Comme ça représente quand même un certain chantier qui peut me prendre quelques semaines à finaliser (implémentation, relecture, tests…), je pense que je vais le faire _après_ le lancement du réseau de test tant attendu. À voir si ça vaudra la peine de déployer dessus (sûrement des migrations complexes à écrire) ou s’il vaudra mieux rebooter un nouveau réseau de test.
Et je vais me contenter d’un fix simple pour [#129](https://git.duniter.org/nodes/rust/duniter-v2s/-/issues/129) en supprimant simplement les métadonnées d’adhésion.
---
### Author:  [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [16 November 2023 12:43 UTC](https://forum.duniter.org/t/pallets-instanciables-et-verifications-dadhesion/11699/2 "2023-11-16T12:43:34Z")
~~Je n’arrive pas à comprendre le problème. Je viens de décommenter le code lié au ticket #136 [sur ce commit](https://git.duniter.org/nodes/rust/duniter-v2s/-/commit/e4023024475720409e366c99065a8a38125dc1cc), et corriger une petite coquille (un `&&` au lieu d’un `||`).~~
~~Et les deux tests de `fixme_tests.rs` échouent comme attendu. 🤷♂️~~
Je suis vraiment mal réveillé aujourd’hui, oublie.
Néanmoins je ne vois toujours pas le soucis, les WoT impliquées sont bien séparées, je ne vois pas en quoi tu ne pourrais pas faire les vérifications.
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [16 November 2023 13:21 UTC](https://forum.duniter.org/t/pallets-instanciables-et-verifications-dadhesion/11699/3 "2023-11-16T13:21:33Z")
Les wot sont bien séparées, mais elles n’ont pas “conscience” des instances de _certification_ et _membership_ auxquelles elles sont liées. J’avoue que je n’ai pas creusé à fond la question, je pense que c’est mieux de régler ça après le lancement du réseau de test. C’est vrai qu’on pourrait quand même faire les vérifications en implémentant les traits `Check*CallAllowed` sur les pallets _certification_ et _membership_ et en les fournissant sous forme de tuple. Mais de toute façons les implémentations devraient prendre en compte l’instance `I` pour explorer les données rattachées à cette instance, donc je trouve ça plus simple de tout relier en utilisant la pallet _wot_.
En gros, si on émet une certification forgeron, vers une identité A, il faut vérifier :
- que A est bien membre de la toile principale (son adhesion n’a pas expiré par exemple)
- que A a une adhésion en cours à la toile forgeron ou est membre de la toile forgeron
Ces vérifications ne doivent pas se faire uniquement de manière statique en stockant dans Idty son statut, mais bien auprès de chaque instance des pallets.
On peut omettre certaines vérifications si on fait en sorte qu’elles se réalisent toujours, mais dans se cas, il faut s’assurer de la cohérence du storage.
Exemple : si A perd son statut de membre sur la toile principale, il doit aussi perdre son statut de membre de la toile forgeron. Dans l’implémentation d’elois, il n’y avait pas ce problème parce l’identité (et toutes les données liées) était immédiatement supprimées ([Proposition de supprimer la notion d'identité désactivée mais non révoquée et la notion d'adhésion](https://forum.duniter.org/t/proposition-de-supprimer-la-notion-didentite-desactivee-mais-non-revoquee-et-la-notion-dadhesion/9051)). Mais c’était une trop grosse modification par rapport au protocole Duniter v1 et en plus très “punitive”, au sens où il fallait recommencer une identité de zéro, changer de pseudo, obtenir les certifications…
Donc j’ai autorisé la perte d’adhésion sans suppression d’identité, mais en introduisant des “bugs”. Maintenant il faut travailler à corriger ces “bugs” pour se rapprocher davantage du comportement v1 qui est bien plus souple et logique sur ce point.