Sommaire
Préambule
Récemment, wazzzzaaaaap a perdu pas mal d'utilisateurs dans mon entourage proche.
J'aurais aimé avoir la puissance de tweet de l'ami Elon pour conseiller à tout le monde de migrer vers XMPP, mais je n'ai ni fanclub ni compte twitter, donc ça commençait mal… [*] Cependant, Signal étant open source, on devrait pouvoir trouver un moyen pas trop alambiqué de communiquer avec ses utilisateurs via XMPP, non ?
La réponse est oui, en théorie. Il existe en effet un plugin libpurple pour signal et un logiciel nommé spectrum pour faire des passerelles XMPP/libpurple.
Malheureusement tous les plugins libpurple ne fonctionnent pas toujours très bien avec, et chez moi ça a pas marché. Bien incapable de comprendre et déboguer le bousin, j'ai décidé d'essayer d'implémenter ma solution avec ce que je connais (c'est-à-dire python), profitant de l'occasion pour apprendre à programmer un poil moins mal.
Pas taper SVP
Coder est un hobby pour moi, et j'apprends sur le tas, donc c'est très rudimentaire et la qualité de code n'est pas au rendez-vous, mais je partage avec vous aujourd'hui mon petit bébé : spectrum2_signald.
Détails techniques
Signald
C'est basé sur signald, un client Signal non officiel sous forme d'un daemon.
On communique avec par un socket UNIX, c'était une bonne occasion pour moi d'enfin comprendre pourquoi et comment async/await en python, et de ce côté, je suis content de moi. J'ai compris comment on pouvait rapidement se retrouver dans l'enfer des callbacks et ma sous-mission est donc réussie: je comprends à quoi correspondent ces event_loops, coroutines et autres Futures qui ne me semblaient jusqu'à présent être là que pour m'empêcher d'utiliser des bibliothèques qu'elles avaient l'air bien mais qu'elles faisaient trop peur avec leur asyncio.
Il y a bien une bibliothèque python qui avait l'air de faciliter la communication avec signald, mais en fait elle est très limitée. Le module signald que j'ai écrit m'a l'air aujourd'hui plus avancé et j'ai contacté les auteurs de pysignald pour savoir si ça les intéressait de joindre nos forces.
Signald est en développement actif et l'API est pas très très bien documentée et cohérente, mais je ne regrette pas mon choix. Je pense que ça va aller en s'améliorant!
Spectrum
J'ai été surpris dans mes recherches de trouver assez peu de solutions qui permettent de facilement écrire une passerelle XMPP.
Slixmpp m'avait l'air d'un bon choix, mais il nécessite une connaissance des XEP un peu trop bas niveau pour mes compétences, c'est pourquoi j'ai décidé d'écrire la passerelle comme un backend spectrum2 (spectrum2_purple_backend est un autre exemple de backend pour spectrum2).
Spectrum2 est mal documenté, mais j'avais déjà discuté avec le mainteneur principal, donc je me suis dit qu'il m'aiderait à m'en sortir, et ça a été le cas. J'avais un point de départ qui m'a bien motivé: des bindings python (presque) tout prêts.
Contribuer à la doc de spectrum2 est quelque chose que je dois faire dans un avenir proche, car une partie est obsolète, et je me suis pris la tête pour arriver à correctement communiquer avec.
Ce qui va
Si vous êtes intéressés par cette passerelles, elle permet déjà de communiquer avec les utilisateurs signal, en messages privés et en groupes, avec un support pour les pièces jointes et la synchronisation des messages entre les clients (officiels ou non).
Ce qui ne va pas
Beaucoup de choses. N'hésitez pas à tester et me faire des retours de bugs, ou à me signaler les énormes défauts de conception qui m'auraient échappé.
Des tests, c'est quoi ?
Malgré la présence d'un répertoire tests dans le dépôt git, il n'y a pas de tests. Je ne sais pas en écrire car je n'ai jamais fait ça (un hobby, je vous le rappelle), et en plus je pense que la nature du projet ne rend pas les tests triviaux à écrire. En effet, pour tester il faudrait un serveur XMPP, signald, spectrum, un client XMPP, et surtout un plusieurs comptes signal. J'ai réussi à faire bannir mon numéro de téléphone temporairement (too many requests) pendant que j'ai écrit les lignes de code que je partage avec vous aujourd'hui alors je ne sais pas trop comment je devrais m'y prendre.
Qualité de code
J'ai deux grosses classes qui font tout et qui sont assez peu commentées. J'ai essayé de choisir des noms pas trop cryptiques pour mes méthodes et j'ai commencé à écrire des docstrings, mais ce n'est pas encore ça.
Sécurité
En l'état actuel, ce n'est pas du tout adapté à être déployé comme une passerelle ouverte à plusieurs utilisateurs. En effet, il faudra attendre la prochaine version de spectrum2 pour empêcher n'importe quel JID d'utiliser n'importe quel numéro de téléphone déjà enregistré sur signald et il faudra que je comprenne comment supprimer un compte de signald lorsque l'utilisateur se désinscrit de la passerelle pour éviter des attaques un peu trop faciles.
Cependant, l'ensemble des gens potentiellement utilisés par cette passerelle et l'ensemble des gens qui ont leur propre serveur XMPP sont probablement égaux, donc je me dit qu'il y aura peut être du monde intéressé ici…
Conclusion
Voilà voilà, j'ai écrit un bout de code, j'ai appris des choses en python et programmation asynchrone, j'ai communiqué avec des inconnus sur des MUCs et canaux IRC, et peut-être vous allez vouloir m'aider à faire mûrir tout ça avec vos suggestions.
[*] J'ai quand même réussi à faire migrer pas mal de potes et de famille sur XMPP grâce à l'excellent et utilisateur-amical Conversations, mais il faut bien avouer que pour les utilisateur de la marque à la pomme, ça n'est pas encore ça…
# bonne initiative
Posté par Goffi (site web personnel, Mastodon) . É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.
[^] # Re: bonne initiative
Posté par Nicoco (site web personnel) . Évalué à 6.
Merci beaucoup pour ce commentaire encourageant.
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.
En fait, j'espère aussi faire de la promo à XMPP avec ce genre d'outils : la plupart de mes potes aiment bien l'idée d'avoir tous les services de messagerie dans un seul et même client. Bon dans les faits, je suis le seul à utiliser mes passerelles, mais je décide d'y croire quand même.
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.
[^] # Re: bonne initiative
Posté par Goffi (site web personnel, Mastodon) . É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).[^] # Re: bonne initiative
Posté par Nicoco (site web personnel) . Évalué à 2.
Ha oui, le nom… Mais c'est aussi une marque de dentifrice non ? Je compte me défendre comme ça, on verra bien. Ils sont un peu enquiquinant ces gens à faire du pseudo-libre quand même. Déjà qu'ils ne veulent pas être sur F-Droid ou enlever les dépendances aux services Google. J'ai un peu du mal à comprendre la philosophie qui guide tout ça.
[^] # Re: bonne initiative
Posté par Anonyme . Évalué à 2. Dernière modification le 27 janvier 2021 à 14:53.
Sans déconner, y a juste à aller sur le dépôt de signald pour comprendre pourquoi :
[^] # Re: bonne initiative
Posté par Nicoco (site web personnel) . Évalué à 3.
Sans déconner ? Je parlais surtout de la dépendance aux services Google et de leur refus de collaborer avec F-Droid.
Pour signald, je pense qu'ils écrivent principalement ça pour se protéger légalement, non ? On peut même imaginer que si signal n'était pas si réticent à l'idée de clients alternatifs, ils pourraient faciliter les implémentations aussi sûres que les siennes ?
Pour ma part, je trouve vraiment paradoxal de mettre en avant la sécurité et la vie privée, tout en recommandant d'avoir les services Google Play sur son téléphone.
[^] # Re: bonne initiative
Posté par Anonyme . Évalué à 7.
Pour F-Droid, Moxie considère que les mises à jour automatiques en arrière plan sont une bonne chose et qu’elles rendent l’écosystème plus sûre. Il considère même que l’écosystème des OS de smartphones est plus sûr que celui des OS desktop.
Je pense qu’il a tort et qu’il est borné, mais à la limite c’est son choix.
Tu peux toujours télécharger l’APK via leur site web et si tu veux Signal via F-Droid, il y a des dépôts alternatifs qui servent l’APK officiel sans modification.
Pour GCM, tu inverses complètement : la majorité des utilisateurs ont les GApps installées, ça ne demande absolument aucune configuration (pas d’optimisation de la batterie, de permissions en plus ou quoi que ce soit) et ça juste marche (et au passage, ça n’a aucun impact sur ta vie privée dans Signal).
Tu peux utiliser Signal sans GCM (je le fais), il va ouvrir une websocket avec leurs serveurs (donc consommer plus de batterie), afficher une notification permanente, te demander de désactiver manuellement l’optimisation de la batterie pour Signal (sinon ça marche pas), etc.
Mets toi à leur place, c’est quoi le mieux si tu veux que ton applications soit adopté par le plus de personnes possible (ça veut dire même ton grand-père de 80 ans) ?
Bah non, regarde, on t’a fait les mêmes remarques sur HN : y a plus de E2EE avec ta passerelle, ça la rend moins sûr que d’utiliser l’application sur Android (même avec GCM :D).
Au passage, l’auteur explique pourquoi il dit ça : signald/signald#101
Imaginer on peut toujours.
# GG
Posté par xouillet . Évalué à 6.
Oh bien ! Merci beaucoup !
J'avais essayé aussi
purple-signaldavecspectrummais c'est clairement pas tout à fait au point et pas facile à débugger. Je vais tester ton projet dès que j'ai un moment, ça à l'air d'être la bonne approche.[^] # Re: GG
Posté par Nicoco (site web personnel) . Évalué à 5.
Merci beaucoup pour les encouragements.
Je pense qu'une passerelle directement pour XMPP serait une encore meilleure approche, mais spectrum m'a fait gagner du temps je pense, car je pars d'un niveau très très bas en génie logiciel (ou un truc du genre, je ne sais pas comment on doit l'appeler).
Purple-signald est censé fonctionner, mais de ce que j'ai compris, c'est un peu la jungle du côté de libpurple et vraiment hors de portée en un temps raisonnable pour moi à appréhender. À l'inverse, tdlib-purple pour Telegram fonctionne très bien pour moi via spectrum. Je n'en ai pas une utilisation avancée, je suis content qu'on puisse me joindre par là. Je n'aime pas écrire sur le clavier des smartphones.
Prépare toi à des plantages dans tous les sens, mais bon c'est un des avantages de spectrum, généralement il relance le "backend" et on ne s'en rend même pas compte. Je suis preneur de tout retour, rapport de bug, conseil sur l'organisation du code etc., n'aie pas peur de me vexer. ;)
# La classe
Posté par Fopossum . Évalué à 7.
Je suis pas codeur du tout donc je ne vais pas pouvoir aider sur le coup.
Mais j'ai juste envie de dire bravo et c'est la classe de faire ça, d'autant plus en tant que hobby, et ce quelle que soit la qualité du code :-)
Longue vie au projet, et espérons qu'il puisse amener du bon pour tout le monde.
cd /pub && more beer
[^] # Re: La classe
Posté par Nicoco (site web personnel) . Évalué à 2.
Bon j'ai un peu exagéré, je "code" pour mon boulot. Mais le hobby c'est d'essayer de faire du code que d'autres pourront utiliser. Habituellement je fais des simulations numériques, en gros des scripts dégueus dont le but n'est pas du tout la pérennité ou la ré-utilisabilité. Merci pour tes encouragements !
# re la classe ++
Posté par Anonyme . Évalué à 10.
tu fais même une apparition sur HackerNews :) !
[^] # Re: re la classe ++
Posté par Nicoco (site web personnel) . Évalué à 3.
Ha ! Je comptais communiquer du côté anglophone lorsque ça serait un peu plus mature, merci de me le signaler, je vais aller essayer de répondre aux commentaires là bas aussi.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.