Goffi a écrit 1556 commentaires

Salut et merci pour le journal,

ce téléphone m'intéresse particulièrement pour porter des applications sur les différents OS, aussi je me demande s'il est possible de passer d'un OS à l'autre facilement. Je crois que c'est possible de booter depuis une carte SD, et qu'il y avait un projet de multiboot, tu sais ce qu'il en est en pratique ?

Aussi est-ce que le modem et autres composants avec des blobs proprios sont isolés ?

Est-il possible d'utiliser une application Android avec une couche de type Anbox ou similaire ? Je pense particulièrement à OSMAnd~ qui est sans doute une des applications les plus utiles sur un téléphone (quoique avec l'autonomie réduite, c'est pas idéal à l'heure actuelle).

J'avais fait ça il y a quelques années avec XMPP. La « radio collective» était une fonctionnalité expérimentale de Salut à Toi qui permettait d'écouter et partager la musique en même temps sur un salon de discussion :

(d'ailleurs on voit en dessous de la dépêche une autre fonctionnalité — toujours en place — pour contrôler un lecteur multimédia à distance avec MPRIS)

Et une vidéo qui présentait la fonctionnalité (en 2012, le temps passe !) :
https://www.goffi.org/post/2012/02/02/Radio-collective

Le code est toujours présent dans le backend, c'est juste que l'interface web a été refaite, mais j'envisage de remettre en place à l'occasion.

J'avais fait, plus jeune, un freeware pour ajouter les bureaux virtuels à Windows, il avait eu un petit succès (GDesktops). Après je suis passé à Gnunux et au libre, et je n'ai plus jamais regardé en arrière…

Salut, c'est vraiment super merci beaucoup du partage. Je fais parti de ces devs logiciels attirés depuis longtemps par l'électronique mais qui ne trouve jamais le temps de s'y mettre sérieusement (surtout avec un gros projet logiciel sur les bras).

Petites questions :

combien de temps réel entre l'idée et la réalisation, et combien de temps tu y as vraiment consacré par semaine ?

Pour la réalisation du circuit, tu as fait ça au boulot, ou par un tiers, ou tu as ce qu'il faut à la maison (comme je me souviens avoir fait à l'école, avec insoleuse et tout) ?

Enfin question de débutant : est-ce qu'il est possible de simuler un tel circuit avec des outils libres avant de passer à la réalisation physique ?

Merci et encore bravo !

Jitsi Meet permet de faire du partage d'écran, et il n'y a pas de compte à créer. Par contre vu la situation, je ne serais pas étonné que les serveurs soient un peu surchargés, donc à voir s'il n'est pas possible d'avoir une instance à vous.

https://meet.jit.si/ (Framasoft a aussi une instance à https://framatalk.org/, mais ils ont annoncés être déjà surchargés, il vaut mieux trouver une autre instance pour les laisser respirer un peu).

Et en plus c'est du XMPP :)

Oui donc ça fait confiance à la première utilisation (TOFU), si le serveur t'envoies n'importe quoi au début ça passe.

Que se passe-t-il si quelqu'un a un nouvel appareil (quelqu'un qui était sur un téléphone et ajoute une tablette par exemple) ? Il y a une notification, quelque chose ? Rien à valider je suppose ?

OMEMO est l'adaptation de double ratchet pour XMPP, ça n'a pas de sens en dehors de XMPP. OTR par contre n'est volontairement lié à aucun protocole, ce qui fait qu'on peut l'utiliser avec pratiquement n'importe quoi. C'est d'ailleurs un des rares avantages qu'il a sur OMEMO : il peut fonctionner avec des passerelles vers d'autre protocoles.

le principe du chiffrement de bout en bout, c'est justement de ne pas faire confiance au serveur. Si c'est ton serveur qui valide les identités, ça ne sert à rien (à la limite à chiffrer les données pour le serveur, comme ça s'il y a un problème il peut indiquer – ou prétendre – qu'il ne pouvait rien savoir).

Et proprio ou libre ça ne change pas grand chose ici, l'important c'est qui a accès au serveur.

ouch oui, fatigue toussa :). Bon enfin avec le contexte, ça n'a pas empêché de comprendre.

Je trouve que c'est ce qui fait la grande force de Wire, Signal et Whatsapp. Cela ne demande aucune action de la part de l'utilisateur.

Oui justement j'ai vu un Whatsapp tourner récemment (je n'ai jamais utilisé moi même), et j'ai l'impression que ça ne demande jamais de valider la ou les empruntes du correspondant, est-ce vraiment le cas ? Si oui ça me laisse perplexe, parce qu'un chiffrement de bout en bout sans vérification de l'authenticité ça ne sert pas à grand chose (à part à avoir un argument marketing peut-être).

