Proposition : Licence Ğ1 - v0.3.0

Salut,
Est-ce que je n’arrive plus à suivre les annonces, en constatant que la fin du vote serait le 13 mars 2025, alors que le décompte du vote d’aujourd’hui 25 février 2025 12h, vient de sortir ?!?

Le décompte est live jusqu’à la fin du vote.

Pour améliorer l’accessibilité et l’efficacité de la licence de la monnaie Ğ1, il serait bénéfique d’introduire un système de mentorat. Ce qui pourrait permettre aux nouveaux membres d’être accompagnés par des membres expérimentés qui les aideraient à naviguer dans le processus de certification. Simplifier certaines étapes du processus de certification tout en maintenant les exigences de sécurité pourrait encourager davantage de monde à rejoindre la communauté. Et pourquoi pas envisager des sessions d’information régulières pour les nouveaux membres pour faciliter leur intégration et renforcer le sentiment d’appartenance à la communauté.

3 « J'aime »

Salut les amis,

Je trouve super cette démarche de chercher à établir un processus qui permette de définir et modifier les règles qui nous relient… Nous explorons le « Référendum d’Initiative Citoyenne » (« RIC »), c’est ça ?

J’ai relevé lors de ma lecture différents points qui me semblent manquer de clarté.

Ces mentions sont très imprécises. Même si l’intention est claire, la méthode reste floue. Il existe déjà certainement dans notre TdC des comptes membres qui ne respectent pas la Licence. J’ai moi même été alerté de ces comportements, mais n’ai su à qui m’en remettre pour relayer l’information…

Cet algorithme est celui qui nous en protège le mieux. Mais limite la dimension que peut prendre une TdC sans se fragmenter.

A ce sujet, il serait judicieux d’expliciter avec la v2 une méthode simple pour démarrer un nouveau bloc 0, ceci afin de respecter la 4e liberté.

  • la liberté d’utiliser le logiciel.
  • la liberté de copier le logiciel.
  • la liberté d’étudier le logiciel.
  • la liberté de modifier le logiciel et de redistribuer les versions modifiées.

Cette méthode déjà éprouvée et fonctionnelle me parait être celle que nous devrions mettre en place. Malheureusement, la diversité de nos canaux de communications (telegram, signal, matrix, whatsap, facebook, twitter, tiktok ;), … email, forums, cesium+, téléphone, visio, …) ne permet pas de garantir un lien entre Humain (reconnu par la TdC) et compte Utilisateur sur ces plateformes.

Pour y parvenir, il faut que notre « Application Sociale » utilise une clef de chiffrement asymétrique comme « login » et que cette clef porte la preuve que l’usage de la clef privée membre ai été fait lors de sa création. La méthode de « jumelage » de clef portefeuille et marquage par primo transaction est une façon d’obtenir cette preuve…

J’ajouterai que même une « rencontre IRL » ne permet pas de savoir si « cet humain ne dispose que d’un compte forgeron »… Il faudrait pour cela avoir une meilleure vision de nos toiles respectives, de la distance relative et de leurs possibles intersections.

Ces schémas apparaîssent lors de la visualisation des « sphères informationnelles » du « graph social » de chacun (N1, N2,…).

C’est ce que j’ai tenté de matérialiser au travers du « UPassport », un document créé par le jumelage d’une clef portefeuille G1 avec une clef IPNS qui déclenche l’analyse du réseau N1 de la clef membre fourni lors de la création (mode « fac-similé ») et ne devient valide qu’une fois avoir reçu une « primo-transaction » émis par la « clef privée membre » associée.

Je suis bien d’accord… Et la nouvelle Licence ne change pas grand chose. Ainsi, je ne voterai « ni pour, ni contre » (donc « pas ») tant les changements y sont insignifiants et qu’aucune solution, ni méthode qui permette d’identifier clairement les chaînes de délégations de confiance n’y sont proposés.

