Goffi a écrit 1520 commentaires

Merci pour la dépêche.

Petites précisions pour le PinePhone, parce que ça ne me semple pas clair avec la dépêche alors que c'est mis en avant pour le Librem :

• on peut aussi le brancher à un écran + clavier + souris (ou autre périphériques USB) pour en faire un ordinateur de bureau avec le pack convergence. J'ai testé avec Manjaro/Plasma Mobile et ça fonctionne pas mal du tout (à quelques crashs près, ça n'est pas encore tout à fait stable).
• il y a des kill switchs aussi (interrupteurs pour couper caméra, micro, modem, etc.), ils sont placés sous la coque à côté de la batterie

Et surtout, une killer feature pour moi : il lance automatiquement un OS installé sur la carte SD externe. En d'autres termes, il suffit de mettre une carte SD pour tester un autre système (et les données sont enregistrées dessus).

En plus de cela la communauté est sympathique et très dynamique, et le développement logiciel avance très très vite. C'est utilisable en l'état contrairement on ce qu'on a pu connaître avec des prédécesseurs comme le Neo FreeRunner à l'époque (qui était une super machine quand même).

Bref pour moi c'est le téléphone idéal pour celles et ceux qui veulent développer sur OS libres (c'est d'ailleurs la raison pour laquelle j'en ai un, porter des logiciels sur les différents OS libres).

Et puis on peut lancer les mêmes logiciels que sur son ordi de bureau, c'est bien agréable (évidemment, avec beaucoup moins de puissance).

À noter aussi l'arrivée prochaine d'un accessoire clavier intégrant une grosses batterie, qui va transformer le téléphone en terminal GNU/Linux portable (une sorte de PDA).

Comme les autres, bravo et merci pour le boulot et la passion.

Vous faites partie de ces projets tenus par peu de personnes avec peu de moyens et qui tiennent malgré tout sur la longueur. Votre projet de lier création artistique avec développement libre est vraiment intéressant, et inspirant.

Merci aussi pour les contributions régulières notamment ici, et pour les commentaires autant techniques que sur ce qu'il se passe dans le monde libre artistique.

Dans une meilleure société vous devriez avoir les ressources pour vivre décemment, et ne pas tenir uniquement par la passion et les nerfs.

Exemple : un serveur FTP dans un réseau local utilisé pour partager des fichiers pour tout le monde, manque de bol, l'appliance qui ne supporte pas le https, et est trop vieille pour être mise à jour …

python3 -m http.server

Seulement voilà, tous ces protocoles ne sont supportés qu'à moitié. Il manque le chiffrement de bout-en-bout à Matrix par exemple.

Mais comment est-ce possible ? Je croyais que le fonctionnement monolithique de Matrix, à l'opposé des extensions de XMPP, rendait une fonctionnalité manquante impossible ! On m'aurait menti ?

Blague à part, c'est souvent le problème des clients multi-protocoles, difficile d'implémenter correctement des tonnes de protocoles. D'ailleurs côté XMPP aussi c'est critiqué pour une implémentation très en dessous de ce qu'on attend de nos jours.

À noter le project Snikket lancé par l'équipe de Prosody, qui est très prometteur.

https://snikket.org

Le projet fonctionne comme ça:

• auto-hébergé, installable en moins d'1/2 heure (avec des containeurs Docker)
• un client est choisi par plateforme (pour le moment Android avec Conversations et iOS avec Siskin)
• les fonctionnalités sont testées entre ces clients, tout problème est corrigé et proposé en amont (upstream)
• on parle de Snikket, pas de XMPP. Les clients sont renommés (« rebrandés » pour les marketeux) et c'est « Snikket » sur les dépôts d'applications
• système d'invitation
• les personnes invitées apparaissent automatiquement dans la liste de contacts (roster) des autres
• même si ça n'est pas présenté explicitement comme tel, c'est du XMPP donc les utilisatrices et utilisateurs avancé·e·s peuvent utiliser le client de leur choix

Bref, c'est idéal pour faire un réseau familial rapidement et facile d'accès, tout en laissant la possibilité d'utiliser ses clients favoris.

