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 ?).
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).
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.
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).
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 :
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.
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.
L’équipe (quelques membres de l’équipe, dans le bassin ou au petit coin coin, n’ont pu être photographiés) :
pan ! pan !
(et aussi s/Nonne/Bonne/ mais je pense que tout le monde avait compris que je ne parlais pas des Nonnes Troppo, même si je leur souhaite une bonne année aussi).
Nonne année et merci aussi à toutes celles et tous ceux qui maintiennent ce site et ce qui va autour depuis tant d'années, malgré les commentaires pas toujours agréables et les ennuis parfois même judiciaires. Ce site est une référence par la qualité de son contenu (et souvent, mais pas toujours, des commentaires).
C'est quand même impressionnant de voir tout ce qu'a fait Gee depuis le geektionnerd : des articles, des albums, des peintures, des musiques, des essais, des animations, des jeux. Et toujours sous licence libre, chapeau !
J'ai regardé très vite fait la démo, ça a l'air bien sympa. Et faire tout tout seul (sans même utiliser un moteur existant apparemment), ça doit demander un temps assez fou.
Je me demande comment il gère son emploi du temps, et s'il arrive à vivre de tout ça, ou s'il a un boulot à plein temps (il me semblait qu'il enseignait à Nice à un moment). D'ailleurs si tu nous lis Gee, peut-être que tu peux répondre directement ^
En tout cas bravo pour tout ça.
Ah, et vu que je fais mon premier commentaire de l'année : bonne année à tou·te·s
D'autre part, je cherche aussi un guide qui retrouve les infos à jour pour se faire enlever de ces liste, comme par exemple le lien pour hotmail (cf. mon message ci-dessous).
Bref, j'aimerais trouver un guide maintenu à jour avec ce genre d'informations, ça faciliterait la tache.
Pour ce qui est de recevoir des spams, sauf à parler des filtres anti-spam des grosses boîtes genre Free/Orange qui analysent les boîtes mails des clients pour faire des stats…, ça n'a rien à voir avec l'auto-hébergement.
Les grosses boîtes peuvent certes avoir des stats plus importantes (notamment savoir si un message particulier est mis à la poubelle/en spam par beaucoup de monde), mais je ne vois pas en quoi ça serait incompatible avec l'auto-hébergement. SpamAssassin et Bogofilter sont des outils disponibles par exemple.
Faut juste faire attention de ne pas donner son adresse email à n'importe qui / n'importe quel site.
J'ai la même adresse depuis à peu près 20 ans, et elle est publique notamment sur le code ou les documents techniques que je publie. Bien que j'utilise des alias uniques pour tout ce qui pourrait éventuellement fuiter les adresses (plus par soucis de retrouver d'où ça vient qu'autre chose), la plupart des spams que j'ai sont à mon adresse principale.
Pour ce qui est de l'envoi des mails en auto-hébergement, c'est plus complexe, car il faut vraiment tout mettre en place de A à Z et tout configurer comme il faut : IP fixe, reverse DNS, SFP, DKIM, DMARC,
Je suis au courant de ça, mais ça ne répond pas à ma question. Ma question c'est « Est-ce qu'il existe un guide à jour avec les configurations à faire, les extensions à mettre en place, les adresses/sites à contacter pour que son courriel passe correctement ? »
Pour ma part je gère mes courriels depuis des années, mais je n'ai plus vraiment le temps de m'occuper sérieusement de l'administration, et effectivement j'ai beaucoup de spam et mes propres messages finissent souvent en spam aussi.
Est-ce qu'il existe un guide à jour des bonnes pratiques ? Notamment qui liste les méthode à utiliser pour vérifier si on est sur une liste noire quelconque ? Et aussi les extensions à activer, les outils de lutte contre le spam moderne, etc. J'en suis resté à SpamAssassin principalement, est-ce qu'il y a des alternatives intéressantes ou des outils pour compléter ?
[^] # Re: Matrix vs XMPP
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Messagerie instantanée : ce n’est pas une question d’applications. Évalué à 4. Dernière modification le 02 février 2021 à 15:57.
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 ?
Si ce qui est affirmé plus haut est faux, et je le démonte dans mon commentaire.
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.
[^] # Re: Configuration serveur et écosystème de clients
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Messagerie instantanée : ce n’est pas une question d’applications. Évalué à 4.
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.
[^] # Re: Matrix vs XMPP
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Messagerie instantanée : ce n’est pas une question d’applications. Évalué à 7. Dernière modification le 02 février 2021 à 13:40.
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 ?
Ç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.
[^] # Re: Configuration serveur et écosystème de clients
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Messagerie instantanée : ce n’est pas une question d’applications. Évalué à 5.
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.
[^] # Re: XMPP ou Matrix ?
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Messagerie instantanée : ce n’est pas une question d’applications. Évalué à 5.
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.
[^] # Re: Mauvaise question...
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Messagerie instantanée : ce n’est pas une question d’applications. Évalué à 7.
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.
[^] # Re: mcabber (ou profanity ?)
Posté par Goffi (site web personnel, Mastodon) . En réponse au sondage Quel est selon vous le client XMPP à l'interface la plus adaptée pour une équipe soudée de gens inconnus?. Évalué à 3.
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 ?).
# Libervia (ex. Salut à Toi)
Posté par Goffi (site web personnel, Mastodon) . En réponse au sondage Quel est selon vous le client XMPP à l'interface la plus adaptée pour une équipe soudée de gens inconnus?. Évalué à 10.
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):
[^] # Re: bonne initiative
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Ma passerelle XMPP/Signal. Évalué à 5.
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).mockc'est principalement pour simuler un objet nécessaire dans une méthode que tu veux tester (par exemple ta méthode appellesignald, tu remplaces par un mock et tu peux vérifier que la méthode voulue, a été appelée avec les bon paramètres).# bonne initiative
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Ma passerelle XMPP/Signal. Évalué à 10.
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.
# derniers mots
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Jean-Pierre Bacri bronsonisé.... Évalué à 8.
Les derniers mots qu'il aurait dit c'est « chérie ça va couper ».
[^] # Re: Centralisation
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Signal la bonne alternative à Whatsapp ?. Évalué à 3.
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).
# pas idéal, mais mieux que d'autres silos
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Signal la bonne alternative à Whatsapp ?. Évalué à 10.
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 :
Bien entendu je ne suis pas neutre étant un développeur XMPP.
[^] # Re: indépendance numérique
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Trois processeurs, trois processus. Évalué à 5.
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 :)
[^] # Re: Yunohost, XMPP et Jitsi
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal XMPP en 2021. Évalué à 6.
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.[^] # Re: Audio / Video
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal XMPP en 2021. Évalué à 8.
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.
[^] # Re: ça interpelle différemment
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Trump == Hitler. Évalué à 1.
Ça fait environ 30 ans que
truml'Amiral Benson avait prévenu pourtant: https://invidious.fdn.fr/watch?v=dDV5x14TVdY[^] # Re: bonne année à tou.te.s
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Bonne année 2021 !. Évalué à 3. Dernière modification le 02 janvier 2021 à 17:18.
J'allais oublier:
pan ! pan !
(et aussi s/Nonne/Bonne/ mais je pense que tout le monde avait compris que je ne parlais pas des Nonnes Troppo, même si je leur souhaite une bonne année aussi).
[^] # Re: bonne année à tou.te.s
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Bonne année 2021 !. Évalué à 3.
ah ah, merci pour le subtil rappel, je ne les ai pas oubliées, elle paraîtront 2021, une bonne résolution ;)
# bonne année à tou.te.s
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Bonne année 2021 !. Évalué à 8.
Nonne année et merci aussi à toutes celles et tous ceux qui maintiennent ce site et ce qui va autour depuis tant d'années, malgré les commentaires pas toujours agréables et les ennuis parfois même judiciaires. Ce site est une référence par la qualité de son contenu (et souvent, mais pas toujours, des commentaires).
# impressionnant
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Démo de Superflu Riteurnz. Évalué à 5.
C'est quand même impressionnant de voir tout ce qu'a fait Gee depuis le geektionnerd : des articles, des albums, des peintures, des musiques, des essais, des animations, des jeux. Et toujours sous licence libre, chapeau !
J'ai regardé très vite fait la démo, ça a l'air bien sympa. Et faire tout tout seul (sans même utiliser un moteur existant apparemment), ça doit demander un temps assez fou.
Je me demande comment il gère son emploi du temps, et s'il arrive à vivre de tout ça, ou s'il a un boulot à plein temps (il me semblait qu'il enseignait à Nice à un moment). D'ailleurs si tu nous lis Gee, peut-être que tu peux répondre directement ^
En tout cas bravo pour tout ça.
Ah, et vu que je fais mon premier commentaire de l'année : bonne année à tou·te·s
# Condoléances
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal pankkake bronsonisé. Évalué à 10.
On ne se connaissait pas vraiment, mais on s'était croisés plusieurs fois. On n'imagine pas ce que peuvent traverser les gens.
Condoléances à sa famille et à ses amis.
[^] # Re: Autohébergement
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Linux ne m'intéresse plus. Évalué à 3.
Ah c'est intéressant ça merci.
Pour vérifier si on est sur liste noire, je connais au moins https://mxtoolbox.com/blacklists.aspx .
D'autre part, je cherche aussi un guide qui retrouve les infos à jour pour se faire enlever de ces liste, comme par exemple le lien pour hotmail (cf. mon message ci-dessous).
Bref, j'aimerais trouver un guide maintenu à jour avec ce genre d'informations, ça faciliterait la tache.
[^] # Re: Autohébergement
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Linux ne m'intéresse plus. Évalué à 4.
Les grosses boîtes peuvent certes avoir des stats plus importantes (notamment savoir si un message particulier est mis à la poubelle/en spam par beaucoup de monde), mais je ne vois pas en quoi ça serait incompatible avec l'auto-hébergement. SpamAssassin et Bogofilter sont des outils disponibles par exemple.
J'ai la même adresse depuis à peu près 20 ans, et elle est publique notamment sur le code ou les documents techniques que je publie. Bien que j'utilise des alias uniques pour tout ce qui pourrait éventuellement fuiter les adresses (plus par soucis de retrouver d'où ça vient qu'autre chose), la plupart des spams que j'ai sont à mon adresse principale.
Je suis au courant de ça, mais ça ne répond pas à ma question. Ma question c'est « Est-ce qu'il existe un guide à jour avec les configurations à faire, les extensions à mettre en place, les adresses/sites à contacter pour que son courriel passe correctement ? »
Il y avait eu un article de blog de Framasoft il y a quelques années qui était intéressant sur le sujet, ce que j'aimerais avoir, c'est la même chose en guide maintenu à jour. Par exemple l'adresse pour se faire enlever de la liste noire de hotmail (indiquée dans ce billet de blog), il faut la connaître.
Bref si ce genre de guide n'existe pas, ça serait très utile. Si ça existe, j'aimerais bien avoir un lien.
[^] # Re: Autohébergement
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Linux ne m'intéresse plus. Évalué à 4.
Pour ma part je gère mes courriels depuis des années, mais je n'ai plus vraiment le temps de m'occuper sérieusement de l'administration, et effectivement j'ai beaucoup de spam et mes propres messages finissent souvent en spam aussi.
Est-ce qu'il existe un guide à jour des bonnes pratiques ? Notamment qui liste les méthode à utiliser pour vérifier si on est sur une liste noire quelconque ? Et aussi les extensions à activer, les outils de lutte contre le spam moderne, etc. J'en suis resté à SpamAssassin principalement, est-ce qu'il y a des alternatives intéressantes ou des outils pour compléter ?