Goffi a écrit 1523 commentaires

Spectrum2 permet d'utiliser libpurple et ses greffons, du coup jette un œil à https://developer.pidgin.im/wiki/ThirdPartyPlugins et à http://spectrum.im/documentation/backends/libpurple.html pour voir ce qui peut t'intéresser. Je n'utilise pas moi même, je ne peux pas t'aider plus que ça.

Vraiment super d'utiliser XMPP pour autre chose que de la messagerie instantanée, et de le montrer. Tes articles sont super didactiques en plus. J'ai hâte d'en lire d'autres :)

Goffi, avec tout le respect que j'ai pour toi et crois-moi ou non, en attendant avec impatience de voir sat-pubsub et Libervia sur Yunohost, je dois te répondre que tu te contredis:

il n'y a aucun problème à ne pas être d'accord, j'aime bien discuter ;)

La technologie Web « WebRTC » hérite et s'inspire de ce travail.

J'ai écris cette phrase suite à ce que j'ai lu sur le sujet sur Wikipédia :

L'API webRTC s'appuie sur des standards existants comme STUN, ICE, TURN, DTLS ou encore SRTP, technologies en parties issues du projet libjingle.

mais jingle sert à la gestion du signal (« signaling »), là où webRTC gère la gestion des périphériques, les filtres très difficiles à faire comme l'annulation d'écho et le flux, ils sont complémentaires, cf. la XEP que j'ai mentionné dans mon commentaire.

Gajim et Pidgin, par exemples, ont implémenté Jingle-vv, et ça ne marche pas avec WebRTC!

Jingle peut fonctionner avec WebRTC, mais également sans. On choisi le transport.

Je ne reproche pas que le standard évolue. Ce que je reproche, c'est ça: […]

je comprends que c'est frustrant vue de l'extérieur. Mais 4 ans ce n'est pas énorme du tout pour un standard (regarde côté technos web le temps que ça prend avec les énormes équipes qui sont dessus pour les implémentations), et Jingle est complètement d'actualité et je ne vois aucune raison que ça change dans un futur proche. Le problème ce sont les clients : la plupart des clients publics actifs sont des projets faits sur le temps libre, pas d'équipe payées, et du coup ça prend du temps. Je pense qu'il est difficilement d'imaginer le boulot que c'est, et chaque client a ses priorités. Ça fait longtemps que j'aimerais bien implémenter le vidéo par exemple, mais j'ai préféré travailler sur d'autre choses avant (même une vidéo en WebRTC one2one je pourrais la faire assez vite, en quelques jours je pense, mais ça serait quelques jours pris sur autre chose). Jitsi lui a mis la vidéo en priorité et a des dévs salariés : là ça tourne.