J'ai un épisode de parlons XMPP sur le chiffrement à moitié rédigé depuis très longtemps, mais je ne trouve pas le temps de le finir, je suis débordé. Il explique justement ça ainsi que les différences entre les méthodes de chiffrements utilisées sur XMPP.

En gros les 2 méthodes modernes (y'a de grosses discussions en cours pour que ça évolue, mais j'ai pas le temps maintenant d'expliquer en détails) sont OMEMO et OX (OpenPGP), qui permettent tous 2 (et contrairement à OTR) de fonctionner avec plusieurs appareils et quand le ou les correspondant⋅e⋅s sont hors ligne.

OMEMO a une confidentialité persistante, ce qui n'est pas le cas d'OX. En pratique, ça veut dire qu'un appareil ne peut pas avoir des messages antérieurs au moment où il est entré dans une conversation avec OMEMO, tandis qu'avec OX c'est possible. C'est une propriété qui est désirable ou non selon les cas.

Quant au chiffrement de bout en bout par défaut, le problème principal est que la spécification OMEMO a été mal faite et ne chiffre que le corps du message (et pas toutes les données autour, ce qui est très utilisé en XMPP avec les extensions). Du coup si on chiffre avec OMEMO, on fait une croix sur beaucoup de fonctionnalités, et on en arrive à des choses très moches et qui font grincer des dents dans la communauté XMPP, comme des données de mise en forme dans le corps du message (une partie qui ne devrait contenir que du texte pour les humains). C'est une des raisons pour lesquelles il y a de grosses discussions en cours, et que la version actuelle d'OMEMO va être retirée tôt ou tard pour une version faite correctement.

Il y a un chiffrement obligatoire entre clients et serveurs (C2S) et entre serveurs (S2S) avec XMPP. Le chiffrement de bout en bout ajoute une couche pour que tout ne soit pas en clair au niveau du ou des serveur(s), mais sur le réseau c'est toujours chiffré.

Tiens pendant qu'on est à parler de Qt et de Python, est-ce qu'il y a toujours les 2 bindings (PyQt et PySide) ? Si oui, et en dehors des licences (qui sont la raison principale d'une réécriture d'un binding si je me souviens bien), quels sont les intérêts à choisir l'un ou l'autre, et est-ce que les API sont compatibles  ?

C'est plus par curiosité, j'utilise Kivy à l'heure actuelle.

Merci pour la dépêche et aux équipes derrière ce logiciel.

J'en profite pour demander si vous avez une solution efficace pour bloquer les vidéos, c'était censé être fait par Firefox lui même, mais sur de nombreux site j'ai toujours des vidéos qui se lancent automatiquement (sans le son) malgré les réglages idoines, et prennent de la bande passante pour rien en plus d'être très énervantes.

Ce qui me bloque pour utiliser Poetry à l'heure actuelle, c'est l'installation. On demande d’exécuter aveuglément un script sur un dépôt git qui peut changer à n'importe quel moment. Autant je peux moi même vérifier ce script, autant je me vois mal demander ça à mes utilisateurs. C'est dommage parce qu'en dehors de ça ça a l'air super. Pour pip qui est maintenant officiellement distribué avec Python il y a ensurepip, est-ce qu'on a la perspective de quelque chose de similaire à court ou moyen terme ?

Pour celles ou ceux qui utilisent déjà Poetry, est-ce que cette installation ne vous pose pas problème ?

pourtant prosody explique comment dans sa doc: je fais tourner ce composant sur mon serveur depuis plusieurs années, et ce n'est que parce que j'ai un utilisateur sous iOS que je dois faire ces changements. Je n'ai jamais eu de problème de transfert de fichier auparavant.

Tu parles de proxy65 ou d'un composant Jingle pour le transfert de fichiers ? Parce que le premier oui ça existe depuis des années, ça date même d'avant Jingle (ça a été repris dans Jingle).

Si tu as un appareil A qui veut envoyer un fichier à un appareil B de ton contact, et que A<->B ne passe pas (à cause d'un NAT ou autre), tu peux utiliser ce proxy au milieu (appelons le P), et tu fais le transfert de fichier avec A->P, et B le récupère en faisant B->P et il n'est pas nécessaire d'accéder à un port ouvert de B. C'est expliqué dans la XEP-0065, d'où le nom. Mais ce composant ne change rien au fait que tu dois être connecté en même temps pour faire le transfert de fichiers via Jingle.

Ce dont je parle avec un composant Jingle, c'est un composant qui garde les fichiers et permet de les retrouver quand on veut, ce qui fait que A peut partager un fichier avec B même s'ils ne sont pas en ligne au même moment (mais du coup ça transite par le serveur). Et ça, il n'y a à ma connaissance que SàT qui le permet à l'heure actuelle. Le gros intérêt par rapport à HTTP Upload, c'est que tu as tous les mécanismes de négociation de Jingle + les extensions comme les vignettes (thumbnails) pour les grosses images, que j'utilise avec les albums photos.

Y a t il un moyen de mettre une espèce de priorité dans les méthodes d'upload ?

C'est le client qui gère ça, et la plupart du temps HTTP upload est utilisé de nos jours. Ceci dit ça marche bien pour les petits fichiers (< 10 Mio) mais c'est généralement bloqué au dessus.

Proxy 65 n'est qu'un outil pour faire le transfert de fichier en le faisant transiter par le serveur si la connexion directe ne passe pas (c'est un peu plus compliqué que ça mais c'est l'idée en gros). La méthode derrière c'est Jingle File Transfer, j'en avais parlé dans parlons XMPP épisode 10. C'est un meilleur système mais c'est moins répandu (et personne – à part dans SàT, que je développe – ne l'utilise avec un composant serveur, du coup ça oblige à avoir les clients connectés en même temps).

Donc bref, c'est HTTP Upload qui est utilisé dans la plupart des cas parce que ça marche à coup sûr pour ceux qui reçoivent les fichiers, et ça ne nécessite pas d'être en ligne en même temps.

Le lien aesgcm:// est une méthode non standard utilisée par Conversation pour envoyer un fichier chiffré avec OMEMO. C'est documenté de façon non officielle mais n'est pas passé en standard officiel, et nous n'avons à l'heure actuelle pas de méthode alternative pour chiffrer un fichier sur le serveur, donc si tu peux trouver un client qui le gère (c'est le cas au moins de Conversation et de Gajim) c'est pas plus mal.

Il y a eu des progrès sur le partage de fichier ces dernières années, mais ça n'est pas encode idéal (et c'est l'un des problèmes sur lesquels je travaille d'ailleurs).

Donc explications mises à part, utilise HTTP Upload et des clients qui gèrent aesgcm:// et ne te prends pas la tête. Pour un gros fichier, un bon client devrait passer automatiquement à Jingle quand c'est nécessaire.

Le transfert d'image se fait la plupart du temps avec HTTP File Upload, donc ton problème est très certainement là.

Sans avoir testé moi même (je n'ai pas d'appareil avec iOS), Monal est un nom qui revient souvent (avec ChatSecure que tu as testé). Sinon l'équipe de Tigase est assez active ces derniers temps, leur clients sont sans doute à tester (BeagleIM et Siskin IM).

Si tu testes, ça pourrait être pas mal de dire ce que t'en penses ici, pour voir si ce sont des clients qu'on peut recommander.

Le protocole de chiffrement et le protocole de communication ça n'est pas la même chose. XMPP aussi utilise une adaptation du protocole de chiffrement de Signal (c'est OMEMO). Je ne sais pas si WhatsApp utilise encore FunXMPP, mais ça n'est pas incompatible.

