Goffi a écrit 1559 commentaires

Ah ça serait super ! Je ne sais pas si c'est nécessaire de garder un truc spécifique à Libervia, ça dépend si l'API risque de changer fréquemment ou pas.

Il faut que je me replonge dans la spéc, le problème est que j'étais un peu pressé par le temps et que j'ai fait plusieurs sessions Jingle (la partie XMPP qui gère les sessions) en me calquant sur ce que faisait Galène, et il faudrait que je revois ça pour que ça fonctionne avec une seule.

Il va falloir que je me replonge dans tout ça. Là je suis en train de fini un autre projet de passerelle email <=> XMPP, et après je vais essayer de mettre ça à jour. On pourrait s'organiser un appel (via Galène bien sûr :) ) ou un chat d'ici 2/3 semaines si ça te va ? Le temps de me laisser finir le travail en cours, et de me remettre dedans.

Salut,

je n'ai pas encore eu le temps de regarder les changements (très pris par ailleurs), mais je voulais surtout te dire merci pour le travail sur Galène. C'est un super logiciel qui s'installe facilement et qui marche bien.

J'ai implémenté un composant XMPP qui l'utilise pour faire des visioconférence en grand nombre (dans le projet Libervia, grâce à une subvention NLnet). J'avais proposé une spécification correspondante, mais on m'a demandé de faire des modifications. Je vais m'y remettre dès que possible pour corriger et la reproposer, et adapter l'implémentation aux changements récents.

Bonne continuation.

Sauf erreur, Dino permet la visio via Muji, c'est à dire en Mesh. En gros, ça signifie que tou·te·s les participant·e·s s'appellent en pair-à-pair. C'est une méthode valable pour un petit groupe de personnes (au doigt mouillé, c'est bien jusqu'à 5/6). Ça a aussi l'avantage de ne rien demander côté serveur de plus que ce qui est déjà utilisé en appelle 1:1.

Une des autres méthodes, c'est via un composant qui permet de sélectionner les flux à transmettre, ce qu'on appelle un SFU. C'est souvent ce qui est utilisé pour les grosses conférences de nos jours, notamment par Jitsi, car c'est efficace.

À ma connaissance, Dino ne gère pas ça à ce jour. Il y a du travail en cours dans plusieurs projets, notamment en utilisant Galène, et du travail sur les spécifications également. Il me semble qu'il y a une implémentation OpenFire.

Movim qui bénéficie actuellement d'une subvention pour la visio, a implémenté Muji (Mesh donc) et va aussi implémenter les appels via SFU.

J'ai moi même bénéficié d'une subvention pour ce travail sur Libervia, aussi Libervia implémente Muji, SFU, et un composant serveur permettant d'utiliser Galène. J'ai aussi proposé une spécification, mais on m'a demandé de faire des changement et de la reproposer, ce que je n'ai pas eu le temps de faire jusqu'ici parce que je travaille seul sur un million de choses.

Sur mobiles, à part Movim qui est une PWA et fonctionne donc sur ces appareils, je n'ai pas connaissance d'équipes qui travaillent dessus, mais je ne suis pas les clients mobiles de très près. Libervia web va également être une PWA, donc ça sera une autre option.

Ce n'est pas une limitation des clients, c'est une limitations des ressources disponibles : gérer les appels en visio avec un gros groupe demande de revoir complètement l'interface, et de gérer de nouveaux problèmes. La plupart des équipes qui travaillent sur des clients XMPP sont petites (souvent une seule personne) et souvent sur leur temps libre.

Et bien sûr il y a toujours Jitsi qui est basé sur XMPP et est probablement une des meilleures options pour les appels quelle que soit la plateforme.

Pour l'instant pour les téléphones, je n'ai rien trouvé qui coche tout. En dehors de Kivy, BeeWare a l'air intéressant et utilise des composant natifs, ce qui règle le problème de l'accessibilité. Ça me semble OK quand on part sur un nouveau projet, mais le port de Libervia ne serait sans doute pas faisable (je ne crois pas que les dépendances qui ne sont pas pure python sont utilisables, il me semble que seul python-for-android permet de les utiliser).

PyQt semble pouvoir tourner sur plateformes mobiles avec PyQtDeploy, mais je n'ai pas creusé plus que ça pour le moment. PySide avait une solution avec un fork de Python-for-Android mais ça ne semble plus maintenu.

Il y a Flet qui permet d'utiliser Flutter avec Python, mais je pense qu'il faudrait avoir un serveur distant (ce que je pourrais faire avec le serveur HTTP de mon frontend web). On ne serait plus sur du natif, et ça bloquerait les fonctionnalités.