Il y a aussi beaucoup de client non public, XMPP est très utilisé en entreprise (on ne le soupçonne pas jusqu'à ce qu'on s'en rende compte dans les meetings et salons). Je l'ai déjà vu utiliser pour surveiller du trafic de tramway, pour du monitoring, je sais que c'est utilisé pour des communications satellites ou dans de la haute sécurité, mais ce n'est pas visible du public.

MIX, la prometteuse prochaine génération de salon, "arrive bientôt" depuis déjà 1an.
On prend la même recette qui fait fuir les utilisateurs et on recommence?

À ma connaissance, MIX n'est une priorité pour aucun projet actif actuel. C'est dans les cartons et ça avance à son rythme mais MUC tourne correctement pour le moment. Moi même je pense que ça va être une grosse avancée, mais que ça n'est pas indispensable à l'heure actuelle (Pubsub est nettement plus intéressant à court terme à mon avis).

Donc le standard, ça va être d'en avoir 2??

oui, même plus que 2.

Pour faire un standard, il faut prendre des décisions, même difficiles, même si ça veut dire que certaines choses ne seront pas optimales, même si ça veut dire sacrifier des possibilités.

Ça sera très probablement OMEMO qui sera utilisé par la plupart des clients. C'est au client de prendre les décisions pour simplifier la vie à l'utilisateur en fonction de son cas d'usage, et l'utilisateur n'a pas forcément besoin de savoir qu'il y a plusieurs méthodes. Qu'il y ait d'autres méthodes disponibles ne pose pas de problème si c'est bien géré par le client.

C'est dingue non? Une équipe trouve des ressources et suscite un gros enthousiasme chez un nombre d'utilisateurs non négligeable, se fait réclamer pour une implémentation dans un projet d'OS pour téléphone Libre, en utilisant les technos XMPP alors que les projets XMPP galèrent à trouver des contributeurs et n'ont que très peu de financement.

Ça devrait faire réfléchir, non?

Matrix ils sont issus de la même boîte et ont eu un gros financement permettant d'avoir des salariés à plein temps pendant plusieurs mois, c'est énorme et change complètement la donne. Tu fais la même chose avec n'importe quel protocole correct tu arrives à un résultat similaire. Ils sont très bons en marketing aussi, et ont les moyens (ils ont réussi à avoir un stand au Fosdem la première fois que je les ai vu + conf de 1 h avec alors qu'ils étaient inconnus, et faisaient le show avec un robot radiocommandé), et visiblement les contacts (gageons que l’association avec Purism ne s'est pas faite sur la simple visite du site). Tant mieux pour eux.

Je pense qu'un projet comme Movim, vu l'énergie, la stabilité et le résultat actuel a de quoi décoller, mais il y a aussi un facteur chance et réseau de connaissances. On verra ce que ça va donner.

Pour SàT c'est un cas très particulier, puisqu'on a se coupe volontairement de certaines sources qui pourraient nous aider (Fb, Twitter ou Github par exemple), et qu'on ne veut pas du modèle startup ou d'actionnaires : on a un projet politique.

On a aussi fait certains mauvais choix (on aurait dû faire des versions utilisables plus tôt plutôt que préparer une version « grand public » depuis des années), et on ne sait pas communiquer correctement (je vois régulièrement des projets apparaître qui font ce qu'on fait déjà ou ce qu'on pourrait faire facilement, et qui repartent de zéro, l'exemple actuel c'est les événements qui sont implémentés chez nous et qui vont être refaits de zéro chez Framasoft, et des cas comme ça j'en ai vu passer des tas).

Donc étonnés pas vraiment, et réfléchir on le fait (crois moi c'est souvent difficile moralement et physiquement non seulement pour ceux qui ont choisi de faire ça, mais pour l'entourage également).

Je t'invite à lire le parlons XMPP expliquant Jingle parce que tu n'as visiblement pas du tout compris comment ça fonctionne. WebRTC ne remplace pas Jingle il s'utilise avec, et il n'est certainement obsolète (ah la manie de toujours vouloir tout jeter).

Il n'y a toujours pas non plus de consensus autour du chiffrage bout-à-bout (OX? OMEMO?).

Il n'y a pas à choisir l'un ou l'autre, les 2 ont des propriétés différentes, et les 2 sont à garder.

Purism choisit Matrix/Riot pour le client messagerie/voix/vidéo + chiffrage bout-à-bout, parce que tout ce qu'ils veulent est déjà là.

Tout est tellement déjà là que la voix et la vidéo c'est Jitsi, et donc XMPP et Jingle (ils ont été les chercher dans la poubelle).

sur un réseau local, du broadcast serait sans doute plus approprié pour une diffusion de vidéo, comme dit par ailleurs.

Si tu veux que ça fonctionne à distance, alors oui XMPP pourrait être utilisé, notamment via Jingle (cf. https://linuxfr.org/users/goffi/journaux/parlons-xmpp-episode-10-copie-de-fichiers-et-jingle-suite), et son chiffrement.

As tu regardé du côté de Jitsi ? Il fait déjà la partage d'écran, il peut servir de base. Je ne sais pas s'il peut être facilement extensible, mais ça vaut le coup d'y jeter un œil. Le Jitsi videobridge est une option pour diffuser la vidéo à plusieurs utilisateurs.

Je pense qu'il y a quand même beaucoup de boulot, même si tu trouves une bonne base. Tout ce qui touche à la vidéo peut prendre facilement du temps, surtout si tu veux bien sécuriser ça. Jette un œil aux bibliothèques disponibles pour voir celles qui gèrent Jingle.

J'aurais pu te conseiller SàT sur lequel je travaille, mais on ne fait pas encore de vidéo et ça ne sera pas la cas avant la prochaine sortie, donc plusieurs mois. Par contre on gère déjà chiffrement, commandes, et Jingle (mais par pour la vidéo encore).

Bon courage !

Il me semblait bien que JabberFr autorisait les nom de domaines perso, mais j'ai demandé confirmation pour être sûr, voilà ce qu'on m'a répondu :

Faut juste nous contacter pour nous communiquer le nom de domaine, et faire pointer un CNAME (ou un SRV, mais du coup le certificat ne sera pas valide parce qu’on utilise Let’s Encrypt).
Et bien sûr, une adresse email de contact.

le(s) compte(s) utilisateur à créer (ça n'utilise pas les comptes UNIX).

jette un œil au modules mod_auth_* sur https://modules.prosody.im/ qui permettent d'avoir des méthodes alternatives pour utiliser des comptes existants (il y a notamment un module PAM, à tester).

Les mots de passe sont en clair par défaut sur Prosody, mais on peut les hasher, c'est expliqué sur leur site : http://prosody.im/doc/plain_or_hashed

Pour OpenPGP j'ai expliqué plus haut (la 0027 est à éviter, mais il y a une version moderne et propre, appelée OX).

Les différents chiffrements ont différentes propriétés, j'ai commencé à écrire un article pour expliquer ça, mais je n'ai pas eu le temps de le finir. En gros OTR ne permet de communiquer qu'avec un seul appareil, OMEMO le permet et gère la confidentialité persistance et OX gère plusieurs appareils sans la confidentialité persistante (mais du coup permet d'avoir les archives sur le serveur). Après c'est le rôle du client de rentre ces notions le plus simple et pratique possible pour l'utilisateur, sans sacrifier la sécurité.

Prosody il vaut mieux utiliser la version à jour. Si tu es sur Debian ou dérivée, tu as un dépôt officiel avec les versions à jour, c'est expliqué sur la doc officielle. C'est très facile à installer.

sont des pré-requis : il faut utiliser OMEMO (PGP est déprécié, et OTR ne permet pas 2., cf mes autres commentaires).

Petite correction, PGP n'est pas déprécié, c'est la XEP historique (c.-à-d. qui a été implémentée au début et qui n'a pas fait l'objet d'un processus normal de standardisation, mais qui décrit un état de fait) qui l'est. La version moderne, propre et sécurisée s'appelle OX, c'est la XEP-0373.

Pour le reste je lis les commentaires, beaucoup de critiques sont justifiées, pas toutes.

Il faut toutefois garder à l'esprit, comme cela a été dit par ailleurs, que la plupart des projets sont développés sur le temps libre, et que chaque fonctionnalité prend un temps fou.

Par exemple dans notre cas (SàT), c'est actuellement un seul développeur actif (moi, avec 1 jour/semaine dédié au projet, et 4 à un boulot salarié qui n'a rien à voir).

Pour donner des exemples : au moment d'implémenter le chiffrement de bout en bout l'état de l'art était OTR, ce qui a désormais changé (il est question bien sûr d'implémenter OMEMO et OX, mais je ne peux pas tout faire en même temps). Une implémentation dans notre cas et dans le cas particulier du chiffrement de bout en bout signifie en fait 2 implémentations : une dans le backend pour les plupart des frontaux, et une en javascript pour le frontal web. De même la vidéo est prévue depuis longtemps, et la base est déjà faite (jingle), mais il y a eu d'autre priorités qui devaient passer avant, surtout qu'il existe déjà des solutions satisfaisantes compatibles (Jitsi).

Movim c'est principalement un seul dév également, Gajim c'est du même ordre, Conversations c'est un seul dév mais à temps plein (il en vit), etc. Matrix de son côté à eu un budget conséquent avec une dizaine de salariés à temps plein (sauf erreur), forcément ça aide à avoir une solution plus léchée.

Un des objectifs de SàT (l'asso) est de développer une activité économique pour que déjà je puisse me salarier, puis si possible embaucher du monde, mais nous voulons faire ça selon nos principes éthiques/politiques et évoluer vers une coopérative à terme (SCOP ou similaire) en autogestion. Si nous y arrivons, ça changera complètement la donne (et ma vie, puisque c'est un investissement sur mon temps qu'il est je pense difficile d'imaginer).

oui même inquiétude (j'ai écris la même chose plus bas avant de voir ton message).

Pour le recyclage j'avais vu il y a 2/3 ans des systèmes qui broyaient le plastique et le recompressait pour ré-utiliser une partie des déchets (je n'ai pas le lien sous la main mais ça doit se retrouver assez facilement), c'est mieux mais pas génial (toujours une perte, plastique recyclé évidemment de moins bonne qualité, et énergie nécessaire pour la transformation).

Est-ce qu'il y a des imprimantes libres qui travaillent en usinant du bois par exemple ? Ou utilisant d'autres matériaux moins nocifs que les plastiques ?

Salut,

j'avais acheté une Smartrap suite à ton journal d'il y a 3 ans, et j'en étais très content (mais ça demande du calibrage). Je m'en étais servi pour refaire une pièce manquante sur un lave vaisselle (avec FreeCAD qui est super, il mériterait une dépêche tuto), plus pour le fun parce que je savais que ça n'allait pas tenir avec la chaleur, mais la pièce fonctionnait (tout comme une vis au final qui elle tient la chaleur).

Là j'ai toujours l'imprimante mais elle est démontée suite à un déménagement, et je n'ai vraiment pas le temps de la remettre en état à l'heure actuelle (puis au final, j'ai pas grand chose d'important à imprimer).

Mais du coup je me demande pourquoi tu en as racheté une ? L'idée n'était pas qu'on puisse réparer et faire évoluer cette imprimante en imprimant les nouvelles pièces ? Quel intérêt d'en prendre une autre ? Imprimer plus d'un coup ? Autre ?

C'est génial pour ce que ça ouvre au niveau créativité ou réparations etc., mais par contre je suis un peu inquiet des conséquences écologiques, il est assez prévisible qu'on va voir exploser des impressions plastiques plus ou moins inutiles qui finiront pour beaucoup à la poubelle.

La XEP-0070 est déjà implémentée dans SàT (et notamment utilisable via Cagou l'interface Android/bureau), on a même pas mal communiqué autour de cette XEP pour la faire connaître.

Mais elle permet uniquement de s'assurer de qui est un contact (on entre son identifiant, et on vérifie que la personne qui se connecte a accès au compte indiqué), pas de publier à la place de la personne. Pour ça, il faut soit que la personne sur un serveur externe ait un client capable d'utiliser la fonctionnalités voulue (ici les tickets), soit qu'il y ait une connexion via un système sans transmission de mot de passe, par exemple via OAuth.

Effectivement c'est peu. Mais ce n'est pas forcément leur seule source de revenus

Liberapay, les cotisations et les (rares) dons sont nos seules sources de revenues, c'est indiqué dans nos assemblées générales (cf. la dernière par exemple).

Pour ce qui est des déplacement (par exemple pour venir au POSS d'où j'écris), l'hébergement, le matériel, etc. C'est de notre poche, et on se fait parfois rembourser par l'association.

Merci !

Il y a bien sûr encore du boulot pour arriver au même niveau de confort que les grosses plateformes, mais c'est déjà utilisable en l'état, et ça peut aller vite si un peu de monde suit.

Les applications vont bien au delà du rapport de bogues, on peut mettre les champs qu'on veut dans les tickets, et les merge-requests sont un exemple d'utilisation.

Il est aussi facile de faire des automatisations (étant basé sur pubsub, chaque nouveau ticket envoie une notification par exemple), et j'aimerais bien ajouter un système d'intégration continue (des tests automatisés) qui nous seraient bien utiles pour le développement de SàT.

J'espère aussi trouver du monde pour avancer sur le développement, si des développeurs python passent par là :)

Bon allez, je vais quand même placer Primitivus, notre frontal TUI (console), puisqu'il s'inspire de Vim et est modal, donc pour tout ce qui touche à la messagerie (soit directement en XMPP, soit via des passerelles).

Pour l'édition j'ai testé le mode Evil, cherchant à me remettre à Emacs alors que je ne l'ai pas utilisé depuis à peu près 10 ans. C'est pas mal, mais on est quand même très loin du confort de vim quand on y est habitué (des trucs tout bêtes comme C-a C-x pour incrémenter/décrémenter ne fonctionnent pas de base – mais je crois que c'est possible avec une extension –, et évidemment des commandes comme :mksession ne sont pas disponibles). Il faudra que je m'y penche un peu plus, mais je n'ai pas trop le temps en ce moment. Mon objectif est principalement d'utiliser le org-mode qui a l'air vraiment super, et éventuellement d'interfacer SàT avec.

Sinon j'ai fait un commentaire dans un journal précédent avec quelques alternatives à Pentadactyl/Vimperator.

pour les pages d'extensions (et certainement about:config) je crois que c'est une limitation des webextensions. Par contre pour le nouvel onglet, vim-vixen indique dans la note de sortie de la 0.5 (sortie il y a quelques jours) qu'il est désormais actif dans about:blank, cf. https://addons.mozilla.org/en-US/firefox/addon/vim-vixen/

Un peu hors sujet mais pas tellement, j'utilise depuis des années Pentadactyl, une extension qui permet d'avoir un comportement à la Vim, en rendant Firefox modal, en supprimant (optionnellement) la barre de navigation et d'outil, et surtout en rendant le navigateur très facile à utiliser au clavier (une fois qu'on a pris les habitude, c'est très très pratique d'ouvrir une page en faisant un simple "o" ou "O" pour ouvrir dans un nouvel onglet).
Bien que le paquet n'était plus mis à jour sur le dépôt d'extensions de Firefox, je continuais à l'utiliser avec des astuces (changement de version maximale à la main) ou des build qu'on trouvait par-ci par-là, mais la fin de XUL annonce la fin définitive de cette extension.

Du coup j'ai cherché des équivalents (pour l'instant je continue d'utiliser sur ESR), et je me suis arrêté sur 3 options, ça peut peut-être intéresser du monde:

• vim-vixen: il me semble le plus prometteur, très réactif (plus que Pentadactyl), il est activement développé et a déjà les raccourcis de base. Il ne me manque que les quick marks (et je ne suis pas le seul) pour que je sois à l'aise.

• tridactyl: qui cherche à refaire Pentadactyl/Vimperator en webextension. Ça n'est pas encore dispo (enfin il y a des builds de test que je n'ai pas essayé), mais c'est très actif. À surveiller de près.

Les webextensions ne permettent pas pour le moment de reproduire toutes les fonctionnalités, la 3ème option que j'ai commencé à tester c'est un navigateur indépendant construit directement pour être utilisable à la Vim.

• qutebrowser qui est basé sur Qt (avec QtWebEngine ou QtWebKit pour le rendu). C'est bien fait et réactif, on est tout de suite à l'aise. Les marque pages sont moins pratiques que les quickmarks de Pentadactyl, mais sinon on s'y retrouve. Par contre le moteur (par défaut) est loin derrière Firefox, au niveau du CSS par exemple, les grilles (grid) ne sont pas gérées correctement.

Voilà, si ça peut servir à d'autres…

Cette histoire de contrepartie est intéressante, surtout avec le libre. Il y a déjà une contrepartie : l'œuvre fournie (code, graphisme, animation, texte ou autre) qui l'est pour tout le monde.
Et c'est aussi de la gestion : on a fait une petite campagne de financement collaboratif sur Arizuka pour notre interface Android, et on avait évité les choses physiques pour différentes raisons, mais notamment ne pas avoir à gérer des envois ; mais même sans ça, c'est du temps à gérer, de l'énergie, etc. qui est perdu pour le développement lui-même.

Après mettre un nom quelque part c'est autre chose. D'un côté une contribution financière est une contribution au même titre que qu'un patch, et nous citons bien ceux contribuent au code ou aux médias. D'un autre côté, et dans notre cas particulier, nous nous sommes engagés à ne pas faire de publicité et autant pour un particulier ça ne pose a priori pas de problème, autant pour une entreprise ça devient de la publicité en contrepartie, et donc on parle de sponsors, plus de dons.

Du coup j'aime beaucoup Liberapay parce que c'est du vrai don pour soutenir, pas un achat ou échange déguisé (*). Dans le libre en particulier la contrepartie est déjà là, et pour tout le monde, et ça permet aux gens soutenus de se concentrer vraiment sur ce qu'ils veulent faire. Ça correspond à la boîte de dons qu'on laisse sur un salon.

Ceci dit, je comprends que c'est frustrant pour les donateurs, et je pense qu'il serait pas mal que Liberapay ait une section pour indiquer ce qu'on fait avec les sous reçus, ou pour indiquer l'avancement pour montrer que les sous servent à quelque chose (d'un autre côté on a déjà les blogs officiels pour indiquer ça), même si c'est juste payer une bière pour garder le moral.

(*) je note quand même qu'on n'a pas du tout eu ce sentiment avec notre campagne de financement collaboratif : on a eu des dons parfois gros, et on eu l'impression que c'était vraiment pour soutenir (on a parfois eu des mots d'encouragement très agréables), d'ailleurs il y a des contreparties qui n'ont même pas encore été réclamées.

Salut,

déjà félicitations pour cette sortie, Mongoose IM a l'air de bien avancer.
Est-ce que votre client Mangosta est destiné à rester un logiciel de démo, ou vous comptez à terme en faire un logiciel utilisable au quotidien au même titre que des Conversation ou Movim (ou SàT bientôt) ?

Aussi est-ce que ces logiciels communiquent via XMPP ou via l'API REST (en d'autres termes : est-ce que ce sont des clients XMPP indépendants du serveur, ou des clients Mongoose IM, donc liés à celui-ci ?)

En tout cas c'est super de voir un projet de plus s'intéresser au blogage via XMPP et à ce qui tourne autour.

On se voit au POSS :)

Je pense que oui, en tout cas pour l'instant.

j'ai répondu en dessous, mais je re-précise: SàT n'est nécessaire qu'à la publication pour un groupe, à la lecture c'est transparent.

Tu veux dire qu'il faut nécessairement que les autres membres du "groupe" auquel est destiné le billet utilisent aussi SaT ?

Non. SàT et SàT Pubsub ont deux fonctionnalités non encore standardisées qui permettent ça:

• une modèle d'accès supplémentaire, publisher-roster qui indique qu'on donne accès à un ou plusieurs groupes de la liste de contacts (roster) de celui qui publie
• la possibilité de faire des permissions par éléments (items), qui est un billet dans le cas du blog. Normalement Pubsub ne permet de le faire qu'on niveau du nœud (autrement dit, le flux complet des billets).

En gros ça veut dire que tu peux dire « je veux que ce billet de blog ne soit visible que par les gens de mon groupe bouchot dans la liste de contacts. Il faut utiliser SàT pour publier de cette façon, mais à la lecture c'est totalement transparent pour le client en face : si la personne est dans le groupe désigné, elle verra le billet, sinon non.

En ce qui concerne je vais laisser Edhelas compléter ou corriger si nécessaire, mais ce qui est appelé « publié publiquement » indique que ça va apparaître sur les blogs accessibles par les moteurs de recherche (c.-à-d. aux gens non connectés dans Movim). C'est juste un drapeau spécifique à Movim, le billet reste accessible par n'importe quel client pubsub (puisqu'il garde un accès ouvert (open)).

J'aimerais aussi voir la vidéo dans SàT (et je compte le faire tôt ou tard), mais encore une fois je suis actuellement seul sur le dév. Je suis en train de chercher à améliorer les choses (je travaille notamment sur des outils pour faciliter la collaboration), mais il faut qu'on voit les priorités, et pour le moment il y a déjà plusieurs gros chantiers en cours (gestionnaire d'événements, gestionnaire de tickets, framework web et interface bureau/Android). Bien sûr si j'arrive à être à plein temps dans les années à venir, ça va nettement s'améliorer.

Parce que Jingle et WebRTC ne font pas la même chose. Jingle c'est la mise en relation/gestion de la session (le signal), webRTC c'est la gestion des périphériques, des filtres (annulation d'écho par exemple), et de du flux. Les 2 sont complémentaires et fonctionnent ensemble, c'est pas l'un ou l'autre.

Et Jingle fonctionne très bien, qui a dit le contraire ? Je t'invite à lire l'article que j'ai écrit sur le sujet pour que ça soit un peu plus clair dans ton esprit.

Si tu relis mon commentaire, tu verras que la tâche sur le web n'est pas trop compliquée (pour quelque chose de base et grâce à WebRTC), mais que sur les autres plateformes ce n'est pas aussi évident (la question parle de smartphone, je suppose qu'elle parle d'application native), et que dans tous les cas si on veut un truc qui fonctionne bien ça demande beaucoup de tests, et ce n'est pas dans nos priorités principales actuelles vu nos ressources (un dév sur le temps libre) et vu que certains projets font déjà ça correctement (Jitsi).

Jingle est souvent implémenté (il est implémenté sur SàT et donc dispo sur Cagou notre interface Android par exemple), mais ce n'est qu'une partie de ce qui est nécessaire (nous l'implémentons pour la copie de fichiers par exemple).

Je ne sais pas pour les autres, mais pour nous la visio-conférence est mise de côté pour le moment parce que c'est un gros boulot, qui demande beaucoup de tests, et que nous avons déjà beaucoup de pain sur la planche. C'est prévu, mais en priorité moyenne. Sur le web la tâche est nettement facilitée par WebRTC, une visio de base est presque triviale avec ça maintenant.

Pour utiliser la même techno sur bureau ou téléphone, il faut regarder comment c'est possible (sur bureau GNUnux je pense qu'avec GStreamer/Phonon ça doit être jouable, avec Kivy je ne sais pas, certainement en faisant des appels Java à l'API Android ça doit pouvoir se faire, ou avec la solution un peu crados d'une webview, mais ça n'est probablement pas simple).

Ça demande d'étudier bien les différentes possibilités et d'avoir du temps. Si j'étais à plein temps ça serait certainement possible, au moins via l'interface web, depuis longtemps…

D'autre part, les priorités sont peut-être différentes selon les projets. Jitsi marche déjà bien pour la vidéo, c'est pas un gros problème de l'utiliser à côté d'ici à ce qu'on ait notre propre implémentation.

C'est complètement faux, vous lisez trop vite et/ou pas assez. XMPP sait gérer le multi-appareils depuis le début (avec les ressources), et a un système de priorités.

Le système de priorité n'est pas pratique et porte à confusion, la plupart des implémentations (mais pas toutes) envoyaient le message à tous les appareils quand les priorités étaient égales. Avec le temps et la prolifération des appareils (il est beaucoup plus courant qu'avant d'avoir plusieurs appareils, rien qu'avec le téléphone et l'ordinateur de bureau), ce système s'est montré inefficace, d'où la sortie d'une extension pour corriger ça, ce qui est la façon de faire chez XMPP. À l'époque XMPP était un des seuls protocoles à gérer plusieurs appareils, et la plupart des autres logiciels (pour ne pas dire tous) se déconnectaient si on se connectait depuis un autre endroit.

L'extension en question est bien faite, elle permet notamment d'indiquer qu'il ne faut pas copier un message si nécessaire (par exemple dans le cas d'OTR), et elle ne date pas de 2017 mais de 2010 (première version publique le 3 mai 2010). Il est possible de le faire avec Prosody (qui n'est qu'une des implémentation d'un serveur XMPP) depuis 6 ans. La seule chose qui a changé est que le module qui le permet (mod_carbons) est maintenant un module installé d'office, et c'est clairement indiqué dans l'annonce. Donc ça n'est certainement une fonctionnalité apparue en 2017.