Goffi a écrit 1537 commentaires

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.

Il y a une petite coquille dans le code aussi, le / manque dans le deuxième exemple de « Arguments exclusivement positionnels »:

def f(a, /, **kw):
  print(a, kw)

f(0, a=1)  # valide ! Affiche: '0 {"a": 1}'

Merci pour la dépêche en tout cas, elle résume bien sans aller dans tous les détails comme l'annonce officielle.

Python 3 est une énorme amélioration et c'était une bonne chose de le faire (rien que la gestion des strings/bytes et le unicode par défaut justifie Python 3). Mais la migration n'a pas été simple, et n'avait pas nécessairement à être gérée immédiatement par tout le monde.

Comme je le dis plus haut, pour ma part je suis content d'avoir eu le support étendu et de faire la migration maintenant, j'aurais eu beaucoup plus de mal il y a quelques années, voire ça n'aurait tout simplement pas été possible (et à lire en diagonale les commentaires sur hacker news c'est le cas pour beaucoup de monde).

Aussi quand on lit que Python 3 est dispo depuis 10 ans, c'est un peu oublier que les premières versions de Python 3 étaient loin d'être parfaites, et que certaines fonctionnalités manquaient (comme les formatage avec % sur les bytes, que j'ai déjà mentionné plus haut).

Bref, il faut aussi faire confiance au développeurs, si certains ont attendu (et j'en fait partie), il peut y avoir de bonnes raisons derrières.

Surtout que la migration n’était quand même pas bien compliquée.

Tu t'avances fort là, peut être que ça n'était pas compliqué dans ton cas, mais il y a des cas où c'était franchement pas simple (Twisted et Mercurial par exemple). Il faut noter aussi qu'il y a des améliorations arrivées plus tard qui bloquaient des migrations auparavant (le % formatting sur les bytes par exemples, il me semble que ça a fortement aidé à la migration de Twisted), et des dépendances qui pouvaient manquer.

Aucun. Fallait migrer il y a longtemps. Genre il y a dix ans. T’aurais eu moins de boulot. ;)

Bien au contraire, j'ai fait la migration récemment et j'ai eu moins de boulot parce que j'ai attendu (je n'avais de toute façon pas tellement le choix). D'une part certaines dépendances n'étaient pas prêtes, et d'autre part des fonctionnalités de Python ou de la bibliothèque standard n'existaient pas ou n'étaient pas aussi complètes qu'aujourd'hui (asyncio par exemple, même si ça n'est pas indispensable au passage Python 3, ça simplifie de pouvoir faire ça en même temps maintenant).

Il y a aussi des projets qui n'ont tout simplement pas pu être portés sur Python 3. C'est le cas de Pyjamas, un transpileur Python => JavaScript. On utilisait ce projet et on a dû jeter une bonne partie du code. Il y a probablement des cas similaires qui ont dû refroidir les envies de passer à Python 3 rapidement.

Et bien sûr, plus on attend, plus on a de chances que les plâtres aient été essuyés.

ah ben je vois que c'est déjà changé, merci aux modérateurs (et merci aussi pour le passage en article de tête :) ).

c'est du SVG, du coup je suppose qu'il prend le max-width. C'est parce que je n'avais pas utilisé d'image dans la première partie que le logo SVG s'est retrouvé là. Si ça pose problème il y a :

• une version PNG en 128x128 
• n'importe quelle autre capture de la version 0.7 peut faire l'affaire, cf. https://repos.goffi.org/sat_docs/file/tip/screenshots/0.7 . Le chat par exemple (même s'il n'est pas encore très élaboré) : 

Sinon peut-être qu'il est possible de limiter la taille du SVG ? Si c'est possible c'est sans doute le plus simple.

Salut,