Bref, pour le moment je me concentre sur le frontend web, et je vais faire du PWA pour avoir une solution viable sur plateformes mobiles rapidement. Mais ça n'est pas suffisant pour du long terme, surtout sur iOS : même si les notifications push sont désormais possibles, d'après ce que j'ai compris c'est impossible de faire une gestion correcte des appels entrant.

Il y a des solution intermédiaires, type Tauri avec le frontend web, ou une webview avec Python-For-Android (et faire tourner le backend sur l'appareil), mais c'est probablement trop fragile, et on va retrouver certains problèmes actuels, comme le temps de chargement.

Sur du (très) long terme, j'envisage très sérieusement de porter de grosses parties du backend en Rust, ce qui permettrait de compiler nativement pour Android et iOS (et WebAssembly). Pour l'UI, une solution type Flutter ou Kotlin Multi Plateform (KMP) sont dans mon radar.

Tant mieux si c'est corrigé. Quand j'avais testé (sur Pinephone avec Plasma Mobile) ça ne fonctionnait pas, et je ne pouvais lancer l'interface qu'avec XWayland (avec le rendu Xorg donc), et ça ne répondait pas bien du tout, c'était inutilisable.

Le détail que ce ticket (toujours ouvert, si ça a été corrigé, c'est donc indépendamment) : https://github.com/kivy/kivy/issues/7367

Merci, et réponse envoyée (mais pas à l’expéditeur, je n'ai vu ce journal qu'après coup).

Avec les propriétés, comme expliqué dans la dépêche, tu peux déjà faire un rendu dépendant de l'état.

Je n'ai pas poussé l'exemple trop loin pour ne pas rendre la dépêche trop indigeste, mais tu peux utiliser des conditions dans les valeurs. Par exemple dans mon client XMPP, je m'en sers pour afficher un avatar par défaut si je n'ai pas d'avatar pour l'entité, ou pour afficher une couleur de cadenas différente en fonction de l'état du chiffrement.

Exemple:

        MessAvatar:
            id: avatar
            source: root.mess_data.avatar['path'] if root.mess_data and root.mess_data.avatar else app.default_avatar
            on_press: root.chat.add_nick(root.nick)

Ce code créé un widget MessAvatar, et affiche l'avatar par default si aucun avatar n'est déclaré. Il ajoute aussi un handler pour mettre le surnom de l'utilisateur en cas de clique. En python, ça serait plus long à écrire, et un peu moins lisible.

Si tu dois ajouter/enlever dynamiquement des widgets, il faut passer par python, mais tes widgets peuvent être complètement déclarés dans kv, même si ajoutés ensuite dynamiquement.

À l'usage c'est très pratique, et c'est pas pour rien que ce n'est pas le seul framework à faire ceci (je pense à QML avec Qt par exemple).

C'est en complément, tu utilises toujours python à côté. Kv et son côté descriptif pour faire le squelette de ton UI c'est vraiment rapide est agréable.

Et c'est assez propre aussi d'avoir la partie UI pure séparée du code.

Après c'est vrai qu'aujourd'hui avec les dataclasses et Pydantic, on pourrait avoir un résultat similaire en restant en python (mais tout ceci n'existait pas quand Kivy a été conçu).

Si je comprends bien, tu perds tout le contenu à moins que tu ai fait une copie préalable ?

• Tu peux mettre en place une synchro automatique entre des dépôts facilement.
• Tu as une copie en local des dépôts sur lesquels tu travailles, et possiblement des tickets selon ton client (Libervia utilise un cache par exemple, tu peux retrouver à partir de là).

Ça va paraître provocateur mais est-ce que c’est pas plus simple :

• d’avoir un format d’export/import standard et de l’implémenter dans autant de forge que possible voir de faire des > outils pour les forges récalcitrantes
• de proposer une authentification OAuth avec la clique habituelle + github, gitlab, linuxfr,…

• Le format d'export standard, c'est la spéc XMPP.

• OAuth (qui est d'ailleurs supporté par XMPP) ne gère que l'authentification, et souvent tu as un compte en local qui est recréé. Ça n'est pas pareil qu'avoir tout le système décentralisé, avec les informations d'identité (vCard, avatar, etc), les clefs de chiffrement, les permissions, la possibilité de lier facilement des éléments ailleurs, l'inscription et les notifications, etc.
  Si je pouvais me connecter à Github avec mon compte linuxfr, ça ne changerait pas grand chose au fait que je ne peux pas facilement forker sur un autre serveur, lier un ticket, etc.

Tu compliques un peu, décentralisé ne veut pas dire avoir les commentaires distribués partout et reconstruire un truc cohérent après coup (ça peut vouloir dire ça si on veut, mais ça peut être beaucoup plus simple).

Dans le cas de XMPP, c'est le serveur pubsub du dépôt principal qui gère les tickets et tout (numéro de ticket, de merge request, etc), c'est un peu comme une mini forge centralisée. Donc tu peux modérer en cas de comportement incorrect ou de spam.

L'intérêt par rapport à une forge centralisée comme Github c'est que:

• c'est un compte XMPP, donc l'authentification est gérée par le mécanisme XMPP, donc le serveur de la personne qui contribue. Pas besoin de créer un compte sur chaque forge.

• Si une forge veut supprimer un projet (comme c'est déjà arrivé plusieurs fois sur Github, avec yt-dl par exemple), il est très facile de le passer sur une autre, et les contributeurs et contributrices peuvent continuer sans changer leur compte (en changeant uniquement l'adresse de la forge).

• Les tickets peuvent être clonées et mis sur une autre forge, c'est de simples nœuds pubsub à cloner.

• Git et Mercurial sont déjà décentralisés, donc pareil, il suffit de cloner pour aller ailleurs.

Bref, sur ta forge tu es chez toi et tu la gères comme tu l'entends. Comme une mini forge centralisée, à la grosse différence près c'est qu'il est très facile de passer sur une autre en cas de problème (technique, politique, etc.), sans avoir à recréer de compte pour les contributeurs et contributrices.

Github a un effet réseau énorme qui limite l'intérêt des petites forges parce que les gens ont la flemme de créer un autre compte, et que ça n'est pas possible/simple de faire des liens entre des tickets/des pull requests/autre sur d'autres forges.

Avec XMPP, chacun peut faire sa propre forge, et c'est l'équivalent un gros service en groupant plein de petits , on peut communiquer et lier facilement les choses entres elles. Je suppose que ce qui est fait avec ActivityPub est plus ou moins similaire (mais encore une fois, je n'ai pas suivi de près, vu que la roue est plus ou moins réinventée, encore une fois).

Courage, Libervia mérite tes efforts!

Merci :)

Ah tu parles spécifiquement des projets liés à ça, je pensais que tu critiquais tout le système NLnet/NGI. Dans le cas précis des forges basées sur ActivityPub, je n'ai pas suivi de près (j'avais été contacté vite fait quand ça a été commencé, puis XMPP ne les intéressait illes ont préféré refaire avec AP).

S'il y a de la demande, je ne serais pas contre intégrer ça à la passerelle AP<=>XMPP un jour (si c'est raisonnablement faisable), mais en attendant, XMPP rempli toutes les cases au moins pour moi.

