Meeting #2

Cette seconde réunion a eu lieu sur un pad le 4 février 2021 à 17h00 GMT, une semaine exactement après la première. Certain·es contributeurices n'étaient pas disponibles à ce moment, et seulement une demi douzaine de personnes sont venues. Pour cette raison, il a été décidé qu'aucune décision importante ne serait prise durant cette réunion : les questions importantes ou controversées sont reportées à la prochaine réunion, qui sera préparée et annoncée longtemps à l'avance.

Durant cette réunion, nous avons jeté un œil à ce qui s'est passé dans les différents Groupes de Travail (rapport de progression). Puis, nous avons discutés de communication. Puis, nous avons eu un point sur l'accès aux identifiants pour les comptes de media sociaux, que faire de notre forum, et comment organiser la prochaine réunion. Enfin nous avons fait quelques questions & réponses pour ce qui n'était pas le sujet durant cette réunion.

Le plus long, potentiellement controversé point à propos de Jabber vs XMPP (le nom du collectif) et les serveurs que nous recommandons ont été discuté brievement, mais aucune décisions n'a été prise. Ces deux points sont reportés à la prochaine réunion. La réunion a été terminé environ 4h45m après son début.

Ordre du jour

Points

Dans cette section, nous discutons des points individuels prévus dans l'agenda.

Depuis le dernier meeting

Avant de discuter des autres points, nous avons pris un moment pour parler de ce qui avait été fait depuis la précédente réunion. Dans chaque sous-section, nous abordons d'abord le cahier de suivis du groupe de travail depuis la dernière réunion, puis présentons d'autres initiatives prises par le groupe de travail depuis la dernière réunion.

Cette section est composé de simples rapports d'avancement. Ça sera rapide, et les questions/préoccupations seront exprimées dans des points dédiés de l'agenda, ou dans les questions/réponses à la fin de cette réunion. Les TODO pour chaque Groupe de Travail incluent à la fois un cahier de suivis des tâches, et des tâches ajoutées durant cette réunion.

Tâches collectives

Dans ce point, nous parlons des tâches collectives décidées durant la dernière réunion, qui n'ont pas été assignés à un groupe de travail spécifique :

  • publier le compte rendu de la réunion #1 : Fait ici
  • publier l'annonce : fait ici
  • lancer un sondage pour la date de la prochaine réunion : fait ici
  • préparer le pad pour la prochaine réunion, ajouter les points dont on a pas pu parler aujourd'hui à l'agenda : fait
  • lister les autres collectifs que nous voudrions inviter à la réunion À FAIRE
  • préparer un tutoriel sur comment organiser une réunion et y participer À FAIRE

TODO :

  • lister les autres collectifs que nous voudrions inviter à la réunion ici À FAIRE
  • préparer un tutoriel sur comment organiser une réunion et y participer À FAIRE

Groupe de Travail Sysadmin

Suivis de la dernière réunion :

  • configurer la solution de pont porposée par le Groupe de Travail Pont
  • considérer l'installation de ConverseJS pour que les personnes puissent rejoindre nos salons et réunions depuis le web

Notes depuis la dernière réunion :

  • ConverseJS n'est pas empaqueté pour Debian, nix ou guix, on devra le configurer manuellement ; converseJS n'a pas été configuré pour le moment ; xmpp-web est une potentielle solution alternative, plus légére
  • Matterbridge n'est pas empaqueté pour Debian ou guix, mais est empaqueté pour nix (mais le paquet est dépassé) ; matterbridge a été configuré depuis les sources en utilisant golang depuis le backport Debian

TODO :

  • configurer prosody pour supporter BOSH et anonymous login
  • considerer s'il faut activer mod_slack_webhooks pour que matterbridge puisse créer des utilisateurices fantômes au lieu de relayer les messages à travers un unique nom (très expérimental)
  • attendre des propositions matterbridge/ConverseJS/xmpp-web plus détaillées et les configurer

Groupe de Travail Site Web