Et sinon Google et FB ont parlé XMPP à un même moment sans pouvoir se parler mutuellement (parce qu'ils ont désactivé la fédération, du moins FB).

Il est probable que si tous les développeurs de clients XMPP concentraient leur effort sur un client au lieu de toute une tripotée, ils arriveraient à y faire tenir plus de fonctionnalités et à se concentrer plus sur ce que l'utilisateur veux.

ça n'est pas si simple, les clients ont des architectures et des contraintes différentes. La méthode la plus commune aujourd'hui pour faire un client qui tourne partout serait de faire du web et d'utiliser Electron pour porter ça ailleurs que dans le navigateur. Ça marche, mais c'est lourd et ça n'est pas du natif, ce qui peut poser tout un tas de problèmes. C'est souvent ce que font les applications de messagerie (ou autre) les plus connues, mais y'a du monde derrière pour arrondir les angles (et on revient au problème du temps/des ressources disponibles). Il faut aussi noter que beaucoup de clients ont été commencés bien avant qu'Electron existe.

Conversations c'est du Java + API Android, difficilement portable. Gajim (probablement le plus complet), c'est du Python + GTK, là c'est déjà beaucoup plus portable, mais on va avoir des soucis sur Android, iOS, Web.

D'un autre côté, Movim utilise justement Electron, et fait du Material Design avec voix et tout, donc a priori tout ce qui est à la mode… sauf le chiffrement de bout en bout avec OMEMO, parce que c'est difficile à faire proprement avec cette architecture.

Et dans mon cas particulier, un projet comme SàT a une architecture différente qui fait une grande partie de sa spécificité, difficile de partir d'un client pensé pour le bureau (ce qui était le cas de la majorité des clients à l'époque où ça a été commencé) pour faire ça.