Alors je fais en général les choses de manière générique, de façon a pouvoir changer de backend, et Libervia est extensible (je suis en train de travailler sur cette partie là aussi, et sur la doc) donc il peut il y avoir des contributions tierces et il sera sans doute possible de gérer d'autres VCS.

Par contre, si je veux passer à Git, c'est parce que c'est le VCS de référence incontestable. Pour d'autres options, ça ne sera pas dans l'immédiat, je n'ai pas actuellement les ressources (je suis complètement sous l'eau).

NlNet et co qui servent quand même souvent de vache à lait pour avoir des thunes et rien faire de substantiel

Alors je suis moi même bénéficiaire de subvention NLnet/NGI (j'en ai eu plusieurs), donc je ne suis pas neutre. Mais dire un truc pareil c'est franchement insultant autant pour le boulot de fou qu'ils et elles font, et pour les bénéficiaires.

Quand une subvention est acceptée (après une validation de plusieurs mois en 2 étapes, 1 première sélection suivie d'une deuxième avec des questions aux projets), on a un appel en visio pour présenter les choses, et on se met d'accord sur un "Memorandum of Understanding". Ça n'est pas un contrat (on n'est pas employé·e·s) mais c'est un accord sur les étapes à faire avec des livrables (une merge-request par exemple) et les sommes demandées. Ces étapes sont proposées par le projet et validées par l'équipe de NLnet, et la sommes des étapes doit correspondre au total accordé.

On ne reçoit rien si on ne fait rien, il faut finir une étape, et ensuite c'est vérifié, et enfin payé, ce qui peut mettre jusqu'à 3 semaines (et je me suis d'ailleurs plusieurs fois retrouvé mal parce que j'avais sous estimé — Comme tout développeur·se qui se respecte — le temps qu'il fallait pour une étape). Ça arrive d'ailleurs qu'on ne puisse pas finir toutes les étapes avant la fin du programme, et alors une partie de la somme accordée est perdue (ça m'est arrivée sur ma première subvention).

Alors il est fort possible, que sur tous les projets financés, certains n'ont pas fait toutes les étapes, et la subvention n'a pas donné ce qui était attendu (encore une fois ça n'est pas un contrat, il n'y a pas d'obligation, on ne reçoit juste par l'argent si les choses ne sont pas faites). Mais je vois énormément de projets, dont certains que j'utilise régulièrement, qui ont pu se développer grâce à NLnet/NGI, et d'ailleurs dans le monde XMPP il y a pas mal de spécifications qui ont vu le jour grâce à ça, et plusieurs logiciels qui ont pu se développer.

NLnet/NGI ont donné et donnent toujours un aide énorme à des tonnes de projets, et il y a de bonnes chances que celles et ceux qui me lisent en bénéficient via un projet financé.

C'est une des meilleures choses qui est arrivée au logiciel libre ces dernière années (et je suis loin d'être le seul à le dire).

