Est-ce qu’on pourrait pas tous prendre l’habitude de tous nous renouveler aux équinoxes ?
A chaque équinoxe, on annoncerais le même message “équinoxe = le DU se revalorise + n’oubliez pas de renouveler votre adhésion”, et donc le reste de l’année pas besoin de chercher ceuix qui ont oublié de se renouveler, on leur a déjà dit de le faire à l’équinoxe
Est-ce que Duniter peut supporter qu’une grande partie de ses membres renouvellent leur adhésion la même semaine ? Peut être qu’à partir d’un grand nombre de membres ça va poser problème, donc pas une bonne idée
L’une des opérations les plus coûteuse est justement effectuée lors du renouvellement d’adhésion : le calcul de distance. Si l’on se retrouvait avec 1 million de membres qui se renouvellent en même temps le même jours cela signifie que tout les nœuds miroir du réseau devrait effectuer 1 millions de calcul de distance, ça ferai très très mal.
Évidemment on est encore bien loin de tout problème de charge a seulement 1500 membres, mais une fois des habitudes établies l’inertie de la masse est colossale, c’est donc au contraire lorsque nous sommes encore suffisamment petit qu’il nous faut réfléchir profondément aux consignes a transmettre aux utilisateurs, plus nous seront gros plus il nous sera très difficile voir impossible de changer les habitudes des utilisateurs.
J’inviterai donc plutôt a présenter le renouvellement comme une date d’anniversaire de contrat, les utilisateurs doivent juste se souvenir de l’anniversaire de leur entrée dans la G1, c’est quand même pas très compliqué
Pour aller dans le même sens qu’Éloïs, je pense que c’est un faux problème.
Car, si la monnaie libre compte aux yeux d’un membre il s’intéresserait à savoir quand est-ce que son statut de membre expire, comme une personne intéressée par les mouvements sur son compte bancaire va aller couramment le consulter.
De plus, les logiciels actuels ne permettent pas de savoir individuellement et efficacement quand va expirer son statut de membre. Actuellement aucun logiciel envoie des notifications par e-mail ou par d’autres moyens aux personnes concernées. Sakia et Césium sont à la ramasse de ce côté. Silkaj 0.6.0 donnera cette information mais reste dur à installer et à utiliser pour le commun des mortels. Il reste les logiciels de monitoring : monit donne déjà ces informations et wot-wizard va donner cette information. Mais, tous les membres consultent-ils ces tableaux des membres qui vont expirer et qui vont s’allonger au fur et à mesure qu’il y aura plus de membres ?
Donc, il y a un travail logiciel et éducatif pour améliorer ceci.
Une mauvaise idée pour une bonne question.
Je vais donc éviter d’encourager à renouveler l’adhésion aussi souvent que possible ayant pris connaissance de cette consommation de ressources.
Comme le dit elois, il est facile de créer des habitudes et très difficile d’y renoncer.
@jeanferreira non ça ce n’est pas gênant car on a un paramètre anti-spam (msPeriod) qui garanti que la fréquence des renouvellements ne peut pas être inférieure a 2 mois
Tant qu’il ne se transmet pas un “il faut absolument se renouveler tous les 2 mois” au sein de la toile, ça va aller.
D’autant qu’on peut toujours mitiger une “attaque par le renouvellement” au sein des logiciels. Mais bon, si on peut s’éviter ce problème, autant le faire.
C’est bien ce que je voulais dire. Habituellement je dis qu’on peut se renouveler de 2 mois minimum à 1 an maximum. Je vais baser ma com sur raisonnablement 6 mois à 1 an.
Le problème des alertes est qu’il nécessite un logiciel de type serveur ou à minima un “worker”, ce qui revient au même. Un logiciel avec une boucle infinie qui surveille quelque chose et alerte lors d’un changement d’état ou à un date définie…
Cela peut être un serveur dédié, mais le plus simple me semble être un module Duniter.
Qu’en pensez-vous ?
Il faudra aussi que les membres confient leurs adresses de courriel, de façon optionnelle, bien sûr, à des nœuds du réseau munis du module et dans lesquels ils ont confiance.
Apparemment oui. Je ne sais pas exactement dans quelles limites, notamment en termes de dépendances du programme en Go.
En tous les cas, ce n’est pas un module qui peut être ajouté “à chaud” via l’IHM Duniter, mais demande une installation de Duniter en compilation manuelle ou alors une distribution de Duniter embarquant le module, pré-compilé pour chaque environnement.
C’est pas une mince affaire de gérer des données personnelles comme les emails.
Il faut aussi configurer et stocker les informations de connexion au serveur de mail.
Et que ce soit convivial, simple et graphique. Ben YaPluka.
Je me demande si ce ne serait pas plus simple de s’appuyer sur les nœuds Elasticsearch de Cesium+.
Ils ont déjà les infos de profils dans lesquelles on peut avoir l’email.
Ils sont synchronisés avec les noeuds et peuvent sûrement envoyer des emails, en ajoutant cela au plugin ES actuel.
A voir avec @kimamila, si cela semble réaliste ou pas.
Crowdfunding ?