Il nous faudrait au préalable réussir à faire évoluer notre TdC de « sauvage » à « civilisée », par le fait de pouvoir se nommer, se différencier et se reconnaître « crytographiquement » afin d’identifier les individus et les rôles assurés par chacun et ainsi leur déléguer notre pouvoir décisionnel en connaissance de cause… Pour cela il nous reste à révéler de nombreuses autres toiles de confiance, qui seront forcément relatives et uniques à chacun.

Personnellement, à notre Charte, j’ajouterai le fait de s’engager à utiliser, défendre et propager l’usage d’un Système Libre sur les machines appartenant aux membres et utilisateurs ! De ne pas acheter sur Gchange pour revendre sur LeBonCoin (comportement déjà constaté). Plus généralement je voudrai n’échanger que des produits qui disposent de leur mode d’emploi ET de leur mode de fabrication détaillé tel que « GNU/Linux » et les Logiciels Libres le réalisent. Je sais c’est radical :stuck_out_tongue: et peut-être inacceptable par certains, mais c’est ce qui me motive… Et vous qu’est ce qui vous motive ?

1 « J'aime »

Bonjour et merci @1000i100
Petite interrogation :

Citation : Si vous vous rendez compte qu’un certificateur effectif ou potentiel du compte concerné ne connaît pas la personne concernée, alertez immédiatement des experts du sujet au sein de vos connaissances de la TdC Ğ1, afin que la procédure de validation soit vérifiée par la TdC Ğ1.

Peut-on savoir qui sont ces « experts du sujet » ?

le sujet étant :
« un certificateur effectif ou potentiel du compte concerné ne connaît pas la personne concernée »

Qui connait, dans son environnement un expert de la sorte ?

Citation ; afin que la procédure de validation soit vérifiée par la TdC Ğ1

Comment la TDC peut-elle « vérifier » ?

1 « J'aime »

Je suis bien d’accord.
Je t’invite à regarder notre proposition de Charte 1.0 qui était une refonte de la licence tentant de corriger ce genre d’imprécision entre autres choses.
Cette dernière cherchant à corriger/améliorer tout ce qui nous semblait utile de l’être a été refusée (il est plus difficile de faire une proposition qui convienne à tout le monde quand ont fait des changements sur tous les fronts à la fois) nous avons donc écouter les retour et changé d’approche :
Pour la proposition actuelle (Licence v0.3.0) nous avons gardé la licence actuelle (v0.2.9) avec tous les défauts qu’elle a selon nous, mais en y ajoutant un procédé de modification, pour valider sur ce coup le fait de pouvoir la faire évoluer à l’avenir et comment.
Bref, très précisément ce que tu nommes :

Une fois ces règles de modification validé, nous pourrons faire d’autre proposition pour améliorer le contenu (en s’inspirant de notre proposition de Charte 1.0 par exemple).

Je comprends ta frustration, mais l’expérience nous a montré que vouloir changer tout ce qui ne va pas ne permet pas une acceptation suffisamment large pour faire adopter la proposition, d’où le fait d’y aller étape par étape.

Pour le reste de ton message, il y a certaines choses qui me parle et d’autres moins, mais ça s’éloigne de l’object de cette proposition spécifique concernant le « processus qui permette de définir et modifier les règles » donc je ne détail pas plus ici :wink:

Même réponse qu’a @qoop
C’est une partie qui me parait flou et qui mériterait d’être remanié, ce que nous avons tenté de faire avec la proposition de Charte 1.0.
Nous proposerons des changements sur ce point plus tard si le moyen de changer est validé :wink:

1 « J'aime »

Une heure à lire l’ensemble des discussions … C’est trop long.
Je trouve que l’usage exclusif du forum pour structurer le débat et valider les décisions atteint ses limites. Il devient difficile de suivre les propositions, les évolutions et d’arriver à un consensus clair.

J’ai quelques idées à proposer :

On pourrait aider à la lecture des discussion faire des résumés avec un plugin IA ajouté au forum
Ensuite on pourrait utiliser Git et un système de validation décentralisé qui utilise le partage de clés (Shamir) :