il y a plusieurs choses qui me motivent, on peut citer en vrac et sans exhaustivité le plaisir de créer et voir évoluer quelque chose, de mettre en pratique des idées, la motivation politique (comme ne pas abandonner et laisser le champ libre aux grosses boîtes avec peu ou pas d'éthique, et qui contrôlent et surveillent déjà trop), l'utilisation personnelle (je l'utilise et je souhaite avoir un outil qui me plaît et que je peux utiliser avec mes proches), une certaine habitude aussi, et ne pas vouloir jeter des années de travail. Il y a des hauts et des bas, mais la motivation baisse rarement dans mon cas. Et puis je sais aussi où je vais, ça aide beaucoup.

Est ce que ça n'empiète pas trop sur ta vie de famille ou d'autres choses importantes?

ça a des conséquences sur la vie de famille oui, j'ai un rythme assez soutenu (en pratique je bosse entre 1 et 2 h chaque jour avant le boulot et plus rarement le soir, j'ai une journée dédiée qui n'est donc pas payée, et je travaille parfois le week-end, sans compter les cas exceptionnels comme les événements type FOSDEM), mais heureusement j'ai des proches compréhensifs, et je fais attention à garder du temps pour eux (et aussi pour les tâches ménagères et administratives).

Il y a des choses qu'il faut mettre de côté (ça fait des années que je veux me mettre à l'Arduino par exemple, mais je dois faire des priorités), et d'autres qu'il faut garder coûte que coûte comme aller en extérieur ou faire un peu de sport (ça je ne le fais pas assez par exemple).

Ça a des conséquences sur la santé aussi : le fait de faire ça en plus de mon travail salarié qui est aussi sur un écran, ça amène des migraines, des douleurs de dos ou de poignets, ça fatigue (abîme ?) les yeux et le corps en général. On peut limiter un peu en s'adaptant (écran spécifique, travailler debout de temps en temps, faire des pauses), mais ça reste malsain.

Est ce que ça vaut le coup?

Je pense oui. Déjà le projet en lui-même je le vois évoluer et arriver où voulu. C'est une brique essentielle pour d'autres projets que j'ai en tête et qui sont désormais possibles. Ensuite sur le plan personnel ça apprend beaucoup de choses (techniques, mais aussi de gestion de temps et de projet, de communication, etc). Sur le plan professionnel c'est aussi un atout : j'ai la chance de ne jamais avoir eu à envoyer plus d'un CV pour trouver du travail, et je pense que c'est en bonne partie dû à mes projets en ligne. Donc même si le projet tombait à l'eau (ce qui n'est pas du tout à l'ordre du jour), il aura été utile.

Qu'en penseras-tu dans 10 ans?

Ça on verra, si je suis encore là (on n'est pas à l’abri d'un accident ou d'une maladie).
Ce qui est sûr c'est que je vais devoir limiter le rythme à un moment si je n'arrive pas à en faire mon travail principal, mais j'ai bon espoir vu les progrès récents et les indices qui montrent un certain intérêt pour ce projet.

oui ça peut être une solution :). Plus sérieusement il faudrait que j'évite de relancer un serveur pendant que je fais autre chose à l'avenir, et que je revois un peu la procédure de maintenance (jusqu'ici le serveur étant uniquement là pour la démo, les mises à jour et autres opérations de maintenance étaient un peu aléatoires). Un serveur de secours ne serait pas une mauvaise chose non plus.

Non non c'est de ma faute, j'ai voulu relancer le serveur à cause d'un petit soucis de ralentissement (peut-être dû à LinuxFr), j'ai fait un systemctl stop qui a pris du temps… et que j'ai oublié.

J'avais beaucoup aimé le livre de Dimitri Robert (Eyrolles) pour GIMP 2.8, je ne sais pas s'il y a eu une mise à jour pour 2.10, j'avais même écris un journal à ce sujet : https://linuxfr.org/users/goffi/journaux/gimp-ca-dechire . Je recommande (et pour ma part je préfère nettement la lecture d'un bouquin papier qu'un tuto ou de la doc sur un écran, et même une liseuse).

la sous-section est une bonne idée en effet. Sinon ça ne me semble pas choquant d'avoir :

• lien 1 (fr)
• lien 2 (fr)
• lien 3 (en)

C'est du texte qu'il faut utiliser, il y a des dénominations standards, et c'est accessible.

Voici un article trouvé sur le web qui résume le problème : https://blog.axe-net.fr/choix-langue-site-web-drapeaux-textes/

Tu n'es pas à l'abri non plus d'une cassure entre deux versions, ça arrive souvent mais ça se gère (python2 > 3, etc.). Je l'ai vécu pour Qt… j'ai pleuré mais au final ces outils m'ont fait tellement gagné de temps que le reste est négligeable.

Je suis justement en train de faire le port Python 3, bien que je sois en vacances. On a eu le tour aussi avec Pyjamas (transpileur Python => JavaScript) et certaines incompatibilités dans les bibliothèques utilisées par-ci par-là, du coup on y fait attention aux dépendances. Le problème d'un système existant comme Bulma ou Bootstrap c'est qu'il faut s'adapter à la logique, or dans le cas d'un framework CSS, c'est pas tellement la mer à boire de faire le sien, et ça permet le sur mesure.
Au passage Twisted est un modèle là dessus, c'est vraiment stable, le code fait il y a dix ans fonctionne toujours sans soucis.

J'avais oublié un petit point : je pense que donner des noms aux différents outils est une mauvaise idée car cela embrouille encore plus le message ; Cagou, ça ne me dit rien. SàT est un nom, connu, un concept, qui contient des sections par exemple "chat", "forum", "tickets" … donc autant l'utiliser partout, ton projet gagnerait en visibilité (moteurs de recherche etc.).

Oui c'est pas la première fois qu'on nous fait la remarque. Dans la communication je mets quasi systématiquement (SàT) après un nom, mais il faudrait sans doute voire à toute renommer. On a déjà débattu de ça en assemblé générale (on fait des assemblées publiques une fois par an pour décider des grandes lignes) et on avait parlé de faire un sondage pour les noms, il faut que je pense à m'en occuper.

Salut,

pour la manque de contributions il y a plusieurs facteurs : déjà des choix politiques (pas de présence sur Facebook, Twitter ni même Github), ensuite des erreurs stratégiques (sorties des versions trop rares), un mauvais timing (j'ai débuté avec SàT quand les smartphones ont commencé à décoller, et la 0.7 sortie la semaine dernière est la première à avoir une version pour Android), un éparpillement en effet, et sans doute un peu de manque de chance. Il y a quand même une (petite) communauté qui s'est formé et quelques contributions.

Pour répondre à tes points:

en premier, je dirais qu'il est difficile à décrire. Il fait tout, mais a l'air de tout faire mal ou moins bien que n'importe quelle application dédiée (tu indiques souvent les manques ou les "j'y ai pensé" ou "ça arrivera" ou "oui on peut faire ça mais faut coder" etc.). Je pense que ça montre un manque de "ligne directrice" et envoie un mauvais message : je suis codeur moi même, je peux transformer n'importe quel logiciel en messagerie en ajoutant des librairies. C'est pas le but.

Oui difficile à décrire en effet (un peu moins ces dernier temps, écosystème de communication me semble relativement approprié).

Par contre, je ne pense pas qu'il fait tout « mal ou moins bien », loin de là. Ça n'est pas parce que ça n'est pas dédié à une tâche que c'est mal fait.

Je pense que le travail de simplification commencé avec cette version commence à rendre les fonctionnalités agréables, et la cohérence (même interface, même façon de configurer, même compte, etc.) est un atout que tu n'auras pas en regroupant des applications dédiées différentes.

Il faut aussi voir que ce ne sont pas des choses tellement différentes : au niveau du chat par exemple, tu t'attends à avoir plus ou moins du partage de fichiers, voire de la visio-conférence. Le blog me semble relativement proche et cohérent avec le chat, et le forum est une vue différente du blog. Il y a d'autres fonctionnalités faites pour des besoins persos ou liés au projet (comme les tickets et merge-requests), mais ça n'est pas ce que je souhaite mettre en avant, c'est plus du bonus.

La base est commune : c'est pratiquement tout le temps du pubsub, des commentaires, et un type de vue. Après les améliorations profitent à tout le monde : quand la recherche en texte intégral sera implémentée (« full text search »), elle sera utilisable d'un coup par toutes les fonctionnalités basées sur pubsub. Les outils mis en place sont génériques et réutilisables.

D'autre part, quand je compare avec ce que j'utilise dans mon travail salarié, SàT n'est pas loin d'avoir tout ce que j'utilise typiquement dans une journée (même si un outil utilisé dans mon boulot peut avoir des tonnes de fonctionnalités, au final je n'en utilise qu'une petite partie dans mon processus de travail quotidien).

Donc non je ne pense pas faire mal ou moins bien, je pense faire différent, dans une autre philosophie.

Ensuite, l'aspect … qui reste très austère. Il faut dire ce qui est : cela n'aide pas.

C'est vrai, mais il y a eu des efforts fait dessus (et de l'écoute sur les commentaires que j'ai reçu). La première capture d'écran par exemple, tout en haut (le tchat sur Cagou pour Android), tu trouves ça vraiment austère ? Ça ne me semble pas tellement éloigné de ce qu'on trouve dans la plupart des applications de tchat de nos jours.

Enfin, je ne vois pas ce que ton logiciel m'apporterait. Je suis déjà super équipé dans tous les éléments que tu proposes.

Peut être que ça n'est pas l'outil pour toi, très bien si tu as déjà tout ce qu'il te faut, c'est vraiment pas notre truc la création de besoin. C'est un outil accompagné d'une certaine philosophie (cf. contrat social, mais aussi le discours qu'on a sur l'éthique et la vision critique des technologies) ce qui est je pense assez rare sinon unique. C'est aussi un projet qui expérimente sur plusieurs points (techniques — comme l'architecture, en fonctionnalité, en interface, etc.), l'avenir dira s'il a sa place ou pas.

Une réduction des fonctionnalités, ou des "cibles" qui prennent du temps (genre une version desktop, android, console etc.). Je ne ferai qu'une seule version, web par exemple, responsive donc adapté au mobile et totalement portable (via un Electron pour le desktop, ou pas). En fournissant une API type REST, ton logiciel reste ouvert.

On réfléchit en effet à se concentrer sur certaines fonctionnalités. On a déjà une version web « responsive ». Les différents frontaux ne sont pas ce qui demande le plus de travail, il y a beaucoup de choses factorisées, et l'architecture du projet est une de ses forces. Je ne suis pas persuadé que faire uniquement du Web/JS avec Electron soit une bonne solution même si c'est la mode aujourd'hui (d'ailleurs en XMPP il y a déjà Movim qui fait exactement ce que tu décris).

Une refonte graphique : quand on est codeur et non graphiste, autant se tourner vers un framework qui-rend-beau (bootstrap …) sans trop d'effort.

Oui c'est un option qui a été étudiée (notamment Bulma et KivyMD), il n'est pas impossible d'y passer à terme, mais il faut voir qu'il y a aussi des contraintes et des risques à évaluer (par exemple Bulma est à ma connaissance maintenu par une seule personne, que se passe-t-il si on se base dessus complètement et que c'est arrêté ?).

Peut-être que ton logiciel gagnerait en visibilité en le fournissant en mode SaaS : on crée un compte, on a un accès à tout ce que tu proposes, avec version payante si on veut du stockage … oui du coup ça centralise, mais n'importe qui pourrait se créer un serveur sur un PI en fournissant les paquets par exemple. C'est le principe des Mastodon et tout.

C'est dans nos projets depuis un petit moment, mais il y a encore besoin d'un peu de travail (disons 2 ou 3 versions) pour que ça soit sérieusement à l'étude.

Voilà, c'est juste mon avis hein, je peux avoir tord, pas de soucis, mais tu vois j'ai passé aussi du temps à écrire ce billet et à donner des idées, ce que je considère normal lorsque l'on critique.

Et je te remercie beaucoup de l'avoir donné, ça aide ce genre de commentaires, nous sommes très ouverts aux critiques tant qu'elles sont polies et respectueuses du travail effectué (parce que malheureusement on a aussi de temps en temps des trolls qui sont volontairement agressifs ou blessants). Et ton commentaire est très bien, on voit que tu as écris ça en pensant à aider et non pas à blesser (et ça aide, ce genre d'avis ça travaille et ça permet de faire évoluer les opinions). Encore une fois merci pour ton commentaire.

oui bien sûr, et notamment le Jitsi bridge qui devrait être intéressant pour les conférences à plusieurs.

Jitsi utilise Jingle, un protocole XMPP, et SàT l'implémente également, une fois implémenté dans SàT il devrait y avoir compatibilité.

Salut,

je t'avoue que je n'avais pas idée qu'il y aurait autant de choses et que j'y serais encore 10 ans après, au début je voulais principalement faire mon propre client XMPP pour m'améliorer en Python (que je n'avais pas commencé depuis longtemps) et apprendre Twisted. Et en avançant on se rend rapidement compte qu'on ouvre petit à petit de nombreuses possibilités, et ça donne des idées, et ça se développe.

Maintenant est-ce que j'ai visé « trop haut » ? Je ne pense pas non, puisque les fonctionnalités voulues arrivent petit à petit, mais je pensais réussir à provoquer assez d'enthousiasme pour motiver des gens à venir participer, et là dessus c'est un peu une déception.
Aussi c'est difficile de tenir sur plusieurs points : la vie sociale/de famille qui sans être sacrifiée est quand même un peu plus compliquée, la santé qui en prend un coup l'air de rien (à force d'être assis devant un écran), la fatigue bien sûr, et les nerfs qui sont parfois soumis à rude épreuve (par un commentaire désagréable, un bug difficile à régler, ou encore des projets qui ré-inventent la roue alors qu'on est là, qu'on indique depuis longtemps les possibilités énormes du protocole, et qu'on a toujours été ouverts à la collaboration, etc.).

Il faut aussi noter qu'il y a une grande partie d'à-côtés qui prennent un temps fou (et parfois de l'argent) : gérer les serveurs, aller à un événement, gérer le site de présentation, répondre aux messages, écrire des billets, etc.

Donc voilà, oui c'est difficile, oui c'est une masse de travail très importante, et non je ne pense pas avoir visé trop haut.

Je reste très motivé, et ce que qui se construit là est une base pour de nombreux projets que j'ai en tête (le framework web prépare le terrain).

En effet c'est l'idée. Alors évidemment ça n'est pas aussi aussi complet qu'un Wordpress + Discourse + Gitlab + Django, mais ça a l'avantage du tout en un, de la cohérence… et la décentralisation/fédération. D'autre part l'intégration avec ces logiciels est possible au cas par cas si nécessaire.

Par la toute nouvelle documentation : https://salut-a-toi.org/documentation . Au passage, s'il y a des erreurs, que ça n'est pas clair, ou que quelque chose ne marche pas, n'hésitez pas à me remonter.

Note que le backend, Primitivus (TUI) et jp (CLI) sont déjà dans Buster (mais dans une version alpha, la version finale n'était pas prête au moment de gèle de Debian).

Salut,

SàT est interopérable nativement avec tout ce qui est XMPP. Pour le reste il y a des passerelles (par exemple les modules libpurple sont utilisables avec Spectrum 2.

En ce qui concerne les fonctionnalités comme les événements, il est prévu de gérer les formats les plus courants (et il est toujours possible de faire une demande si tel ou tel format est manquant et désiré).

CozyCloud il me semble qu'il ne développent pas de protocole mais utilisent l'existant, il faut donc voir quels formats sont utilisés.

Caliopen d'après ce que j'ai compris (mais ça ne m'a jamais paru clair), c'est aussi une réutilisation de protocoles existants, même chose qu'au dessus.

WebDAV je sais qu'il y a la XEP-0129 qui l'intègre à XMPP, à voir si ça vaut la peine de passer du temps dessus.

Pour Mastodon, comme dit dans la dépêche une passerelle ActivityPub est envisagé (mais il y a déjà un autre projet en cours pour une passerelle ActivityPub/XMPP, je vais probablement attendre de voir ce que ça donne avant de me lancer moi même).

Signal est à ma connaissance fermement opposé à l'utilisation de leur serveur par tout projet tiers. Mais XMPP propose le chiffrement OMEMO, qui est implémenté dans SàT, et qui se base sur le même protocole que Signal.

Pour résumer : ça peut potentiellement utiliser n'importe quoi maintenant (si des passerelles existent déjà) ou dans le futur (si on y consacre du temps).

Ah je vois qu'il y un petit soucis sur le lien vers l'APK Android, dans la phrase:

Pour Android, vous trouverez un APK sur ce lien

ce lien ne pointe pas vers le bon lien qui est : https://ftp.goffi.org/cagou/cagou-0.7.0_unsigned_debug.apk

merci :)