surlebeat / demeter-discord-bot Goto Github PK

Le 09/03, Déméter ne répondait plus. Voici ce que j'avais conclu :

Chaque jour (à des horaires aléatoires), Heroku redémarre les applications qui y sont hébergées. Hier, le redémarrage a eu lieu à 19h07. Quelqu'un se souvient de ce qu'il s'est passé à cette heure-là? Discord était down! Pendant au moins une bonne demi-heure, plus personne n'y avait accès. En redémarrant, le bot n'a pas su se connecter à Discord.

Il faut donc que si la connexion échoue, on réessaye toutes les minutes. Il faudra aussi corriger les logs, car malgré l'erreur, on a loggué que la connexion était OK :

Lors de rapide sondage ou @everyone, le propriétaire du message reçoit souvent beaucoup de réputation car son message reçoit beaucoup de réactions.

Une fonctionnalité intéressante pourrait permettre de marquer un message comme étant inéligible à recevoir de la réputation.
Ex : si la communauté ou le propriétaire du message réagis avec l'emoji 🐙 (c'est un exemple!), alors on ne prend pas en compte ce message lors du calcul de la réputation.

On pourrait définir un nombre de points de réputation minimum (configurable) : 300 par défaut ?

Implémentation :
Si le propriétaire d'un message réagis à son propre message avec l'emoji 🐙
OU
Si la communauté réagis à un message avec l'emoji 🐙et que la somme de la réputation de chacun est supérieure au minimum défini
ALORS
Le message n'est pas pris en compte lors du calcul de la réputation par Déméter.

Au démarrage de Déméter, checker si des messages ont reçu des réactions ou des réponses.

Car dans l'état actuel, si je redémarre Déméter (pour déployer une nouvelle version ou après un éventuel plantage), elle n'ira pas voir ce qui s'est passé durant son absence.

Concernant les réactions sur les messages, ce n'est pas très important, ça affecte seulement la distribution de la réputation. Mais concernant les propositions encours de vote, c'est plus gênant. Les votes des membres réalisés durant la déconnexion de Déméter passeront à la trappe! Pas très démocratique et en plus, on pourrait ne jamais atteindre les 2000 ou 6000 pts de réputations requis...

Lorsqu'on arrête Déméter (déploiement d'une nouvelle version), les données persistées en DB (in memory) après le dernier push de la DB sur IPFS seront perdues à jamais.

Il faudrait que lorsque l'app node détecte qu'elle va être kill, elle push d'abord la DB sur IPFS avant de s'éteindre.

On pourrait penser que l'issue #10 couvre ce besoin, mais pas entièrement. En effet, les commandes tapées ne seront pas réexécutées par l'issue #10.

Exemple concret, quelqu'un édite ses préférences ou la conf de la guild (serveur) à 10h40. A 10h55, Déméter est arrêtée afin de déployer une nouvelle version. Ces derniers changements n'auront pas été poussés sur IPFS et ne seront donc pas pris en compte lors du redémarrage.

Actuellement, la DB est poussée sur IPFS toutes les 30 min.

Lors de chaque démarrage, il va chercher le dernier état de la DB sur web3.storage. Seulement, lors du premier démarrage, il ne trouve pas de dernier état (logique!) donc il plante.

Contournement : commenter la ligne await loadDb(clientWeb3, db, mutex) dans bot.js.

Une solution plus pérenne serait de pouvoir indiquer (via variable d'environnement ou argument?) qu'il s'agit du premier démarrage et qu'il ne faut donc pas tenter d'aller chercher le dernier état.

Le fonctionnement du salon 📕-manuel-demeter de DFF n'est pas parfait. On ne peut pas éditer le message de Nolan. A chaque changement, il faudrait supprimer tout le contenu du salon et tout réécrire...

Une chouette fonctionnalité serait de pouvoir configurer Déméter (au moyen d'une commande). On pourrait dire à Déméter "Hé, le manuel de notre Discord est hébergé ici (url du gitbook ou d'un repo github)". Et Déméter, viendrait automatiquement récupérer le contenu du Gitbook et l'afficherait dans 📕-manuel-demeter . Chaque heure, elle pourrait aller récupérer les dernières modifications.

Auparavant, on pouvait :
-s'ajouter à une liste d'attente afin d'être validé (=vouché ou parrainé) sur PoH
-consulter la liste: affiche la liste des membres en train d'être parrainé et ceux en attente
-parrainer un membre : une période de 24h est initiée. Le membre parrainé à ensuite 24h pour remercier son parrain. Durant ces 24h, lorsqu'on affiche la liste, le membre apparait dans la section "membres en train d'être parrainé". Le délai écoulé, sans remerciement, le membre retourne dans la liste des membres en attente.
-remercier son parrain : retire le membre de la liste et attribue des points de réputation à son parrain (0 par défaut et valeur à configurer grâce à une commande).
-se retirer de la liste

Il faudrait réimplémenter cette fonctionnalité.

Cela cause un probleme par exemple ici. Il faudrait mettre la recherche de l'url de faço plus globale

 if (!messageUrl.startsWith('https://discord.com/channels/') || !messageId || !duration || duration < 1) {
            await interaction
                ?.reply({content: 'Please provide message url and duration...', ephemeral: true})
                ?.catch(() => logger.error('Reply interaction failed.'))
            return true
        }

Lors du premier démarrage, inutile de consulter la réputation des membres, lancer un round ou quoique ce soit avant d'avoir tapé au moins une fois la commande /guild config ... car sinon, la "guild" (= le serveur Discord) n'existe pas encore.

Peut-être pouvons-nous améliorer ce comportement?

Il y a au moins un autre bug de ce genre où l'utilisateur n'existe pas tant qu'il n'a pas fait une certaine action (réagir ou répondre au message d'un autre membre je pense).

Actuellement, c'est le compte web3.storage (IPFS) de Cyrille qui est utilisé pour stocker les données.
Si Cyrille venait à quitter DFF, on serait embêté.
Il faudrait trouver un moyen pour répliquer le contenu ailleurs de manière périodique.

Un cron quotidien qui exporte le dernier état de la DB stocké chez Cyrille vers d'autres stockages?
Exemple, 4 variables d'environnement :
WEB3_STORAGE_SOURCE=le-token-de-cyrille
WEB3_STORAGE_DEST_1=le-token-de-nico
WEB3_STORAGE_DEST_2=le-token-de-ootsun
WEB3_STORAGE_DEST_3=le-token-de-taz

Ou autre solution :)