1. Utilisation de Git pour la gouvernance

  • Chaque proposition est soumise sous forme de Merge Request (MR) dans un dépôt Git (GitLab/Gitea).
  • On peut suivre précisément l’évolution des propositions et leur historique.
  • Les discussions restent visibles et auditables.

2. Validation collective via un mécanisme de seuil (Shamir)

  • Chaque participant au processus décisionnel possède une part de clé permettant d’approuver une proposition.
  • Lorsqu’un nombre suffisant de participants (N/2 +1) valide un MR, celui-ci est automatiquement fusionné.
  • Exemple de seuils progressifs :
    • 1 individu = 2/1
    • 3 individus = 3/2
    • 5 individus = 5/3
    • N individus = N/2 +1

3. Délégation de vote pour élargir la participation

  • Ceux qui ne veulent pas suivre activement les discussions peuvent déléguer leur vote à un participant.
  • Un participant recevant plusieurs délégations voit son vote pondéré en conséquence.

Qu’en pensez-vous ? :blush:

2 « J'aime »

Salut et merci pour tes retours. Je n’ai malheureusement pas le temps de répondre à toutes tes remarques, de plus, Millicent l’a très bien fait. Juste, pour que tu aies une idée d’où est né notre groupe de travail, dont l’intention va dans le sens de tes remarques : Reformulations licence Ğ1 - Ğ1 - Duniter Forum

Je comprends, l’idée c’est que là tu avais au moins la première proposition, qui tentait de reformuler entièrement la licence, en enlevant les maladresses et les flous artistiques du genre « les experts du sujets », « connaître bien la personne », etc… :slight_smile:

1 « J'aime »

Je ne vois pas où voter :frowning:

@Rajesh , c’est précisé sur le premier post

Bonjour ,
Encore bravo pour cette expérience de gouvernance de la G1 . C’est tellement important de pouvoir connaître l’avis des membres qu’il est nécessaire d’avancer dans ce sens .Cette proposition ne fait pas rêver , on ne peut que souhaiter plus concis . Ça viendra , n’en doutons pas .
J’avais énormément apprécié le post de 1000i100 sur le forum duniter sur le sujet de la gouvernance il y a quelques temps .
Reste à construire des outils pour y arriver .
J’ai voté OUI parce que j’ai apprécié la démarche .

1 « J'aime »

J’ai procédé au vote. bonne journée
Rajesh

Bonsoir à tous

@1000i100 est ce que cette analyse est juste dans le but denous aider à comprendre cette mise à jour de la licences pour arriver à prendre une décision :

aide pour l’analyse de la mise àjours de la licence 0.29 à 0.30

La transition vers la licence v0.30 du réseau TdC Ğ1 représente une évolution importante, apportant des changements significatifs par rapport à la version précédente v0.29. Voici un résumé des principales différences:

Licence v0.29:

  • Système de certification plus rigide: La vérification des membres était plus restrictive, nécessitant une interaction humaine directe et intensive pour valider l’identité d’un utilisateur.

  • Modèle monétaire basé sur le DU: Le Dividende Universel (DU) était distribué quotidiennement à chaque membre humain du réseau, sans distinction de participation ou contribution.

  • Structure communautaire moins évolutive: La classification des membres en « référents » était basée sur un système relativement statique et les possibilités d’évolution étaient limitées.

Licence v0.30:

  • Système de certification simplifié: La vérification des membres est simplifiée grâce à l’intégration de nouvelles technologies qui permettent une authentification plus efficace et accessible.

  • Modèle monétaire plus dynamique: Le DU est désormais ajusté en fonction de la contribution des membres au réseau, récompensant activement leur engagement et participation.

  • Structure communautaire plus flexible: La classification des membres et les opportunités d’évolution sont revues pour favoriser une structure plus adaptable et évolutive, encourageant la participation à différents niveaux.

En bref, la licence v0.30 vise à:

  • Faciliter l’intégration de nouveaux membres et leur contribution au réseau.

  • Encourager l’engagement et la participation active des membres.

  • Créer une structure communautaire plus dynamique et flexible.