Suivis de la dernière réunion :

  • ouvrir une section blog sur le site web FAIT
  • publier le compte rendu de la première réunion, et l'annonce de notre collectif FAIT
  • ouvrir une section microblogging sur le site web, et donner l'accès au Groupe de Travail Media À FAIRE

TODO :

  • ouvrir une section microblogging sur le site web, et donner l'accès au Groupe de Travail Media
  • intégrer des ressources externes utiles
  • lister les salons existants sur une page : #chat, #sysadmin, #website, #translations, #bridging, #science
  • afficher "symbole de construction" partout, pour faire savoir à nos utilisateurices que tout est en cours et que les contributions sont les bienvenues

Groupe de Travail Traduction

Suivis de la dernière réunion :

  • traduire le compte rendu de la réunion #1 À FAIRE
  • traduire l'annonce du collectif : français FAIT
  • recruter plus de traducteur·ices

Notes depuis la dernière réunion :

  • il y avait un argument pour la traduction en français : devrions-nous utiliser la forme de genre neutre (inclusif), ou par défaut la variante française approuvé par l'état ?

TODO :

  • Recruter plus de traducteurices
  • Formuler une proposition pour une langue inclusive pour la prochaine réunion
  • Traduire le compte rendu des réunions #1 et #2

Groupe de Travail Pont

Suivis de la dernière réunion :

  • explorer les solutions de pont pour notre chat multi-utilisateurice : Matterbridge à été choisi FAIT
  • faire une proposition concrète pour le Groupe de Travail Sysadmin À FAIRE

Notes depuis la dernière réunion :

  • où héberger les comptes/salons Matrix ?
    • feneas.org : iels sont vraiement vraiment inquiét·es à propos de l'état de leur sysadmin, et du manque de contributions, donc iels ne recommande pas de dépendre d'elleux pour quoi que ce soi
    • aria-net.org (projet Metronome) : iels seraient heureux d'héberger un salon et un compte bot pour nous, et nous pouvons promouvoir leur gateway Bifrost XMPP <-> Matrix au public (Bifrost est toujours en beta)
  • où héberger les comptes/salons IRC ? Freenode ? OFTC ? ~chat ?
  • comment stocker et partager les identifiants utilisateurices ? voir Sécurité et identifiants plus loin dans l'agenda
  • matterbridge a été testé pour cette réunion (mais non hébergé par notre infra), relayant les discussions entre meeting@joinjabber.org et #joinjabber sur irc.tilde.chat ; ça semble très fonctionnel

TODO :

  • créer des comtpes matrix/IRC avec le mail de secours bridging@joinjabber.org
  • faire une proposition concréte pour le Groupe de Travail Sysadmin

Groupe de Travail Media

Suivis de la dernière réunion :

  • créer des comptes Mastodon et Movim, et partager les identifiants À FAIRE
  • obtenir les identifiants du Groupe de Travail Site Wbe pour publier dans la section microblogging du site web À FAIRE
  • considérer si on doit autohéberger notre propre instance Movim, et si oui voir avec le Groupe de Travail Sysadmin À FAIRE

Notes depuis la dernière réunion :

  • comment partager des identifiants au sein du Groupe de Travail Media ? voir Sécurité et identifiants dans l'agenda
  • un bot RSS vers ActivityPub (Mastodon) à été envisagé, plusieurs options trouvées
  • certains services nécessite un email de validation pour s'inscrire : media@joinjabber.org a été créé pour ça, et est un alias redirigeant vers les membres du Groupe de Travail Media

TODO :

  • créer des comptes sur Mastodon et Movim, et partager les accès
  • obtenir les accès du Groupe de Travail Site Web pour publier sur le site web dans la section microblogging
  • considérer si l'on doit autohéberger notre propre instance Movim, et si oui faire une proposition concréte au Groupe de Travail Sysadmin

Communication

Le point qui été prévu à propos de si on préfère utiliser Jabber ou XMPP pour faire référence à l'écosystème Jabber/XMPP à été reporté.

Ressources utiles

Quelles ressources externes voulons-nous montrer sur notre site web ? Quelques idées :

En plus, voici quelques bons endroits pour trouver des nouvelles sur Jabber/XMPP :