Après il y a le cas de ceux qui veulent faire un client spécifique à une plateforme, et qui utilisent ce qu'ils connaissent, c'est le cas de 2 clients récents (Dino qui utilise Vala, et Kaidan qui utilise Qt).

Et il est probable que ça leur plaise plus de coder un client en partant de zéro que de contribuer à un client existant.

c'est extrêmement rare qu'un client parte de zéro. Bien souvent une bibliothèque est utilisée et complétée quand nécessaire.

c'est pas compliqué, c'est parce que la plupart des clients sont développés par un groupe très restreint de personnes (souvent 1 seule) sur le temps libre. « Conversations » est un des très rares clients à avoir un dév à plein temps, et du coup c'est un des clients les plus populaires parce que le dév a le temps de polir.

Côté serveurs il y a un peu plus de monde à plein temps, beaucoup avec des entreprises: ejabberd, MongooseIM, Tigase, Openfire ont tous une boîte avec du monde payé derrière, Prosody c'est plus petit mais y'a, sauf erreur, 2 dévs à plein temps. Et les serveurs sont, eux, très utilisés (ejabberd en particulier est ou a été utilisé avec de très gros réseaux).

Il y a beaucoup de légendes, de fantasmes et d'idées reçues sur ce que fait la communauté XMPP, et du monde pour critiquer et expliquer comment il aurait fallu faire ça on trouve sans trop de problèmes. Mais la réalité c'est qu'on sait très bien ce qu'il faut (vidéo conf, un bon client iOS, une interface léchée, les bonnes pratiques d'UX, une installation simple avec des paquets pour toutes les distributions/plateformes, du chiffrement de bout en bout) mais on manque de temps.

Dans les cas particuliers de SàT et Movim qui sont des clients qui creusent en dehors de la messagerie instantanée, on souffre aussi du fait que la plupart des gens qui connaissent XMPP l'ont associé au chat uniquement. On l'a vu avec ActivityPub, quand des gens s'émerveillaient d'une vidéo avec un commentaire partagé alors qu'on fait ça depuis des années.

Avec SàT j'expérimente sur des terrains complètement nouveaux (forge fédérée par exemple), et là encore je manque de temps pour que ça prenne vraiment (il me faudrait quelques jours pour ajouter la recherche full text, la gestion de Git en plus de Mercurial, des passerelles Gitlab/Github, et une interface un peu plus agréable, mais je ne les ai pas).

Rien que pour avoir des paquets sur Flathub, Yunohost, F-Droid etc. pour que les gens puissent tester facilement, ça prend un temps énorme (d'ailleurs si y'a des gens pour aider là dessus, je suis preneur).

Sur Android tu as aTalk (natif) et Movim (electron) qui gèrent la vidéo (je n'ai pas testé moi même, donc à voir), et c'est prévu sur Conversation pour le début d'année prochaine. Jitsi avait une application mais je crois qu'elle n'est plus trouvable (au moins sur F-Droid), mais sauf erreur aTalk en est un fork.

J'ai moi même prévu d'implémenter la vidéo sur Android, web et bureau, mais vu le peu de temps disponible, ça ne sera pas pour tout de suite.

Pour Tox, le problème de ne pas avoir de serveur est que ton client va faire son boulot, ça veut dire qu'il va avoir besoin de plus de ressources (réseau et processeur notamment), et du coup ça risque de se sentir fortement sur la batterie. À vérifier, je n'ai jamais testé Tox sur Android, et la dernière fois que j'ai testé sur bureau remonte à des années.

Émission super intéressante du début à la fin, autant la rubrique sur les transcriptions, l'interview de Jean-Baptiste que les perles avec le passage sur Wikidata. Merci à tous les participant⋅e⋅s et personnes qui travaillent régulièrement pour rendre tout ça possible.

Le / dans les arguments est une possibilité du langage qui peut être pratique mais qui n'a pas forcément (et ne devrait pas à mon avis) à être utilisé souvent.

Je vois 2 cas principaux où c'est utile et ça peut empêcher des problèmes:

• imiter une API C, je pense que c'est le cas d'utilisation principal
• pouvoir réutiliser des noms d'arguments dans kwargs. C'est un cas de niche, mais ça m'est déjà arrivé d'être embêté de ne pas pouvoir utiliser un nom d'une variable positionnelle dans des **kwargs, et le jour où ça arrive, on est bien content d'avoir cette syntaxe.

De toute façon, comme le rappelle le zen de Python (import this), « Explicit is better than implicit. »: ces syntaxes sont à utiliser quand elle sont vraiment nécessaires, et dans les autres cas il vaut mieux quelques lignes de plus pour rendre le code plus lisible.

Quelqu'un qui veut rendre un code illisible y arrivera toujours, Python ou pas.