On utilise les mêmes extensions oui, et on se connaît, si quelque chose ne fonctionne pas, on cherche à corriger.

Libervia gère aussi le blogging/microblogging, et c'est déjà implémenté dans la passerelle AP<=>XMPP (les messages directs sont convertis en messages de chat, les message publics sont convertis en blogs XMPP et vice versa).

Je suis justement en plein redesign, et il est fort probable que je passe finalement à Git, de plus en plus d'outils ne prenant en compte que Git (notamment uv qui devient la référence en Python). C'est dommage, Mercurial est vraiment un bon outil, et plus intuitif que Git.

C'est ce que je fais avec XMPP pour mon projet Libervia depuis des années  : une forge (enfin pour le moment des tickets et un système de merge requests) décentralisée, et accessible avec tout compte XMPP. C'est basé sur Pubsub, ça veut dire que de nombreuses chouette fonctionnalités sont possibles, comme le chiffrement de bout en bout (pour faire un ticket sensible, comme un rapport de bogue sur une faille de sécurité par exemple).

L'idée a été reprise pour ActivityPub avec ForgeFed. J'ai également une passerelle ActivityPub <=> XMPP, il est possible, si je trouve les ressources, d'ajouter une compatibilité pour ces fonctionnalités à terme.

Si tu veux que le serveur n'ait pas accès au contenu d'un groupe (MUC), il te faut du chiffrement de bout en bout. C'est en général OMEMO qui est utilisé, et pas mal de clients l'activent par défaut. Les salons peuvent être publics ou caché, ouverts à toutes et tous, ou accessible uniquement aux membres.

Pour monter facilement un serveur à héberger soit même, tu peux utiliser Snikket qui est maintenu par l'équipe de Prosody, et qui a des apps du même nom sur Android et iOS (mais qui fonctionne avec n'importe quel client XMPP).

"c'est null, ça marche pas"

Alors ça c'est un cas d'école de faute de développeur·se ! 😃

Ça avance oui, mais effectivement pas facile tous les jours. Je vais sans doute écrire un billet de blog à l'occasion pour faire le point.

En tout cas c'est vraiment chouette pour GIMP 3, sortir une telle version après des années de boulot, c'est quelques chose.

Bravo pour cette release et pour avoir tenu sur la longueur !

Vaut mieux attendre un mois ou deux, je suis en plein travail sur le design. Je ferai une annonce ici à la sortie de la prochaine version, ça sera le bon moment pour tester.

Il y a des clients spécialisés, notamment il y a Prose qui cible précisément ça : https://prose.org/ . Le chat professionnel est aussi un cas d'utilisation que je cible avec Libervia.

Mattermost apporte plus facilement des fonctions de travail en équipe (par exemple les wokflows)

Peux-tu me décrire précisément ce que c'est/me donner un cas d'utilisation concret ? J'ai des fonctionnalités d'automatisation dans ma TODO list, et du coup ça m'intéresse d'avoir des cas concret d'utilisation pour être sûr que ça aide.

Le problème principal, c'est que la plupart des clients sont développées par de très petites équipes, et la plupart du temps par des personnes seules. Peu de développeurs/développeuses de clients XMPP sont financé·e·s. NLnet/NGI ont fait beaucoup de bien de ce côté, mais il faut un modèle plus pérenne pour maintenir de tels logiciels et avoir les ressources pour rentre le tout agréable à utiliser, accessible, et complet.

De gros progrès ont été faits ces dernières années, et il y a des projets (dont Libervia sur lequel je travaille) qui cherchent à avoir un modèle viable sur le long terme.