Les idées sur comment intégrer ces ressources au site web seront formulées par le Groupe de Travail Site Web. Elles peuvent êtres divisées en fonction de l'audience cible : utilisateurices finaux, administrateurices de serveurs, développeureuses de client/serveur.

Suggestions pour le site web

Quelques suggestions de la dernière réunion, et d'autres formulés depuis, que l'on devrait ajouter sur le site web :

  • tutoriels : fait dans Section tutoriels FAIT
  • FAQ : contributions bienvenues !
  • Guide pour contribuer

Il nous a été signalé que notre site web n'affiche pas de licence. Quelle licence devrions-nous adopter ? Une licence copyleft comme Creative Commons BY-SA semble bien, mais ce point spécifique est reporté à la prochaine réunion.

Il est demandé si nous devrions installer un logiciel de wiki (comme MediaWiki) sur notre serveur ; voici une liste des pour & contre :

  • + interface web simple pour contribuer sans connaissance de git
  • - encore une autre application à maintenir
  • - nous n'avons aucune service centralisé d'authentification, donc ça ferait plus d'identifiant/mot de passe à se souvenir pour les personnes (cependant une authentification tierce devrait marcher)
  • - redondant avec le site web qui est déjà comme un wiki (juste besoin d'un éditeur web)
  • - contrairement au site web (fichiers statiques), un wiki dynamique ne peut pas être redistribué sur des réseaux peer-to-peer (Bittorrent/IPNS/Freenet)

Comme alternative, nous pouvons :

  • utiliser les wiki de dépôts sur notre forge : cependant, cela rendrait plus difficile d'exporter l'information sur notre site web
  • utiliser l'éditeur web intégré de Gitea pour avoir des camarades moins-tech qui proposent des merge requests : cependant, Gitea n'a actuellement pas de "fork-and-edit" workflow comme le font Github/Gitlab

Aussi, il a été suggéré que nous pourrions trouver de l'inspiration pour le design sur les sites suivants :

Nous rappelons aux camarades que le projet JoinJabber est fait par des bénévoles, et que des webdesigner bénévoles sont bienvenus pour aider à améliorer notre site web.

Quelques remarques en plus on été collectés durant la réunion. Elles ont été ajoutés au À FAIRE du Groupe de Travail Site Web.

Sécurité et identifiants

Comment partager les mots de passe des comptes sociaux (et autres) ? Comment éviter les accès non-autorisés, tout en s'assurant que les mots de passes ne soient pas perdus avec le temps ? Pour les mots de passes utilisés par les bots/services, on peut les garder sur le serveur. Pour les mots de passe utilisé par des humains (ex : compte de media sociaux), ils peuvent être gardés dans les boîtes mails des contributeurices (pour le moment). On vient de mettre en place des alias sur notre système mail :

Ces alias redirigent les mails vers les membres des groupes de travail correspondants.

Il a été suggéré d'utiliser un gestionnaire de mots de passe partagé. Cependant, les camarades du Groupe de Travail Sysadmin ne sont pas content·e de devoir déployer encore un autre service avant que nous n'ayons un bon support des services existants. Il a été suggéré, comme alternative, que les mots de passe soient chiffrés via GPG pour les personnes qui en ont besoin.

Forums et listes mail

Nous utilisons actuellement Discourse comme forum, car c'est la seule solution que nous avons trouvé qui marche sans JavaScript dans le navigateur, et est aussi utilisable par mail. Cependant, tout n'est pas parfait avec lui :

  • Discourse supporte uniquement une seule baseURL pour chaque virtualhost, donc on ne peut pas servir le même forum a travers une adresse .onion (ticket)
  • L'installation de Discourse est supporté uniquement à travers un conteneur Docker, donc on doit créer un rôle Ansible pour supporter Discourse (ticket)
  • La stack mail de Discourse est très mauvaise (voir ticket au-dessus)
  • Discourse n'est pas basé sur le protocole XMPP : même si ce n'est pas une raison de ne pas l'utiliser, une solution basée sur Jabber/XMPP nous rendraient plus heureuxe
  • Discourse pourrait ne pas être des plus simple à utiliser avec l'authentification Jabber/XMPP, ou d'autres mécanismes d'authentification fédérés

Les solutions habituelles comme Mailman et Redmine ne s'appliquent pas car elles permettent seulement du forum ou liste mail, mais sont très mauvaises pour faire les deux à la fois. Trois solutions basées sur Jabber/XMPP ont été explorées pour remplacer le forum actuel :

  • Movim était plein de petits (insignifiants) bugs, et n'est clairement pas fait pour être utilisé comme forum (un mainteneur nous à dit de ne même pas essayer)
  • Salut-à-toi n'a pas encore été testé, mais semble mieux sur le papier, et le mainteneur à montré beaucoup d'intérêt à ce qu'on utilise son projet ; le forum sàt marche actuellement seulement via une interface web (libervia) ou d'autres front sàt (donc www + Jabber/XMPP), mais le mainteneur à déjà prévu d'implémenté le support mail complet
  • un chat standard multi-utilisateurices avec une interface web en lecture seule, avec fonctionnalité de recherche ; cette solution ne marche pas très bien car il n'y a aucun thread/categories (trouver l'information est difficile)