C'est en bêta, mais côté Android c'est Conversations qui est largement éprouvé, et côté iOS je pense que ça tourne bien aussi (à vérifier).

Ce projet mérite une dépêche d'ailleurs.

Ayant participé plusieurs fois à l'espace numérique de la fête de l'huma, j'ai été en contact avec lui et j'ai eu l'occasion de discuter avec lui. Une personne engagée et intéressante, ça fait mal au cœur d'apprendre qu'il est parti comme ça.

C'est grâce à lui que l'espace numérique de la fête de l'huma existait, j'espère qu'il continuera. C'est un de mes événements préférés, car on y rencontre un public différent de celui des événements libristes habituels. Merci à Yann d'avoir permis ça.

Mes sincères condoléances à sa famille, ses ami·e·s et camarades.

bon autant aller directement à l'origine : la nature le faisait encore avant

Quand on est capable d'inventer les rouleaux de glace on est un anglais original, pas un escroc.

Je ne sais pas si c'est antérieur, mais j'ai déjà vu ça en Slovaquie (et c'est pas terrible, ça vaut pas les glaces traditionnelles qu'on a quelques dizaines de mètres plus loin).

Tu dis toi même qu'il faut que les 2 clients implémentent les mêmes XEP, et au moins pour certaines,

Il me semble assez évident que pour une conversation audio ou vidéo, il faut que les clients supportent, quel que soit le protocole. Y'a vraiment besoin de préciser ça ?

Me semble difficile de commencer ta phrase par un simple "ça c'est faux" du coup.

Si ce qui est affirmé plus haut est faux, et je le démonte dans mon commentaire.

On est bien d'accord qu'en dehors des fonctions les plus basiques, il faut que tous les participants utilisent un client qui supportent des XEP, qui sont optionnelles …

J'aime bien comme ça a glissé de « toute la chaîne » à « tous les clients ». Évidemment que pour afficher de la vidéo, il faut que le client soit prévu pour.

Déjà mentionné plus haut, Prosody le fait (cf. conclusion).

non Prosody utilise une version hashée, en tout cas c'est ce qui est mis dans la configuration de base (si on omet l'option je ne sais pas, il faudrait vérifier les sources plus en détails et je n'ai pas le temps, mais cette page laisse entendre que c'est bien la version hashée qui est utilisée par défaut) : https://hg.prosody.im/0.11/file/tip/prosody.cfg.lua.dist#l127 . La page citée plus haut ne doit plus être à jour depuis longtemps, il faudrait sans doute leur remonter d'ailleurs.

Pour ejabberd je ne sais pas, à vérifier. Tu cites un ticket de plus de 2 ans qui pointe sur un fichier qui n'existe plus, c'est le code actuel qu'il faut regarder.

Enfin bref, ça sert à rien de tourner en rond, j'ai déjà répondu plus haut : oui il faut hasher les mots de passe, non le protocole n'incite pas à garder les mots de passe en clair, et oui la spec citée plus haut devrait être corrigée pour mettre ça plus en évidence.

• Les salons sont distribués sur tous les serveurs qui y participent. Il n'est donc pas possible de faire fermer un salon en supprimant un serveur qui l'hébergerait

Je ne pense pas qu'une réplication systématique soit une bonne chose pour beaucoup de raisons (maîtrise des données et ressources notamment), mais elle est très intéressante si elle est optionnelle.