La transition vers la licence v0.30 marque un pas important dans l’évolution du réseau TdC Ğ1, permettant d’améliorer l’expérience utilisateur et de renforcer la dynamique collaborative au sein de la communauté.

cordialement Wilfried

1 « J'aime »

Pour l’instant la v0.3.0 ne fait qu’ajouter le processus de modification de la licence.

Une fois ce processus accepté, on pourra proposer de nouvelles modifications, y compris celles du processus de modification.

4 « J'aime »

Résultat des votes selon le protocole de modification que nous avons proposé :
Après élimination des doublons et votes non-membre, nous avons :

180 votes "Pour"
24 votes "Contre"
1 vote "Nul"

Pour que la proposition soit retenue il y a besoin 140 votes « Pour » : 20 + 5*(24 votes « Contre »)
Il y a 180 votes « Pour », La proposition est donc adoptée !

Synthèse avec Ğ1 vote view

Comptage manuel détaillé :

  • 180 votes « Pour » dans les délais
  • 24 « Contre » dans les délais
  • 1 « Nul » (vote « Pour » et « Contre » par le même compte membre)
  • 1 double vote « Pour » par un compte membre, n’a été compté qu’une seule fois.
  • 6 votes « Pour » non comptabilisés car hors délais (après la fin de la période de vote de 30 jours comptés à partir de l’heure de publication sur le forum : 11/02 à 22h12)
  • 5 vote « Pour » non comptabilisés car depuis comptes non-membre
  • 1 vote « Contre » non comptabilisés car depuis compte non membre

4 616,08 Ǧ1 ont été collectées (4 374,43 Ğ1 sur le compte pour + 241,65 Ğ1 sur le compte contre).
Nous en avons versé 1616,08 à Mégadon HjWkHYDod49Cc9q6DB9BtUbiY2XgJ2tmQfKgyYKo5TQQ:xuX
1500 G1 à la caisse Rémuniter TENGx7WtzFsTXwnbrPEvb6odX2WnqYcnnrjiiLvp1mS:AXW
1500 G1 à la caisse des développeurs 78ZwwgpgdH5uLZLbThUQH7LKwPgjMunYfLiCfUCySkM8:4VT

Merci pour votre participation !

7 « J'aime »

Je ne crois pas que cela soit prévu!

2 « J'aime »

Mise à jour de G1vote-view qui intègre désormais :

  • les bonnes heures de début et fin de vote (ou presque) : elle se base sur le premier vote en blockchain, plus fiable que l’heure de publication de la proposition sur le forum, qui pourrait être manipulé par un administrateur du forum. Dans le cas présent, il y a 3 minutes d’écart et ça ne change pas les votes comptabilisés (il n’y a pas eu de vote durant ces 3 minutes).
  • l’affichage des commentaires de transaction dans le détail des votes « pour » et « contre », permettant notamment d’accéder aux arguments contre.
  • un lien vers les blocs de chaque vote en cliquant sur leur horaire
  • un lien vers la page profil de chaque compte votant (sur demo.cesium.app)
  • l’affichage, toujours dans le détail des votes, des votes nuls ou invalides accompagnés du motif pour lequel le vote n’est pas comptabilisé dans les « pour » ou les « contre ».
  • Un graphique de l’évolution des votes au cours du temps.

C’est tout pour le moment.

6 « J'aime »

Merci @1000i100 pour tes explications.

Je suis entrain de relire depuis le début afin d’avoir une meilleure vue d’ensemble.

Tu ne retiens pas ma proposition et je suis d’accord avec toi.

Ma difficulté venait d’abord de la forme utilisée pour expliquer le mode de scrutin.

Grâce à une relecture, je dirais, « plus concentrée » et aux formes différentes de présentation, mon entendement est plus clair et plus précis.

Par ailleurs, je n’ai pas tenu compte des contraintes techniques. C’est un inconvénient mais c’est aussi la position des non devs pour la plupart… Ce qui change la donne.

Je pense qu’il serait bon de rappeler ces contraintes le plus souvent possible, pour, à la fois informer et gagner en efficacité.

Je continue ma relecture…

1 « J'aime »