On va essayer de tester une instance de salut-à-toi pour la prochaine réunion, les personnes pourrons tester et collecter des retours pour le mainteneur du projet, qui est très intéressé d'avoir des retours du monde réel.

Planifier la prochaine réunion

Jusqu'à présent, nous avons demandé aux personnes de voter pour la date sur le forum. Cependant, ça nécessite de créer un compte pour voter, ce que certaines personnes ne veulent pas faire. On pourraient utiliser un système de vote publique comme framadate. Ça sera testé pour la prochaine réunion.

Aussi, jusqu'à présent la majorité du travail avant et après une réunion à été fait par une seule personne. Ça ne prend pas beaucoup de temps (2h avant la réunion, 2h après), et ne nécessite pas de compétences spécialisés (les typos sont ok, aussi). Idéalement plus de personnes seraient impliqués et personne n'aurait à le faire pour chaque réunion. Cette personne bénévole va toujours préparer la réunion suivante, mais va travailler sur un tutoriel sur comment organiser une réunion donc iel pourra être remplacer par n'importe qui.

Comment on annonce la prochaine réunion ? Actuellement, la même personne a plus ou moins spammé plein de salonsliés à jabber avec l'annonce de notre réunion. Quelques idées :

  • les sujets des salons chat@joinjabber.org & meeting@joinjabber.org FAIT
  • un salon dédié aux annonces ? (peut-être ennuyeux de rejoindre encore un autre salon) À FAIRE
  • compte de media sociaux du Groupe de Travail Media FAIT
  • un bandeau sur le site web, comme on a fait pour la première réunion ? FAIT

Est-ce que la réunion doit avoir lieux dans chat@ ou meeting@ ? Ça a du sens de diviser la discussions en plus petits salons, mais ça divise aussi une communauté déjà petite. Avoir un long débat comme une réunion dans chat@joinjabber.org ne serait surement pas très accueillant pour les nouvelles personnes, qui pourraient se sentir submergés d'informations et juste partir.

Quels collectifs et autres projets voudrions-nous inviter à notre prochaine réunion ? Comment on les joints ? Quel est notre message ? On pourrait faire un sondage pour avoir des retours de plus de développeureuses de client/serveur, et administrateurices de serveurs :

  • est-ce qu'iels aimeraient recevoir des informations/invitations à propos du projet JoinJabber ?
  • qu'est-ce qu'iels voudraient voir dans le projet JoinJabber ? Quels genre d'efforts peuvent être mutualisés ?
  • est-ce qu'iels voudraient apparaître sur la page d'accueil de JoinJabber ?
  • comment aimeraient-iels être présenté par notre collectif ? Quels genre de cas d'usage représente t-iels ?
  • Que font-iels pour la vie privée et la sécurité, si cela les intéresse ? qu'est-ce qui peut être amélioré ? pour quoi pourraient-iels avoir besoin d'aide ?
  • que font-iels pour les traductions ? qu'est-ce qui peut être amélioré ?