Note qu'il est possible de le faire avec XMPP aussi (XEP-0282 et XEP-0289), mais c'est vrai que je ne connais aucune implémentation en pratique (je ne sais même pas trop ce que les XEPs valent, il faudrait regarder ça en détails). Aussi MIX (le nouveau protocole de chat en court d'élaboration/implémentation) devrait permettre aussi la réplication.

Enfin qu'on aime ou pas cette fonctionnalité, c'est vrai que Matrix le fait aujourd'hui, et XMPP en pratique non, reste à voir si c'est une fonctionnalité critique pour la personne qui choisi.

Par contre je crois me souvenir que le serveur principal de matrix était tombé il y a quelque temps, et que ça avait sacrément perturbé le réseau (à confirmer, je suis ça de très loin). Est-ce qu'en pratique la réplication permet vraiment de fonctionner sans accroc quand notre serveur principal tombe ?

• Le protocole est versionné au lieu d'avoir un cœur simpliste et toute une collection d'extensions optionnelles. C'est ce qui fait que XMPP ne marche pas dans le monde réel : pour pouvoir utiliser des fonctions élémentaires, il faut que toute la chaîne (ton client, ton serveur, le serveur de ton interlocuteur, le client de ton interlocuteur) supporte les mêmes XEP et que tout soit bien configuré. Comme c'est rarement le cas, et qu'il n'y a aucune façon de le garantir … On fini par ne plus l'utiliser pour envoyer des fichiers par exemple (puisque trop de risque que ça ne passe pas). Je parle même pas d'appels audio/vidéo. Avec Matrix, ça juste marche.

Ça c'est faux. Il y a très peu de fonctionnalités qui demandent que toute la chaîne implémente quelque chose (en fait je n'en vois aucune là tout de suite), excepté PEP qui est implémenté par absolument tout le monde (c'est nécessaire pour publier des infos comme des clefs publiques). L'audio vidéo peut fonctionner si uniquement les clients l'implémentent, le serveur ne fait que fournir une aide pour traverser les réseau difficiles, et même là il suffit qu'un des 2 serveurs implémente ce qu'il faut.

L'envoi de fichier marche à ma connaissance avec tous les clients et serveurs, ça fait combien d'années que tu n'as pas essayé ?

Matrix utilise justement XMPP pour les appels audio/vidéo (via Jitsi Meet qu'il embarque), sauf pour les appels 1:1 qui sont du webRTC (et là c'est les navigateurs qui font le boulot principal).

Et en pratique, combien de clients autres que le client principal de Matrix (Element) implémentent toutes les fonctionnalités ? Est-ce qu'il y a un seul client tiers qui le fait ? Ils ont exactement le même problème pour la même raison : c'est une question de ressource, et le client principal de Matrix avance bien parce qu'ils ont de l'argent pour payer des équipes de développement à plein temps (tant mieux pour eux), mais les clients tiers n'ont pas souvent les moyens de suivre au même rythme.

Tu parles d'une extension qui a été écrite en 2007, et qui n'a pas été touchée depuis 2010, à l'époque les mots de passe étaient stockés beaucoup plus souvent en clair, maintenant il y a des méthodes plus à jour, et je ne pense qu'il y ait beaucoup de serveurs qui gardent les mots de passe en clair. Et le principe d'un protocole ouvert comme XMPP, c'est qu'on peut justement pointer ce genre de problème et y répondre par une mise à jour de la spécification (ou une nouvelle qui va remplacer l'ancienne).

De la même façon un code libre n'est pas dépourvu de bugs ou failles de sécurités parce qu'il est libre, mais il y a plus de chance que quelqu'un voit le problème et le corrige.

Bref, bien sûr que le protocole n'est pas parfait, il ne doit pas y en avoir beaucoup qui le sont (on trouve des failles dans des protocoles bien plus utilisés que XMPP), mais on peut le corriger et le faire évoluer, et il y a de bon mécanismes pour ça.

Tous les avantages que tu cites pour XMPP se retrouvent dans le protocole Matrix.
Avec peut être en plus des passerelles vers pas mal d'autres solutions (dont signal, Slack,IRC,Telegram,etc)

Il y a des passerelles avec XMPP aussi, et je doute qu'il existe beaucoup de protocoles qui ont un « bridge » Matrix et pas de passerelles XMPP. En tout cas pour Signal, Slack, IRC et Telegram ça existe.

Le problème de XMPP du point de vue utilisateur lambda, c'est qu'il faut faire, au minimum, 2 choix :
- le logiciel à utiliser (et il y en a pléthore)
- le serveur sur lequel sera héberger notre compte (et potentiellement, pour les plus geek, installer ce-dit serveur).

Ce sont 2 questions de trop pour la plupart des gens. Quand on leur dit, je suis sur Signal, rejoins moi, les gens ne se posent pas la question de savoir quel logiciel installer, ni où créer leur compte. C'est "naturel".

