sauf que celui que tu connais n'est peut-être pas celui qui sera utilisé. Et JS plus que tout autre écosystème demande une mise à jour permanente, et potentiellement des refactoring ou changements d'outils (je sais qu'on est vendredi).
Je risque moins d'apprendre Brython. D'où moins de coups de mains possibles, que vous déplorez.
Si tu souhaites contribuer à SàT, il vaut mieux avoir des notions de Python (c'est un « tu » général vu que tu en as déjà). À partir de là, tu sais utiliser Brython ou Pyjamas.
et bim, redirection vers un papier xmpp ! Je me dis "c'est forcément technique et trop dur pour 20min par ci par là". Réponse très technique.
Le tuto lié ne parle de XEP, tu peux commencer par là pour jouer un peu.
Après implémenter une fonctionnalité XMPP, ça passe 9 fois sur 10 par une XEP, ça peut sembler difficile quand on n'en a jamais fait, mais en pratique ça ne l'est pas : ça explique juste précisément ce qu'il faut faire. Regarde celle là par exemple, tu verras que ça n'est pas si compliqué: XEP-0245.
Puis je parle aussi de CSS, de traduction, d'ouvrir la liste de tickets pour en choisir un, etc.
vous préférez avancer que rendre les contributions + faciles. Ok.
Il ne faut pas exagérer non plus, les contributions ne sont pas difficiles. Mercurial n'est pas plus compliqué que GIT (c'est même plus simple), et si vraiment ça pose problème on peut même s'en sortir avec un envoi du code par courriel ou XMPP, les rapports de bogue ne sont pas non plus compliqués à faire (on accepte même ceux en Français si nécessaire).
argument pour des tickets d'une forge, type gitlab :)
quelqu'un qui disparaît je ne vois pas trop ce que ça va changer dans une forge. Enfin de toute façon Gitlab n'est pas exclus, et il nous manque un outil de revue de code c'est vrai.
et j'oubliais dans les choses à faire (mais c'est chiant et je le ferai sûrement moi même): les tests ! On a utilisé par le passé un buildbot, mais la couverture est à revoir, ainsi que le système de tests, c'est le chantier que je comptais faire pendant la phase de bêta et que les fonctionnalités seront gelées.
ce serait super. Votre employeur est-il ok pour vous passer à temps partiel ? J'aimerais y arriver aussi, sans nécessairement une compensation de salaire. Je serais tellement content ! La compensation aurait du sens pour un temps long dédié au logiciel, à mon avis.
Ce sont des choses à négocier, mais vu le temps que ça prend sur ma vie, il va falloir trouver une solution et celle là semble la plus réaliste à l'heure actuelle.
y a-t-il une liste de tâches faciles ? pas vu sur votre bugzilla.
À une époque on avait fait une TODO list sur le wiki, mais avec le faible nombre de contributions et l'évolution constante du projet, on n'a pas maintenu. Le plus simple est de venir sur notre salon XMPP (sat@chat.jabberfr.org) pour en discuter.
Il y a quelques XEPs qui seraient sympa à implémenter (par exemple blocking command serait assez trivial à faire), ça se passe côté backend et il y a un tuto écrit ici: écrire un greffon pour SàT.
On peut aussi faire de l'amélioration de CSS (on va réécrire Libervia pour la 0.8, mais ça serait pas mal de rafraîchir), du thème (je viens de commencer à réécrire le système de thèmes pour le blog statique), de la traduction, ou prendre un bug qui semble abordable dans la liste.
Mais je trouve que vous ne rendez pas la chose facile: hg, bugzilla et pas github/gitlab et un gestionnaire de tickets plus moderne.
Mercurial est utilisé depuis le début du projet, et bugzilla est là depuis longtemps aussi, c'est toujours utilisé parce que ça fait le boulot et que changer demande du temps qu'on consacre plutôt au code de SàT.
On a abordé l'utilisation de Gitlab/Github dans la dernière A.G. (celle dont je parle dans le journal si je ne m'abuse, du coup le résumé doit être dans ce compte-rendu), ainsi que d'implémenter l'authentification XMPP dans Bugzilla pour éviter d'avoir à créer un compte. Github a été écarté par cohérence, Gitlab reste une option.
Cependant on a toutes les briques pour faire notre propre outil de rapport de bogues basé sur XMPP maintenant (et donc décentralisé), c'est en gros une version spécialisé du blogage qu'on gère déjà (en tout cas dans notre cas pas besoin de plus, du moins pour le moment), et ça permet d'avoir un cas concret, c'est a priori ce qui va être fait dans un futur que j'espère proche.
Et il y aura une difficulté en plus si vous utilisez comme je vous en ai entendu parler, brython ou un truc du genre à la place d'un framework JS.
Brython ne sera utilisé que pour l'interface Web, et devrait être beaucoup plus simple à installer que Pyjamas que nous utilisons actuellement. Ce n'est pas plus compliqué qu'apprendre un framework JS (même plutôt plus simple vu qu'on ne change pas de langage), et ça ne sera de toute façon pas utilisé pour les pages statiques.
Certes, l'image docker simplifie l'installation. Mais surtout je trouve que vous restez très techniques et que vous ne parlez pas bien aux potentiels utilisateurs, dont je suis aussi (surtout?).
Effectivement on a parfois un problème de communication, il ne faut pas hésiter à nous le dire et à nous demander si quelque chose n'est pas clair. C'est difficile de ne pas être technique quand on a la tête dans le code à longueur de temps, en plus sur linuxfr j'ai tendance à aller plus dans les détails qu'ailleurs.
Et le thème CSS… a besoin d'un contributeur ou contributrice :S
Oui, d'ailleurs quelqu'un était venu proposer un thème CSS pour le blog statique sympa comme tout, je voulais l'intégrer mais depuis on ne le voit plus sur le salon :(. Sinon Libervia va être réécrit pour la version 0.8 (pas celle à venir, la suivante), et il va y avoir un gros coup de rafraîchissement graphique au passage.
Nous y avons ouvert un compte pour SàT après en avoir discuté en A.G., bien que nous n'ayons pas encore vraiment commencé à utiliser et communiquer dessus (ça va venir). Nous apprécions beaucoup le côté éthique et impliqué dans le libre.
Je tiens aussi à vous remercier pour votre super réactivité, j'ai demandé la gestion des liens xmpp:, et ça a été intégré en quelques jours.
Tiens petite question pratique. Nous nous sommes ajouté à la communauté « libre à toi », parce que nous nous connaissons et avons des valeurs communes, mais la page de la communauté indique « Êtes-vous un contributeur dans la communauté libratoi ? », ce qui n'est pas le cas. Le rôle des communautés c'est d'indiqué des liens/affinités ou des personnes qui participe activement à un projet ?
Bon courage, vraiment content de voir un service comme ça se développer.
La question est très bonne, et vu de l'extérieur ça peut sembler surprenant, mais en y regardant de plus près ça n'est pas très difficile à comprendre.
Il y a déjà – et surtout – un budget bien plus important pour Matrix, et des développeurs (je ne sais pas combien, mais à vu de nez quelques uns) qui y travaillent à plein temps. C'est une très grosse boîte derrière Matrix (Amdocs). En comparaison, la plupart des clients se font sur le temps libre : Gajim c'est principalement une personne qui a peu de temps libre, Movim c'est principalement 1 seule personne aussi, pour SàT on a été temporairement 2 à plein temps (donc une grosse partie a été utilisée pour participer à des événement), mais c'est actuellement 1 seule personne sur son temps libre (moi), et on peut dire la même chose de la plupart des projets actifs (si ce n'est tous pour les clients libres, pour les serveurs c'est un peu différent).
Conversations fait figure d'exception avec 1 (seule !) personne qui arrive à être à plein temps dessus, et ça se sent dans le soin apporté dans les détails et la com', et qui contribue à son succès.
D'autre part il y a un choix du tout web en effet, et les technologies ont énormément évolué ces dernières années. La vidéo-conférence était un défi technique à la naissance de Jingle, aujourd'hui WebRTC gère toute la complexité. Je me souviens à la conf Matrix que j'avais vu au Fosdem des applaudissement nourris pour la vidéo alors que ce n'est qu'une mise en place de WebRTC, il y a aujourd'hui des très petits projets qui arrivent à faire de même.
Il faut bien se rendre compte de la complexité d'une vidéo-conférence, ce n'est pas juste envoyer un flux à un participant, il faut gérer les débits variables, annuler l'écho, gérer les codecs, adapter la transmission aux conditions, etc. Tout ceci est devenu presque trivial en web grâce aux développements de Google ou Mozilla.
Par contre sur bureau c'est toujours très compliqué, donc ça explique les difficultés des clients non web (pour notre part on met ça de côté pour le moment par exemple). Des clients s'appuyant sur des outils avancés comme Gajim avec Gstreamer, ou dont c'est une fonctionnalité principale comme Jitsi s'en sortent mais ça reste un boulot bien plus important que sur le web.
Pourquoi ne pas faire pareil pour les clients XMPP webs ? Et bien ils le font justement, Movim gère la vidéo dans le version de dév, Jappix (qui n'est plus maintenu) le faisait également, et probablement d'autres. Quand nous nous y intéresserons dans SàT, il est fort probablement que nous implémenterons en premier dans Libervia (frontal web) avec WebRTC.
Ce que j'affirme est tout de même à prendre avec des pincettes : je n'ai pas encore travaillé moi même sur la visio-conférence, aussi mon ressenti n'est peut-être pas juste.
Même en dehors de la vidéo, il y a beaucoup de problèmes qui sont plus simples aujourd'hui à gérer parce qu'il y a plus d'outils et bibliothèques disponibles, parce qu'on a plus d'outil de messageries existants dont on peut s'inspirer.
Ensuite les objectifs peuvent être différents. Pour Whatsapp le but principal évident était (et est toujours) de monétiser. Pour Matrix, je pense que c'est assez clairement le but aussi à moyen ou long terme. Ces choix font mettre les moyens et les priorités dans l'esthétique, les fonctionnalités populaires et le marketing, et on se retrouve avec X applications qui font peu ou prou la même chose et se ressemblent fortement, et qui plaisent parce que les gens s'y retrouvent.
Selon les projets, les objectifs peuvent être très différents (j'allais élaborer un peu là dessus, mais je manque de temps donc je vais finir ce message sur cette remarque).
le transfert de fichier est possible via Jingle, mais pas avec plusieurs destinataires en même temps.
C'est HTTP upload qui est utilisé dans ce cas (avec apparemment un chiffrement spécifique à Conversations dans certains cas).
Ce tableau est d'ailleurs incorrect, puisqu'il n'y a pas de méthode de transfert de fichier standard à l'heure actuelle avec OMEMO (il est plus ou moins au même point que OX de ce côté, avec une protoXEP en plus mais non officielle).
bon je rectifie, j'avais mal compris. Le fichier est envoyé normalement sur le HTTP upload, mais la clef de déchiffrement est mise dans la partie « fragment » (après le « # ») de l'URL. Du coup pas besoin d'un HTTP upload spécifique, et les clients qui gèrent ça vont avoir le fichier, pour les autres il sera illisible.
Le chiffrement de point à point (client <==> serveur <==> MUC (conversations de groupes) <==> autres serveurs <==> autres clients) est effectivement obligatoire dans XMPP depuis plusieurs années. Le chiffrement de bout en bout est principalement utile si tu n'as pas confiance en l'un des entités entre toi et ton/tes contact(s) (donc ton serveur, le service MUC, et un des serveurs de tes correspondants).
Dans le cas par exemple ou tu communiques avec un ou des proches sur le serveur que tu gères toi même (avec le service MUC très probablement sur la même machine), le chiffrement de bout en bout n'est pas utile.
HTTP upload qui stocke le fichier en clair sur le service (mais la transmission est chiffrée via HTTPS), et il n'y pas (encore) de méthode (standard du moins) pour chiffrer le fichier.
Apparemment il utiliserait une méthode de chiffrement avec clef dans l'URL, le problème est que ça n'est pas standard et ça demande un HTTP upload spécifique, ça ne marchera donc pas avec n'importe quel serveur.
Conversation -> Conversation (en clair et OMEMO, 1@1 ou multi: OK)
t'es en train de dire que Conversations est capable d'envoyer un message chiffré à plusieurs personnes en même temps ? T'es certain de ce que tu dis ?
Parce qu'à l'heure actuelle, tu peux utiliser Jingle (avec l'utilisation d'OMEMO – ce qui n'est pas standard pour le moment – comme je l'ai expliqué plus bas), mais ça n'est possible qu'entre 2 contacts, ou HTTP upload qui stocke le fichier en clair sur le service (mais la transmission est chiffrée via HTTPS), et il n'y pas (encore) de méthode (standard du moins) pour chiffrer le fichier.
Du coup je suis très étonné par ce que tu dis, est-ce que j'ai mal compris ou est-ce que tu dis bien qu'il est possible de chiffrer un fichier pour plusieurs destinataires en même temps ? Si oui ça marche pour gros et petits ? Tu fais comment (je testerai pour être sûr) ?
Gajim -> Conversation (non)
Gajim gère HTTP upload donc il est possible de partager un fichier, mais je veux bien que ça ne fonctionne pas avec Jingle vu que Gajim utilise une version obsolète (et conversation ne gère probablement pas Stream Initiation, ce qui n'est pas plus mal).
Il y a eu une petite tension entre Matrix et la communauté XMPP l'année dernière (et un peu l'année d'avant), parce que pour se faire connaître ils se sont mis sur un angle d'attaque très agressif envers XMPP, que ce soit dans les interventions (par exemple au FOSDEM il y a 2 ans, là où j'ai entendu parler d'eux la première fois d'ailleurs) ou par écrit.
Le problème n'est pas tant la critique en soit, c'est aussi qu'ils ont propagé un certains nombre de fausses vérités, notamment sur leur FAQ (qui n'est d'ailleurs toujours pas terrible même si c'est mieux) au point que la communauté a dû répondre, par exemple avec cette page (ainsi que des réponses sur différents réseaux).
À ça s'ajoute des gens (a priori des groupies, même si on ne sait pas trop si c'est des gens impliqués dans le projet ou pas) qui font de la propagande systématiquement pour Matrix dès qu'un article un peu visible parle de XMPP (en particulier sur hackernews ou reddit, mais on a vu des remarques désagréables même ici). Là encore pas vraiment un problème de parler d'un projet, mais quand c'est sous pour insinuer que XMPP est dépassé (ce qui est faux) et que l'herbe est plus verte chez eux, forcément à force c'est fatiguant.
Enfin bref, maintenant que Matrix est plus connu ça s'est un peu calmé, et c'est préférable de voir qu'il est possible de collaborer.
OMEMO a été basé historiquement sur libsignal, et la première proposition de XEP a été faite avec.
Cette proposition a été rejetée parce que :
la seule implémentation était une bibliothèque copyleft
ça n'était pas standardisé
il y avait des risques juridiques
De leur côté, les gens de Matrix ont développé Olm, standardisé et sans les problèmes mentionnés, il a donc été retenu pour une nouvelle proposition de OMEMO, cette fois acceptée.
Un exemple où Matrix et XMPP peuvent collaborer, une relation un peu plus seine que ce qu'on a vu l'année dernière.
Seulement il y a un « standard » de fait avec la première version de OMEMO (pas celle de la XEP donc), car c'est celle utilisée par Conversations et tout le monde veut être compatible avec.
De son côté, Conversations est bloqué pour passer à Olm parce qu'il n'y a pas encore de bibliothèque Java.
Les nouvelles implémentations partent actuellement toutes sur la version brouillon à cause de ce standard de fait, mais il ne devrait pas être difficile de passer d'une version à l'autre une fois que tout le reste est en place (interface utilisateur, gestion des messages chiffrés, autre XEPs nécessaires à l'utilisation, etc). Il est aussi tout à fait possible de fournir les 2 versions en même temps, mais aucun client ne le fait à l'heure actuelle.
Autre changement, une documentation de Double Ratchet a été mise dans le domaine public entre temps, donc il est possible de repasser à une implémentation basée dessus. J'ai suivi cette partie de loin, mais je sais qu'il est question d'en discuter au XMPP summit qui aura lieu ce week-end.
Tout ça va rapidement se stabiliser, il y a une petite excitation sur le sujet en ce moment , mais d'ici quelques mois ça devrait être stable.
Le téléversement de photos fonctionne avec Gajim, Conversation (je ne sais pas pour ChatSecure) et avec une bonne partie des clients activement développés. Le problème est que sauf si tu maîtrises ton propre serveur (ou si tu fais confiance aux admins), tu ne sais pas qui peut voir ces photos, combien de temps c'est stocké, et tu ne peux pas les supprimer (ce qui est – me semble-t-il – le cas sur la plupart des plateforme de messagerie, XMPP ou pas, si vous avez des contre-exemples je veux bien des infos).
L'envoi en pair à pair est disponible au moins sur Gajim, je pense que Conversations implémente Jingle et ChatSecure je ne sais pas. Gajim malheureusement utilise une ancienne version du protocole.
Plus d'infos sur l'envoi en pair à pair dans les épisode 9 et épisode 10 de parlons XMPP.
Pour le chiffrement des fichiers en pair à pair, je crois que Conversations utilise une méthode non standard avec OMEMO (proposée à la standardisation mais pas retenue), et il n'y a pas encore de méthode standard (il y a une méthode utilisant TLS qui devrait avoir un numéro officiel mais qui semble perdue).
Enfin pour l'envoi avancé (sous forme d'album), il y a des extensions permettant un début d'implémentation, mais rien de concret à ma connaissance. Ça devrait être un de nos chevaux de bataille pour 2017 avec SàT.
est-ce qu'un modo peut corriger: On peut noter que ni Gajim, ni Conversations, ni ChatSecure n'utilise ==> On peut noter que ni Gajim, ni Conversations, ni ChatSecure n'utilise*nt*
principalement 2 sources : différentes subventions, et le support technique/développement de fonctionnalités particulières pour certains clients (on peut notamment citer AAP qui a accompagné le développement depuis le début du projet, et NTB).
Les autres projets comme Booktype ont des services payant disponibles également, mais je connais moins vu que je travaille sur Superdesk.
intégrant le chiffrement de bout en bout PAR DÉFAUT
ce n'est pas forcément simple ou désirable.
À l'heure actuelle il y a 3 méthodes de chiffrement de bout en bout:
1) OTR, qui ne gère pas les appareils multiples, ne permet pas l'historique sur le serveur, et ne chiffre pas toute la stanza (seulement le corps)
2) OX (OpenPGP moderne) qui gère chiffrement de toute la stanza, appareils multiples, et archives serveurs, mais qui ne gère pas la confidentialité persistante et qui fait augmenter considérablement la taille des données
3) OMEMO qui ne gère pas le chiffrement de toute la stanza (il le fera peut-être dans le futur), qui gére les appareils multiples et la confidentialité persistante, mais qui ne permet pas les archives serveur.
Le chiffrement de la stanza complète bloque certaines fonctionnalités (le serveur a parfois besoin de savoir ce qui passe), de même que l'impossibilité d'avoir les archives sur le serveur.
D'autre part si tu as confiance en ton serveur et en celui de ton correspondant, le chiffrement de bout en bout n'est pas forcément nécessaire.
Bref, le problème n'est pas si simple qu'il parait, et le chiffrement de bout en bout par défaut n'est pas forcément souhaitable (à l'heure actuelle).
Et je passe sur le fait que les XEPs ne sont qu'expérimentales (OMEMO n'est une XEP officielle que depuis quelques jours d'ailleurs).
ce n'est pas le première fois que je vois passer ce nom, mais c'est la première fois que je lis autant d'informations dessus, dépêche très complète bravo pour la transparence !
Ça ressemble à exactement ce qu'on cherche pour Salut à Toi (dons récurrent sans contrepartie, transparence, gestion par une association à but non lucratif, et financement par votre propre système sans pourcentage indécent), bref c'est très très intéressant.
Ce n'est pas précisé dans la dépêche mais je demande par par acquit de conscience : il n'y a pas de publicité ou de publicité prévue ? Ça serait rédhibitoire pour nous car contraire à notre contrat social.
Aussi est-il possible de refuser certains mode de paiement (bitcoin si ça arrive notamment) ?
Merci pour la dépêche je vais suivre ça de très près et nous allons probablement nous inscrire si c'est aussi prometteur que ça en a l'air.
il y avait planète jabberfr (https://planet.jabberfr.org/) mais à part jabberfr eux même je suis quasiment le seul à encore publier là bas (la version anglophone est bien active elle par contre).
Pour ma part avec DLFP (surtout) et planet libre j'ai suffisamment pour me tenir à peu près à jour (et pour XMPP là le mieux c'est de suivre les salons et le planète anglophone).
Tu as l'air d'aller dans un terrain ou il y a déjà pas mal de choses, notamment demosphere : https://lille.demosphere.eu/ (change Lille par une autre ville si tu déménages). Ça vaut sûrement le coup d'entrer en contact avec eux.
Pour le financement, réussir à payer serveur + loyer + minimum vital avec un financement participatif, c'est faisable mais très difficile.
gajim a peut-être un look qui n’évolue pas beaucoup (avec une forte connotation GTK), mais il implémente quand même beaucoup de normes récentes qui améliorent la qualité de l’utilisation ;
Gajim est très complet et les implémentations de fonctionnalités sont en général bonnes voire excellentes, c'est ma référence quand je veux tester une fonctionnalité, ils ont fait un client vraiment bon.
encore Salut à toi qui avance quotidiennement (mais pas forcément sur la partie desktop, cela dit).
Il n'est pas super joli pour le moment parce qu'il faut d'abord qu'il tourne bien avant de s'occuper de la peinture, mais il sera clairement là pour notre prochaine version (et j'espère qu'une version au moins alpha sortira avant la fin d'année).
certains terminaux permettent d'afficher des images (comme Terminology), c'est peut-être sortir un peu du principe du terminal, mais ça peut valoir le coup d'y jeter un œil : https://www.enlightenment.org/about-terminology
Bravo pour votre super boulot, et content de voir la XEP-0070 se répandre, hâte de voir le plugin mediawiki.
Petite remarque, pour moi Poezio est un client console et pas ligne de commande, vous faites du ncurses (comme Vim ou Mutt), la ligne de commande c'est uniquement une commande dans un shell (comme ls ou grep). Enfin c'est un détail.
[^] # Re: Divers
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Salut à Toi sur bureau et Android (Cagou), état des lieux. Évalué à 3.
sauf que celui que tu connais n'est peut-être pas celui qui sera utilisé. Et JS plus que tout autre écosystème demande une mise à jour permanente, et potentiellement des refactoring ou changements d'outils (je sais qu'on est vendredi).
Si tu souhaites contribuer à SàT, il vaut mieux avoir des notions de Python (c'est un « tu » général vu que tu en as déjà). À partir de là, tu sais utiliser Brython ou Pyjamas.
[^] # Re: Divers
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Salut à Toi sur bureau et Android (Cagou), état des lieux. Évalué à 4.
Le tuto lié ne parle de XEP, tu peux commencer par là pour jouer un peu.
Après implémenter une fonctionnalité XMPP, ça passe 9 fois sur 10 par une XEP, ça peut sembler difficile quand on n'en a jamais fait, mais en pratique ça ne l'est pas : ça explique juste précisément ce qu'il faut faire. Regarde celle là par exemple, tu verras que ça n'est pas si compliqué: XEP-0245.
Puis je parle aussi de CSS, de traduction, d'ouvrir la liste de tickets pour en choisir un, etc.
Il ne faut pas exagérer non plus, les contributions ne sont pas difficiles. Mercurial n'est pas plus compliqué que GIT (c'est même plus simple), et si vraiment ça pose problème on peut même s'en sortir avec un envoi du code par courriel ou XMPP, les rapports de bogue ne sont pas non plus compliqués à faire (on accepte même ceux en Français si nécessaire).
quelqu'un qui disparaît je ne vois pas trop ce que ça va changer dans une forge. Enfin de toute façon Gitlab n'est pas exclus, et il nous manque un outil de revue de code c'est vrai.
[^] # Re: Divers
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Salut à Toi sur bureau et Android (Cagou), état des lieux. Évalué à 3.
et j'oubliais dans les choses à faire (mais c'est chiant et je le ferai sûrement moi même): les tests ! On a utilisé par le passé un buildbot, mais la couverture est à revoir, ainsi que le système de tests, c'est le chantier que je comptais faire pendant la phase de bêta et que les fonctionnalités seront gelées.
[^] # Re: Divers
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Salut à Toi sur bureau et Android (Cagou), état des lieux. Évalué à 5.
salut,
Ce sont des choses à négocier, mais vu le temps que ça prend sur ma vie, il va falloir trouver une solution et celle là semble la plus réaliste à l'heure actuelle.
À une époque on avait fait une TODO list sur le wiki, mais avec le faible nombre de contributions et l'évolution constante du projet, on n'a pas maintenu. Le plus simple est de venir sur notre salon XMPP (sat@chat.jabberfr.org) pour en discuter.
Il y a quelques XEPs qui seraient sympa à implémenter (par exemple blocking command serait assez trivial à faire), ça se passe côté backend et il y a un tuto écrit ici: écrire un greffon pour SàT.
On peut aussi faire de l'amélioration de CSS (on va réécrire Libervia pour la 0.8, mais ça serait pas mal de rafraîchir), du thème (je viens de commencer à réécrire le système de thèmes pour le blog statique), de la traduction, ou prendre un bug qui semble abordable dans la liste.
Mercurial est utilisé depuis le début du projet, et bugzilla est là depuis longtemps aussi, c'est toujours utilisé parce que ça fait le boulot et que changer demande du temps qu'on consacre plutôt au code de SàT.
On a abordé l'utilisation de Gitlab/Github dans la dernière A.G. (celle dont je parle dans le journal si je ne m'abuse, du coup le résumé doit être dans ce compte-rendu), ainsi que d'implémenter l'authentification XMPP dans Bugzilla pour éviter d'avoir à créer un compte. Github a été écarté par cohérence, Gitlab reste une option.
Cependant on a toutes les briques pour faire notre propre outil de rapport de bogues basé sur XMPP maintenant (et donc décentralisé), c'est en gros une version spécialisé du blogage qu'on gère déjà (en tout cas dans notre cas pas besoin de plus, du moins pour le moment), et ça permet d'avoir un cas concret, c'est a priori ce qui va être fait dans un futur que j'espère proche.
Brython ne sera utilisé que pour l'interface Web, et devrait être beaucoup plus simple à installer que Pyjamas que nous utilisons actuellement. Ce n'est pas plus compliqué qu'apprendre un framework JS (même plutôt plus simple vu qu'on ne change pas de langage), et ça ne sera de toute façon pas utilisé pour les pages statiques.
Effectivement on a parfois un problème de communication, il ne faut pas hésiter à nous le dire et à nous demander si quelque chose n'est pas clair. C'est difficile de ne pas être technique quand on a la tête dans le code à longueur de temps, en plus sur linuxfr j'ai tendance à aller plus dans les détails qu'ailleurs.
Oui, d'ailleurs quelqu'un était venu proposer un thème CSS pour le blog statique sympa comme tout, je voulais l'intégrer mais depuis on ne le voit plus sur le salon :(. Sinon Libervia va être réécrit pour la version 0.8 (pas celle à venir, la suivante), et il va y avoir un gros coup de rafraîchissement graphique au passage.
merci !
# Réactif et super esprit
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal La première année de Liberapay. Évalué à 4.
Nous y avons ouvert un compte pour SàT après en avoir discuté en A.G., bien que nous n'ayons pas encore vraiment commencé à utiliser et communiquer dessus (ça va venir). Nous apprécions beaucoup le côté éthique et impliqué dans le libre.
Je tiens aussi à vous remercier pour votre super réactivité, j'ai demandé la gestion des liens
xmpp:, et ça a été intégré en quelques jours.Tiens petite question pratique. Nous nous sommes ajouté à la communauté « libre à toi », parce que nous nous connaissons et avons des valeurs communes, mais la page de la communauté indique « Êtes-vous un contributeur dans la communauté libratoi ? », ce qui n'est pas le cas. Le rôle des communautés c'est d'indiqué des liens/affinités ou des personnes qui participe activement à un projet ?
Bon courage, vraiment content de voir un service comme ça se développer.
[^] # Re: Olm vs libsignal
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche ChatSecure 4.0 ronronne et adopte OMEMO . Évalué à 4.
La question est très bonne, et vu de l'extérieur ça peut sembler surprenant, mais en y regardant de plus près ça n'est pas très difficile à comprendre.
Il y a déjà – et surtout – un budget bien plus important pour Matrix, et des développeurs (je ne sais pas combien, mais à vu de nez quelques uns) qui y travaillent à plein temps. C'est une très grosse boîte derrière Matrix (Amdocs). En comparaison, la plupart des clients se font sur le temps libre : Gajim c'est principalement une personne qui a peu de temps libre, Movim c'est principalement 1 seule personne aussi, pour SàT on a été temporairement 2 à plein temps (donc une grosse partie a été utilisée pour participer à des événement), mais c'est actuellement 1 seule personne sur son temps libre (moi), et on peut dire la même chose de la plupart des projets actifs (si ce n'est tous pour les clients libres, pour les serveurs c'est un peu différent).
Conversations fait figure d'exception avec 1 (seule !) personne qui arrive à être à plein temps dessus, et ça se sent dans le soin apporté dans les détails et la com', et qui contribue à son succès.
D'autre part il y a un choix du tout web en effet, et les technologies ont énormément évolué ces dernières années. La vidéo-conférence était un défi technique à la naissance de Jingle, aujourd'hui WebRTC gère toute la complexité. Je me souviens à la conf Matrix que j'avais vu au Fosdem des applaudissement nourris pour la vidéo alors que ce n'est qu'une mise en place de WebRTC, il y a aujourd'hui des très petits projets qui arrivent à faire de même.
Il faut bien se rendre compte de la complexité d'une vidéo-conférence, ce n'est pas juste envoyer un flux à un participant, il faut gérer les débits variables, annuler l'écho, gérer les codecs, adapter la transmission aux conditions, etc. Tout ceci est devenu presque trivial en web grâce aux développements de Google ou Mozilla.
Par contre sur bureau c'est toujours très compliqué, donc ça explique les difficultés des clients non web (pour notre part on met ça de côté pour le moment par exemple). Des clients s'appuyant sur des outils avancés comme Gajim avec Gstreamer, ou dont c'est une fonctionnalité principale comme Jitsi s'en sortent mais ça reste un boulot bien plus important que sur le web.
Pourquoi ne pas faire pareil pour les clients XMPP webs ? Et bien ils le font justement, Movim gère la vidéo dans le version de dév, Jappix (qui n'est plus maintenu) le faisait également, et probablement d'autres. Quand nous nous y intéresserons dans SàT, il est fort probablement que nous implémenterons en premier dans Libervia (frontal web) avec WebRTC.
Ce que j'affirme est tout de même à prendre avec des pincettes : je n'ai pas encore travaillé moi même sur la visio-conférence, aussi mon ressenti n'est peut-être pas juste.
Même en dehors de la vidéo, il y a beaucoup de problèmes qui sont plus simples aujourd'hui à gérer parce qu'il y a plus d'outils et bibliothèques disponibles, parce qu'on a plus d'outil de messageries existants dont on peut s'inspirer.
Ensuite les objectifs peuvent être différents. Pour Whatsapp le but principal évident était (et est toujours) de monétiser. Pour Matrix, je pense que c'est assez clairement le but aussi à moyen ou long terme. Ces choix font mettre les moyens et les priorités dans l'esthétique, les fonctionnalités populaires et le marketing, et on se retrouve avec X applications qui font peu ou prou la même chose et se ressemblent fortement, et qui plaisent parce que les gens s'y retrouvent.
Selon les projets, les objectifs peuvent être très différents (j'allais élaborer un peu là dessus, mais je manque de temps donc je vais finir ce message sur cette remarque).
[^] # Re: partage d'images
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche ChatSecure 4.0 ronronne et adopte OMEMO . Évalué à 3.
le transfert de fichier est possible via Jingle, mais pas avec plusieurs destinataires en même temps.
C'est HTTP upload qui est utilisé dans ce cas (avec apparemment un chiffrement spécifique à Conversations dans certains cas).
Ce tableau est d'ailleurs incorrect, puisqu'il n'y a pas de méthode de transfert de fichier standard à l'heure actuelle avec OMEMO (il est plus ou moins au même point que OX de ce côté, avec une protoXEP en plus mais non officielle).
[^] # Re: partage d'images
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche ChatSecure 4.0 ronronne et adopte OMEMO . Évalué à 3.
bon je rectifie, j'avais mal compris. Le fichier est envoyé normalement sur le HTTP upload, mais la clef de déchiffrement est mise dans la partie « fragment » (après le « # ») de l'URL. Du coup pas besoin d'un HTTP upload spécifique, et les clients qui gèrent ça vont avoir le fichier, pour les autres il sera illisible.
[^] # Re: Chiffrement de conversations
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche ChatSecure 4.0 ronronne et adopte OMEMO . Évalué à 3.
Le chiffrement de point à point (
client <==> serveur <==> MUC (conversations de groupes) <==> autres serveurs <==> autres clients) est effectivement obligatoire dans XMPP depuis plusieurs années. Le chiffrement de bout en bout est principalement utile si tu n'as pas confiance en l'un des entités entre toi et ton/tes contact(s) (donc ton serveur, le service MUC, et un des serveurs de tes correspondants).Dans le cas par exemple ou tu communiques avec un ou des proches sur le serveur que tu gères toi même (avec le service MUC très probablement sur la même machine), le chiffrement de bout en bout n'est pas utile.
[^] # Re: partage d'images
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche ChatSecure 4.0 ronronne et adopte OMEMO . Évalué à 3.
Apparemment il utiliserait une méthode de chiffrement avec clef dans l'URL, le problème est que ça n'est pas standard et ça demande un HTTP upload spécifique, ça ne marchera donc pas avec n'importe quel serveur.
[^] # Re: partage d'images
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche ChatSecure 4.0 ronronne et adopte OMEMO . Évalué à 3.
t'es en train de dire que Conversations est capable d'envoyer un message chiffré à plusieurs personnes en même temps ? T'es certain de ce que tu dis ?
Parce qu'à l'heure actuelle, tu peux utiliser Jingle (avec l'utilisation d'OMEMO – ce qui n'est pas standard pour le moment – comme je l'ai expliqué plus bas), mais ça n'est possible qu'entre 2 contacts, ou HTTP upload qui stocke le fichier en clair sur le service (mais la transmission est chiffrée via HTTPS), et il n'y pas (encore) de méthode (standard du moins) pour chiffrer le fichier.
Du coup je suis très étonné par ce que tu dis, est-ce que j'ai mal compris ou est-ce que tu dis bien qu'il est possible de chiffrer un fichier pour plusieurs destinataires en même temps ? Si oui ça marche pour gros et petits ? Tu fais comment (je testerai pour être sûr) ?
Gajim gère HTTP upload donc il est possible de partager un fichier, mais je veux bien que ça ne fonctionne pas avec Jingle vu que Gajim utilise une version obsolète (et conversation ne gère probablement pas Stream Initiation, ce qui n'est pas plus mal).
[^] # Re: Olm vs libsignal
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche ChatSecure 4.0 ronronne et adopte OMEMO . Évalué à 3.
J'ai fait une belle faute surtout (saine) :)
Il y a eu une petite tension entre Matrix et la communauté XMPP l'année dernière (et un peu l'année d'avant), parce que pour se faire connaître ils se sont mis sur un angle d'attaque très agressif envers XMPP, que ce soit dans les interventions (par exemple au FOSDEM il y a 2 ans, là où j'ai entendu parler d'eux la première fois d'ailleurs) ou par écrit.
Le problème n'est pas tant la critique en soit, c'est aussi qu'ils ont propagé un certains nombre de fausses vérités, notamment sur leur FAQ (qui n'est d'ailleurs toujours pas terrible même si c'est mieux) au point que la communauté a dû répondre, par exemple avec cette page (ainsi que des réponses sur différents réseaux).
À ça s'ajoute des gens (a priori des groupies, même si on ne sait pas trop si c'est des gens impliqués dans le projet ou pas) qui font de la propagande systématiquement pour Matrix dès qu'un article un peu visible parle de XMPP (en particulier sur hackernews ou reddit, mais on a vu des remarques désagréables même ici). Là encore pas vraiment un problème de parler d'un projet, mais quand c'est sous pour insinuer que XMPP est dépassé (ce qui est faux) et que l'herbe est plus verte chez eux, forcément à force c'est fatiguant.
Enfin bref, maintenant que Matrix est plus connu ça s'est un peu calmé, et c'est préférable de voir qu'il est possible de collaborer.
[^] # Re: Olm vs libsignal
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche ChatSecure 4.0 ronronne et adopte OMEMO . Évalué à 7. Dernière modification le 26 janvier 2017 à 16:54.
OMEMO a été basé historiquement sur libsignal, et la première proposition de XEP a été faite avec.
Cette proposition a été rejetée parce que :
De leur côté, les gens de Matrix ont développé Olm, standardisé et sans les problèmes mentionnés, il a donc été retenu pour une nouvelle proposition de OMEMO, cette fois acceptée.
Un exemple où Matrix et XMPP peuvent collaborer, une relation un peu plus seine que ce qu'on a vu l'année dernière.
Seulement il y a un « standard » de fait avec la première version de OMEMO (pas celle de la XEP donc), car c'est celle utilisée par Conversations et tout le monde veut être compatible avec.
De son côté, Conversations est bloqué pour passer à Olm parce qu'il n'y a pas encore de bibliothèque Java.
Les nouvelles implémentations partent actuellement toutes sur la version brouillon à cause de ce standard de fait, mais il ne devrait pas être difficile de passer d'une version à l'autre une fois que tout le reste est en place (interface utilisateur, gestion des messages chiffrés, autre XEPs nécessaires à l'utilisation, etc). Il est aussi tout à fait possible de fournir les 2 versions en même temps, mais aucun client ne le fait à l'heure actuelle.
Autre changement, une documentation de Double Ratchet a été mise dans le domaine public entre temps, donc il est possible de repasser à une implémentation basée dessus. J'ai suivi cette partie de loin, mais je sais qu'il est question d'en discuter au XMPP summit qui aura lieu ce week-end.
Tout ça va rapidement se stabiliser, il y a une petite excitation sur le sujet en ce moment , mais d'ici quelques mois ça devrait être stable.
[^] # Re: partage d'images
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche ChatSecure 4.0 ronronne et adopte OMEMO . Évalué à 8.
ça dépend de ce que tu entends par là.
Le téléversement de photos fonctionne avec Gajim, Conversation (je ne sais pas pour ChatSecure) et avec une bonne partie des clients activement développés. Le problème est que sauf si tu maîtrises ton propre serveur (ou si tu fais confiance aux admins), tu ne sais pas qui peut voir ces photos, combien de temps c'est stocké, et tu ne peux pas les supprimer (ce qui est – me semble-t-il – le cas sur la plupart des plateforme de messagerie, XMPP ou pas, si vous avez des contre-exemples je veux bien des infos).
L'envoi en pair à pair est disponible au moins sur Gajim, je pense que Conversations implémente Jingle et ChatSecure je ne sais pas. Gajim malheureusement utilise une ancienne version du protocole.
Plus d'infos sur l'envoi en pair à pair dans les épisode 9 et épisode 10 de parlons XMPP.
Pour le chiffrement des fichiers en pair à pair, je crois que Conversations utilise une méthode non standard avec OMEMO (proposée à la standardisation mais pas retenue), et il n'y a pas encore de méthode standard (il y a une méthode utilisant TLS qui devrait avoir un numéro officiel mais qui semble perdue).
Enfin pour l'envoi avancé (sous forme d'album), il y a des extensions permettant un début d'implémentation, mais rien de concret à ma connaissance. Ça devrait être un de nos chevaux de bataille pour 2017 avec SàT.
# ortho
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche ChatSecure 4.0 ronronne et adopte OMEMO . Évalué à 3.
bonjour,
est-ce qu'un modo peut corriger:
On peut noter que ni Gajim, ni Conversations, ni ChatSecure n'utilise ==> On peut noter que ni Gajim, ni Conversations, ni ChatSecure n'utilise*nt*
merci :)
[^] # Re: Et le pognon ;-)
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal [radio] logiciel libre et journaliste, présentation de « Sourcefabric ». Évalué à 6.
principalement 2 sources : différentes subventions, et le support technique/développement de fonctionnalités particulières pour certains clients (on peut notamment citer AAP qui a accompagné le développement depuis le début du projet, et NTB).
Les autres projets comme Booktype ont des services payant disponibles également, mais je connais moins vu que je travaille sur Superdesk.
[^] # Re: Wire
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Silence : XMPP, chiffrement et méta‐données. Évalué à 3.
ce n'est pas forcément simple ou désirable.
À l'heure actuelle il y a 3 méthodes de chiffrement de bout en bout:
1) OTR, qui ne gère pas les appareils multiples, ne permet pas l'historique sur le serveur, et ne chiffre pas toute la stanza (seulement le corps)
2) OX (OpenPGP moderne) qui gère chiffrement de toute la stanza, appareils multiples, et archives serveurs, mais qui ne gère pas la confidentialité persistante et qui fait augmenter considérablement la taille des données
3) OMEMO qui ne gère pas le chiffrement de toute la stanza (il le fera peut-être dans le futur), qui gére les appareils multiples et la confidentialité persistante, mais qui ne permet pas les archives serveur.
Le chiffrement de la stanza complète bloque certaines fonctionnalités (le serveur a parfois besoin de savoir ce qui passe), de même que l'impossibilité d'avoir les archives sur le serveur.
D'autre part si tu as confiance en ton serveur et en celui de ton correspondant, le chiffrement de bout en bout n'est pas forcément nécessaire.
Bref, le problème n'est pas si simple qu'il parait, et le chiffrement de bout en bout par défaut n'est pas forcément souhaitable (à l'heure actuelle).
Et je passe sur le fait que les XEPs ne sont qu'expérimentales (OMEMO n'est une XEP officielle que depuis quelques jours d'ailleurs).
# Ça m'a l'air très intéressant
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Liberapay, plate‐forme libre de dons récurrents . Évalué à 10.
ce n'est pas le première fois que je vois passer ce nom, mais c'est la première fois que je lis autant d'informations dessus, dépêche très complète bravo pour la transparence !
Ça ressemble à exactement ce qu'on cherche pour Salut à Toi (dons récurrent sans contrepartie, transparence, gestion par une association à but non lucratif, et financement par votre propre système sans pourcentage indécent), bref c'est très très intéressant.
Ce n'est pas précisé dans la dépêche mais je demande par par acquit de conscience : il n'y a pas de publicité ou de publicité prévue ? Ça serait rédhibitoire pour nous car contraire à notre contrat social.
Aussi est-il possible de refuser certains mode de paiement (bitcoin si ça arrive notamment) ?
Merci pour la dépêche je vais suivre ça de très près et nous allons probablement nous inscrire si c'est aussi prometteur que ça en a l'air.
[^] # Re: Alternatives et compléments à Planet-libre ?
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Qu'arrive-t-il à Planet-libre ? [edit: en fait tout va bien]. Évalué à 3.
il y avait planète jabberfr (https://planet.jabberfr.org/) mais à part jabberfr eux même je suis quasiment le seul à encore publier là bas (la version anglophone est bien active elle par contre).
Pour ma part avec DLFP (surtout) et planet libre j'ai suffisamment pour me tenir à peu près à jour (et pour XMPP là le mieux c'est de suivre les salons et le planète anglophone).
# existant
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Tentative de financement participatif pour projet OpenSource. Évalué à 5.
Tu as l'air d'aller dans un terrain ou il y a déjà pas mal de choses, notamment demosphere :
https://lille.demosphere.eu/ (change Lille par une autre ville si tu déménages). Ça vaut sûrement le coup d'entrer en contact avec eux.
Pour le financement, réussir à payer serveur + loyer + minimum vital avec un financement participatif, c'est faisable mais très difficile.
Bon courage tout de même.
[^] # Re: Super!
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Sortie de poezio 0.10. Évalué à 4.
Gajim est très complet et les implémentations de fonctionnalités sont en général bonnes voire excellentes, c'est ma référence quand je veux tester une fonctionnalité, ils ont fait un client vraiment bon.
En fait si, on a Cagou notre nouveau frontal qui tourne déjà sur bureau ( https://www.goffi.org/blog/goffi/ddc8d18f-bae7-4929-8af8-fe51b8d80323 ) et le port Android est en cours : encore quelque problèmes à régler mais ça se lance.
Il n'est pas super joli pour le moment parce qu'il faut d'abord qu'il tourne bien avant de s'occuper de la peinture, mais il sera clairement là pour notre prochaine version (et j'espère qu'une version au moins alpha sortira avant la fin d'année).
[^] # Re: L'histoire se répète
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Ceci est un lancement de chatons. Évalué à 10.
ceseraitquandmêmetrèscondeperdretonpari:/
[^] # Re: Super!
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Sortie de poezio 0.10. Évalué à 6.
Je crois que depuis quelques temps, on peut vraiment pas dire que ça stagne : https://linuxfr.org/tags/xmpp/public
[^] # Re: Super une nouvelle version !
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Sortie de poezio 0.10. Évalué à 4.
certains terminaux permettent d'afficher des images (comme Terminology), c'est peut-être sortir un peu du principe du terminal, mais ça peut valoir le coup d'y jeter un œil : https://www.enlightenment.org/about-terminology
# Bravo
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Sortie de poezio 0.10. Évalué à 8. Dernière modification le 12 octobre 2016 à 11:44.
Bravo pour votre super boulot, et content de voir la XEP-0070 se répandre, hâte de voir le plugin mediawiki.
Petite remarque, pour moi Poezio est un client console et pas ligne de commande, vous faites du ncurses (comme Vim ou Mutt), la ligne de commande c'est uniquement une commande dans un shell (comme ls ou grep). Enfin c'est un détail.