tofu et eevvoor vont faire une proposition complète basée sur ça, et la proposer publiquement dans le salon pour vérification.

Questions et réponses

Éviter de devenir un point central ?

Question : Comment évitons-nous de devenir une infrastructure central de l'écosystème ? Comment faisons-nous pour éviter de nous-même devenir un Point de Défaillance Unique, malgré notre offre de services pour de nombreux projets ?

Réponse : Pour le moment, on se concentre sur fournir de l'information uniquement donc la question n'est pas si pertinente. Cependant, nos objectifs disent que nous devrions proposer d'autres services à l'écosystème (ex. système de traduction, dépôts logiciels).

Dans le cas de certains services spécifiques (weblate, forums), nous devons nous assurer que notre infrastructure est par définition (du moment que c'est pratique) copiable à tout moment en suivant nos recettes d'adminsys. Ça devrait déjà être le cas. De plus, et comme spécifié par le RGPD, nous devrions permettre à tout membre/projet utilisant nos services d'exporter leurs données pour les déplacer ailleurs. Enfin, peut-être qu'on pourraient accepter uniquement d'héberger des services pour des projets qui ont leur propre domaine, donc ils resteraient indépendants dans le futur ?

Dans le cas des dépôts logiciels, c'est un problème plus dur. Au cas où notre infrastructure serait compromise, nous ne voulons pas finir par distribuer des malwares sur nos dépôts. À notre connaissance, seulement GNU guix peut étténuer ce problème en :

Financement participatif

Question : Planifions-nous de jouer un rôle actif dans le crowdfunding de fonctionnalités pour les client/serveur XMPP ?

Réponse : Oui, comme décidé dans nos objectifs de la dernière réunion. Nous ne lancerons pas nous-même de crowdfunding, mais pouvons annoncer ceux existants. Pour le moment nous n'avons reçu aucune proposition concrète de support de campagne de crowdfunding.

Expérience sur iOS

Question : Comment accueillir les utilisateurices iOS (avec des clients étranges à utiliser)?

Réponse : Est-ce que quelque chose ne va vraiment pas avec Siskin ou Monal ? Ce n'est pas juste une idée dépassée que les clients iOS sont mauvais ? S'ils vous -plaît donnez-nous des retours plus concrets.

Responsabilités lors de l'auto-hébergement

Question : Informez clairement les nouvelleaux (et les ancien·nes utilisateurices) de ce que signifie auto-héberger un serveur et la responsabilité à assumer en tant qu'administrateurice. Pour un aperçu de la manière dont les opérateurices peuvent abuser de leurs pouvoirs, voir cet article

Réponse : C'est vrai pour tout service proposé à des utilisateurices finaux, plus ou moins. Nous voudrions fournir aux opérateurices et utilisateurices finaux plus d'informations à ce sujet, comme pour la conformité RGPD. Les contributions sont bienvenues.

Dons

Question : Comment accepter les dons ?

Réponse : Nous n'acceptons pas l'argent comme dons, mais tout le monde est bienvenue pour donner du temps, de l'énergie et des idées. Vous pouvez aussi donner de l'argent ou des machines à notre hébergeur Fosshost ou à n'importe quel projet en amont et fournisseur service que nous recommendons.

Groupe de travail « Science »

Question : Il est proposé de considérer Jabber/XMPP comme plateforme pour les scientifiques, et avoir un cas d'usage dédié à ça sur notre site web.

Réponse : Un Groupe de Travail Science peut être créé dans le salon science@joinjabber.org, et une proposition plus concrète sera discuté durant la prochaine réunion.

Groupe de travail « École »

Question : Un Groupe de Travail École pourrait être créé pour promouvoir l'apprentissage à distance et les solutions de visioconférence comme Jitsi.

Réponse : Personne de présent à cette réunion ne veut lancer ça, mais certain·es seraient ravis d'accueillir de nouvelleaux contributeurices pour ça et peut-être participer dans le futur. Un guide en allemand existe déjà sur ce sujet. Nous pouvons inviter son auteur à rejoindre notre discussion.

Coopération multi-utilisateurice via XMPP

Pas vraiment une question, mais certains projets sont mentionnés pour la coopération multi-utilisateurices via Jabber/XMPP :

  • salut-à-toi comme forum et forge logicielle fédérée
  • saros pour du développement en temps réel jusqu'à 5 personnes
  • jsXC permet une intégration Nextcloud/Sogo pour le partage de fichiers & autres

Si certaines personnes veulent mentionner de tels cas d'utilisation sur notre site Web, tout en avertissant les utilisateurices finaux qu'iels sont de niche et potentiellement bogués, les contributions sont bienvenues.

Reporté

Recommandations de serveurs

Nous recommandons actuellement certains fournisseurs de services sur notre page d'accueil, cependant les critères d'inclusion ne sont pas clairs. On peut bien sur ajouter plus de fournisseurs, mais on craignait également que certains fournisseurs n'utilisent l'infame et hostile RECAPTCHA de Google, ou le tout aussi infame Cloudflare. Nous avons mentionné lors de la dernière réunion que nous aimerions établir des critères plus objectifs pour décider si nous souhaitons recommander un serveur.

En fonction du cas d'usage de l'utilisateurice, différents critères peuvent s'appliquer :

  • à but non lucratif : le fournisseur est une association à but non lucratif ou une coopérative de travail
  • pas de tiers : les services destinés aux utilisateurices n'incluent pas de ressources/appels à des tiers, comme des analytics, CAPTCHAs ou CDNs
  • facteur bus : le service est fournis par une ou plusieurs personne, avec des garanties en place au cas où un·e adminsys ne pourrait plus contribuer au projet
  • durabilité : le modèle économique est compréhensible, et il y a de la transparence sur les frais de fonctionnement et les dons
  • intimité : la politique de confidentialité est compréhensible par les utilisateurices et nous semble raisonnable (à interpréter)

En premier, nous devons décider quels cas d'usage nous voulons prendre en charge, puis nous déciderons quels critères spécifiques s'appliquent à chacun :

  • Personel : pour les amis et familles, avec une intimité raisonnable, mais une préférence pour la durabilité (le service devrait toujours être là dans 10 ans)
  • Collectif : pour collectifs et coopératives, fournissez votre propre domaine et administrez votre hôte virtuel, avec une préférence pour la durabilité et la fiabilité ; en plus, nous pouvons considérer qu'il est obligatoire pour ce cas d'usage de fournir une facture/un devis officiel pour les services
  • Pseudonyme : pour les militant·es, privilégiant la sécurité à la durabilité ; peut-être que ce cas d'usage peut être renommé (ex. "Activist Friendly")

Certaines listes existent déjà pour référencer des fournisseurs de services Jabber/XMPP :

De plus, certains programmes permettent la découverte/évaluation de services basés sur des tests logiciels :

Communications

Licence libre

Il a été singalé lors de notre deuxième réunion que nous n'avons pas encore de licence sur notre site web. Toute notre production doit absolument être copyleft.

joinjabber ou joinxmpp ?

  • Jabber est une marque déposée par Cisco et habituellement associé au vieux xmpp des années pré-2010 ou pire un chat Cisco d'entreprise interne que des personnes ont abandonnées pour Slack
  • XMPP mène est bataille difficile contre les personnes tech qui l'associent à une mauvaise expérience "Jabber" par le passé. Le XMPP moderne devrait donc se distancier autant que possible de l'ancien Jabber
  • joinjabber.org devrait rediriger vers joinxmpp.org et pas l'inverse comme actuellement
  • joinxmpp.org convient parfaitement à ce qu'il est, c'est-à-dire partager un lien qui explique xmpp moderne et ses clients, l'adoption réelle par les utilisateurices finaux est déterminée par les recommandations de clients et serveurs, pas vraiment par le protocole
  • Les personnes disent que Jabber est plus facile à retenir et à prononcer que XMPP