Avec Signal aussi tu choisis un logiciel (Signal), et un serveur (le serveur officiel de Signal), la seule différence c'est que tu l'imposes aux autres.

XMPP est un protocole qui te permet de choisir un logiciel est un serveur, ça ne veut pas dire que chaque utilisateur doit le faire, il y a des projets qui le font pour toi. C'est le cas de Snikket par exemple où le serveur est déjà choisi par la personne qui invite, et les clients sont déjà choisis aussi. La différence avec Signal, c'est que je peux communiquer avec eux avec le serveur et le client de mon choix.

Mais malheureusement, de plus en plus mes contacts chiffrent leurs messages avec OMEMO, bien souvent sans le savoir, juste parce que c'est activé par défaut dans Conversations.

C'est gênant quand son client ne le gère pas encore, mais je ne dirais pas « malheureusement », c'est une très bonne chose (même s'il y a redire sur beaucoup de points, le mouvement général va dans le bon sens).

Sinon le frontal TUI de Libervia (ex. Salut à Toi) que je développe gère aussi OMEMO (en 1:1, groupe et pour les fichiers). Et accessoirement, je suis ouvert au suggestions pour améliorer l'interface.

Et Poezio est un très bon client, et il me semblait que OMEMO était en cour d'implémentation dedans (mathieui tu peux confirmer ou infirmer ?).

Un autre oublié est Libervia (ex. « Salut à Toi », le projet est en train d'être renommé).

Il y a plusieurs frontaux, voici quelques captures :

Cagou (Libervia sur bureau et mobiles):

Libervia-web:

Primitivus (Libervia TUI):

Techniquement, peuvent-il vraiment empêcher les implémentations alternatives tout en fournissant des clients open source ? Dans tous les cas, mon but étant principalement éducatif, je n'aurais pas tout perdu. Puis j'aurais une base pour écrire une passerelle vers le prochain service de messagerie à la mode.

Je ne suis pas juriste, mais je pense que ça a plus à faire avec les conditions d'utilisations du service qu'avec la licence tu logiciel. Pour l'utilisation de "signal" dans le nom, c'est très probablement déposé. Après c'est toujours utile pour toi et c'est possible que tout passe sans problème (depuis combien d'année existe signald ?). Si ça n'est pas le cas, tu pourras voir quoi faire à ce moment (mais il y a effectivement le risque que ton projet ne puisse plus être utilisable, mais tu ne serais alors pas le seul dans ce cas).

Merci aussi pour tes conseils sur les tests, je vais regarder du côté de unittest.mock que je ne pratique pas du tout. J'aime bien l'idée de favoriser la bibliothèque standard quand c'est possible.

mock c'est principalement pour simuler un objet nécessaire dans une méthode que tu veux tester (par exemple ta méthode appelle signald, tu remplaces par un mock et tu peux vérifier que la méthode voulue, a été appelée avec les bon paramètres).

Salut,

merci pour ton travail, c'est bien de voir quelqu'un motivé au point d'écrire sa propre passerelle. Par contre l'organisation derrière signal (ex. Open Whisper Systems, maintenant c'est Signal Technology Foundation) est connue pour ne pas aimer les implémentations non officielles sur leurs serveurs (cf. LibreSignal), donc c'est possible qu'un jour ils causent du tort à signald et donc ton travail.

Pour les passerelles, le logiciel sur lequel je travaille (Libervia/Salut à Toi) permet aussi d'en écrire en Python asynchrone, mais ça manque également de documentation à l'heure actuelle. Spectrum2 est probablement la solution la plus connue, et c'est bien que l'auteur t'aie répondu.

Les tests de bout en bout c'est effectivement risqué dans ce genre de cas parce que tu peux te faire bannir de Signal, et puis ça peut être compliqué à mettre en place (il faut mettre tous les serveurs en route, attendre qu'ils soient dispo, etc.).

Par contre tu peux faire des tests unitaires, c'est à dire vérifier que tes méthodes ont le comportement attendu. Par exemple tu peux écrire une entrée type de ce que ta passerelle attendrait d'un client XMPP, et vérifier que ça se traduit correctement en la requête que tu vas faire à signald. Jette un œil à pytest qui est très populaire, et permet d'écrire des tests avec de simples assert. Tu pourrais aussi t'intéresser au module mock de la bibliothèque standard, c'est très utile et une fois que tu as compris le truc, ça devrait de permettre de tester facilement.

En tout cas bonne continuation, et merci de contribuer à XMPP.

Les derniers mots qu'il aurait dit c'est « chérie ça va couper ».

je suppose que ça signifie que https://gitlab.com/signald/signald (et donc le plugin libpurple qui se base dessus, et les passerelles comme celle de XMPP ou Matrix) ne sont pas autorisés, n'est-ce pas ?

C'est pas beaucoup mieux que whatsapp au final (ça reste un peu mieux quand même).

Salut,

Signal est un silo centralisé, mais il reste mieux que la plupart des autres silos, et en tout cas mieux que WhatsApp car le client et le serveur sont libres, et ça n'est pas affilié (du moins à ma connaissance) à Facebook ou autre entreprise qui font leur beurre sur les données personnelles.

Je copie ce que j'ai publié ce matin sur Mastodon :

Pour rappel, Signal c'est centralisé et fier de l'être cf. https://signal.org/blog/the-ecosystem-is-moving/ (et quelques réponses de la communauté XMPP: https://blog.jabberhead.tk/2019/12/29/re-the-ecosystem-is-moving/ ou https://gultsch.de/objection.html).

Ils se sont aussi déjà montrés hostiles envers de implémentations alternatives (cf. https://github.com/LibreSignal/LibreSignal/blob/master/README.md).

Alors oui ils ont fourni Double Ratchet et c'est mieux que la plupart des autres silos, mais c'est à garder en tête quand on le recommande pour remplacer whatsapp.

Pour moi, c'est décentralisation !

Bien entendu je ne suis pas neutre étant un développeur XMPP.

je ne suis pas ça de près du tout, mais j'ai vu passer des articles sur des projets européen :

• https://www.eetimes.eu/eu-signs-e145bn-declaration-to-develop-next-gen-processors-and-2nm-technology/

• https://fr.wikipedia.org/wiki/European_Processor_Initiative

Voilà, après je laisse ceux qui connaissent le domaine commenter :)

Pour la petite histoire, Metronome a été intégré dans Yunohost parce qu'il a été à un moment poussé par Jappix et Movim * (Movim avait des problèmes à l'époque avec Ejabberd, et le composant Pubsub de Prosody perdait tout au redémarrage).

Metronome est un fork de Prosody, maintenu par une seule personne (à l'origine pour un jeu il me semble, mais je n'en suis pas sûr du tout). Le problème c'est qu'il n'a pas été maintenu pendant longtemps.

Entre temps le Pubsub de Prosody s'est nettement amélioré, je ne sais pas pourquoi Yunohost n'a pas rebasculé dessus (ou sur un autre serveur, Ejabberd, OpenFire, Tigase, ou autre).

Le développeur de Metronome avait repris la maintenance la dernière fois que je m'y suis intéressé, je ne sais pas ce qu'il en est aujourd'hui (mais je pense que Prosody évolue beaucoup plus vite et régulièrement).

Pour répondre à ta question: oui le mauvais score est probablement dû à l'utilisation de Metronome ou au moins à une mauvais configuration de celui-ci.

* SàT avait les même contraintes à l'époque, mais le choix a été fait de développer un composant pubsub complet et utilisable avec tous les serveurs (SàT Pubsub, encore actif et développé aujourd'hui) plutôt que de pousser un serveur en particulier.

je crois que Gajim, qui avait la vidéo il y a quelques années mais n'a pas maintenu le code, et en train de travailler à remettre ça en état.

Dino a eu une subvention pour implémenter la vidéo aussi.

Ça fait environ 30 ans que trum l'Amiral Benson avait prévenu pourtant: https://invidious.fdn.fr/watch?v=dDV5x14TVdY