De la prise de décision entre modérataires
Les discussions entre modérataires ont lieu via le channel “General” de l’espace de discussion Matrix des modérataires. Les modérataires essaient d’arriver à un consensus par discussion.
S’il est nécessaire de participer à un vote parce qu’en consensus ne peut pas être trouvé, les différentes positions sont exprimées sur le channel “Annonces”. Les modérataires votent ensuite pour ou contre les différentes propositions via des emojis réactions pouce vers le haut / pouce vers le bas
Si un modérataire estime qu’une décision nécessite un vote anonyme, celui-ci est organisé via Framapoll (https://framadate.org/create_poll.php?type=autre&lang=en)
Du choix des admins
Les modérataires discutent entre eux pour décider d’une liste de candidats au poste d’admins.
Cette liste est ensuite soumise sur !meta@jlai.lu pour vote public par la communauté.
Les postes d’admins sont également ouverts: - aux autres modérataires qui ne sont pas sur le Matrix - aux autres membres de Jlai.lu, mais qui devront d’abord modérer une communauté avant de pouvoir devenir admin
Les hauts-votes sont monitorés via une instance mbin (telle que https://fedia.io/m/meta@jlai.lu) qui permet d’afficher les hauts-votes, et identifier les potentiels comptes “trolls” (créés moins de 2 semaines avant le vote).
Le vote est clôturé après une semaine.
Une fois élus, les admins peuvent décider d’utiliser un compte alternatif pour leurs taches d’administration, afin de dissocier leur compte standard et leur compte admin. Du rôle des membres actif-ves
Les membres actif-ves peuvent être consultés par les modérataires via le Matrix général “Jlai.lu” pour avoir des retours sur leurs décisions sans devoir passer par un post public sur !meta@jlai.lu.
Les membres peuvent également faire part de leurs retour aux modérataires sur le Matrix.
Du rôle des membres
Chaque membre de l’instance est libre de proposer des changements en postant sa proposition sur la communauté !meta@jlai.lu
Ok, plus bénin que je pensais alors. Mais je trouve ça un peu étrange qu’au moins le total anonymisé ne soit pas fédéré. Genre là demain pour une raison X ou Y la communauté décide de changer d’instance, tous les posts où on vote en commentaire auront leur résultat perdu. Perso je trouve que c’est un peu un bug dans l’implémentation de la décentralisation.
C’est parce que les actions de votes ne sont envoyées qu’une fois à toutes les instances, il n’y a pas de mécanisme de consolidation du nombre de votes par la suite
De toute façon, si on changeait d’instance, on perdrait tout, pas uniquement les votes. Il n’y a pas de migration de contenu sur Lemmy, sur Mastodon non plus d’ailleurs: https://slrpnk.net/post/12361352
De ce que j’ai compris, si demain une inondation détruit les serveurs jlai.lu, les autres instances ont quand même mirroré son contenu, comme par exemple https://slrpnk.net/c/france@jlai.lu
Y a pas d’outil de migration prévu, c’est vrai, mais l’archive existe et pour qui a accès à la machine et un peu de motivation, on doit probablement pouvoir repeupler la base. Et je dois avouer que si la question m’intéresse c’est que j’avais envisagé de mettre les mains dans ce cambouis si un jour la vie me le permettait.
Mais dans cette hypothèse, où je crée en 2025 une instance keepthep.ace et la fédère à jlai.lu, il me manquera toutes les infos de vote dans la base locale sur les commentaires de 2024. keepthep.ace/c/france@jlai.lu et slrpnk.net/c/france@jlai.lu auront des contenus différents dans les posts de 2024 et la fédération ne me donnera même pas accès à toutes les infos que je pourrais avoir juste en scrapant slrpnk.net/c/france@jlai.lu (comme le total des votes), ce que je trouve quand même vachement étrange comme choix.
Attention que la fédération n’est pas censée se substituer aux backup et à la continuité des opérations de l’instance.
Dans ton scénario, l’instance Jlailu doit être recréée depuis ses propres sauvegardes
Pas tellement, dans ta proposition n’importe qui peut créer des instances en boucle, se connecter à des instances-cibles, et récupérer tous les votes depuis leur création, potentiellement amenant à un DDoS
Toute API peut être DDoS si elle n’implémente pas de QoS. Qu’il faille plusieurs jours pour reconstruire une archive ne me choque pas.
Mais là je trouve que la fédération ne fait que la moitié du boulot. Une instance fédérée est censée dupliquer les infos. AMHA il serait préférable qu’elle décide soit de tout récupérer soit de ne rien récupérer d’avant sa fédération.
Parce que bon imagine un peu le bordel de quelqu’un qui accède à /c/france depuis une instance qui s’est fédérée une journée après un post qui appelle à un vote: les comptes différeront en fonction des instances. Je me demande quelle est la logique derrière cette décision
N’hésite pas à ouvrir une issue sur le Github de Lemmy, les devs seront sans doute les plus à même de te répondre.
C’est un cas limite, et même dans celui-ci, les scores références seront sur l’instance source
J’ai mis un doigt dans les issues lemmy quand j’ai constaté qu’ils avaient un filtre à insultes codées en dur, ce qui empêchait notamment de parler de “retard” en français et… j’ai pas envie d’y retourner! Ils sont bien chelous.
Ils sont un peu spéciaux effectivement
@keepthepace et est ce que les alternatives à lemmy t’interessent ? Si oui, lesquelles ? @Camus
Je trouverais ça dommage de switcher alors que la commu commence à exister, si je devais passer à une alternative je prendrais un truc qui sache se fédérer avec lemmy. Kbin peut être?
J’ai malheureusement pas la bande passante maintenant pour m’intéresser aux histoires de protocoles compatibles ou non, de clients, de frontends, de backends…