Pour cette décision en particulier, je ne sais pas (vu que je ne fréquentais pas les mailing lists de la communauté GNOME), mais de mon expérience personnelle, remplacer les mailing lists par discourse ça change complètement l’usage et la population d'utilisateurs présents.
Utiliser discourse sans javascript, c’est impossible, utiliser discourse comme une mailing list avec l'interface mail, c'est impossible (c’est techniquement possible, mais en pratique ce n'est pas tenable, car il n’y a pas de threads corrects, pas de citations au format mail, et surtout, beaucoup plus de messages entrants qui sont aussi beaucoup moins construits).
Je vois après le passage de l’espace de discussions des CHATONS vers discourse, je n'ai simplement pas l'énergie pour aller consulter un forum périodiquement (où des décisions importantes sont prises par ailleurs), et après avoir activé l'interfaçage email je l'ai vite désactivé car c’est beaucoup trop de messages, dans un format pas très agréable à lire.
Ce n'est pas pour critiquer la décision du passage à discourse dans un cas où dans l'autre (les pour et contre ont certainement été pesés, même si ça m'affecte négativement), mais c'est plus honnête de dire qu'on supprime les mailing lists et qu’on ouvre un discourse, que dire qu’on va remplacer un avec l’autre.
Je ne suis pas sûr de visualiser ce que tu appelles "guerre de ptites chapelles". Chaque protocole, chaque produit a une histoire, des fonctionnalités, des développeurs différents, et s’ils sont pour beaucoup en concurrence sur leurs modes d’utilisation principaux, ça n’en fait pas une querelle de clochers soluble d’une quelconque façon.
Par exemple, je suis plutôt impliqué dans l’écosystème XMPP, je développe une lib, un client, j’administre un serveur public. Ce n’est pas le fait que matrix ait de la hype et du pognon (et du HTTP+JSON) qui va me faire bouger d’un écosystème à l’autre (sans compter les tensions entre les communautés, pour des raisons justifiées et moins justifiées).
Du coup je ne vois pas ce que cible "une chapelle revendiquée", puisqu’évidemment un projet va faire des choix techniques, et donc "choisir une chapelle", généralement dès le tout début de son existence.
Du reste la difficulté reste de proposer une expérience d’onboarding fluide, maintenant que les gens sont habitués à ne plus avoir à choisir de serveur/instance ou de mot de passe pour quoi que ce soit, le tout sans regrouper tout le monde sur un seul serveur (ou cluster). Et après on peut rentrer dans le détail de "Il manque à cette fonctionnalité INDISPENSABLE pour faire migrer les gens depuis Whatsapp" (et une fois que la fonctionnalité est là, en fait non, il fallait juste un effet réseau et de la pub, pas la Xème feature gadget).
Sur XMPP le projet libre qui a le plus une ambition grand public est Snikket, l’idée étant de proposer un client unique au même nom sur toutes les plateformes, et d’avoir une approche basée sur les invitations. Pas mal de choses ont déjà abouti depuis la création de cette initiative, mais il reste bien sûr beaucoup à faire.
Alors c’est plus une question de moyens, intérêts et de temps disponible que de temps pur. Jingle ça marche depuis un bail (Google s’est d’ailleurs basé dessus pour concevoir webrtc, il reste quelques traces dans libwebrtc), toute la cohorte de XEP audio-vidéo est plutôt stable, les trucs à résoudre n’étant pas dans le "domaine" XMPP et donc sont fatalement plus compliqués (codecs, dépendances externes, libs pour faire de la vidéo sur le desktop, etc).
On peut constater que Conversations a pu ajouter le support de la vidéo dans un temps raisonnable avec un financement, Movim l’a fait rapidement également avec la voie un peu plus tracée, Dino est en train de finaliser l’ajout (via un financement, c’est déjà testable dans une branche mais encore très alpha). Gajim l’implémentation qui marchottait il y a 10 ans et laissée à l’abandon a été remise peu à peu au goût du jour et l’audio commence à remarcher.
C’est une tradition, qui ne me fait pas beaucoup rire personnellement, mais c’est le prétexte le plus bidon pour dire qu’un protocole est pourri. On peut jeter tout ce que fait l’IETF, quitte à dire ça, ça te paraît être une bonne idée ?
C’est un débat un peu maudit dans la mesure où c’est “damned if you do, damned if you don’t”, si le compte a des clefs OMEMO publiées (ou déjà utilisées par le passé), alors le client va tenter de façon opportuniste de chiffrer les messages pour ces clefs. Personnellement ça m’insupporte mais je comprends le raisonnement.
Si le client ne le fait pas, les gens pour qui le chiffrement bout en bout est indispensable, vont immédiatement être scandalisés de la faille de sécurité que ça implique (le serveur pouvant donc "désactiver le chiffrement" s’il est malicieux, même si le client affiche un gros warning en rouge il sera probablement ignoré).
Si le client le fait, ça veut dire qu’on a des messages OMEMO qui arrivent sur des clients ne le prenant pas en charge, ce qui amène une expérience utilisateur pas terrible si un des clients derrière ne gère pas OMEMO (ce qui se passe actuellement).
Alors en tant que mainteneur de poezio je n’ai aucun problème avec ça (et mcabber est en effet un bon client), par contre je suis preneur des fonctionnalités à désactiver avant que ça soit "raisonnablement utilisable" :).
Alors "XMPP était sensé être la réponse contre whatsapp" alors que whatsapp est basé sur XMPP, je suis pas sûr de suivre… Whatsapp ça montre juste ce qu’on peut faire d’XMPP avec de l’argent et des pratiques prédatrices.
Même avec un hash "relativement lent", comme l’ensemble de départ fini et qu’il est impossible de les saler (puisque le but c’est de pouvoir retrouver ses contacts avec leur numéro de téléphone), obtenir l’intégralité des hashs reste totalement faisable. La seule solution envisageable serait de faire une sorte de rotation en forçant la mise à jour de l’application régulièrement pour que les identifiants changent, mais ce n’est pas réaliste.
J’utilise cette fonctionnalité assez peu, mais pour alimenter le dossier :
Je sais qu’au moins Conversations a une option facile d’accès pour le faire ("Créer un groupe de discussion privé"), avec choix des participants dans la liste de contacts
Les serveurs doivent indiquer aux clients dans leur configuration quel serveur de salons les utilisateurs peuvent utiliser pour créer leurs salons privés
Il y a normalement une fonctionnalité "transparente" qui permet de transformer un chat entre deux personnes en groupe de discussion au besoin
En effet, il faut valider la configuration, mais la plupart des clients gèrent l’envoi automatique du formulaire sans interaction utilisateur (les champs sont standard et il est donc possible de ne pas l’exposer à l’utilisateur directement)
Il me semble que gajim 1.3 (qui vient de passer en beta 2, depuis l’écriture de ce journal), a également des nouveautés côté audio/vidéo, même si ce ne sera pas complet. Je ne suis pas sûr et tout ça sera de toute façon dans les notes de sortie quand la version finale sera disponible.
Quelque chose que j’aurais dû rajouter, car ça rajoute pas mal de lisibilité à l’écosystème, c’est le travail fourni (principalement par Link Mauve) pour pousser l’utilisation de DOAP (Description Of a Project) dans XMPP. DOAP est un format (se basant sur RDF) permettant de décrire de façon sémantique un projet logiciel. Grâce à des extensions spécifiques à XMPP, il va permettre d’apporter les modifications suivante au site xmpp.org, ainsi qu’à n’importe quel site qui souhaite présenter ces données :
Pour les développeurs, des informations rapides sur quel client/serveur/bibliothèque implémente quelle extension, et dans quelle proportion (un exemple est disponible sur linkmauve.fr, avec l’affichage du nombre dans la liste des extensions, et l’affichage de chaque projet avec son logo dans la visualisation de chaque extension.
Pour les utilisateurs, une façon rapide de voir si le client prend en charge les “Compliance Suites” les plus récentes, ainsi qu’un format standard pour visualiser un projet avec logo, capture d’écran, etc.
C’est un travail qui n’est pas terminé, certains projets n’ont pas encore renseigné les informations, certains partiellement, et certains n’ont pas encore référencé leur fichier DOAP sur xmpp.org, mais c’est quelque chose qui devrait rendre la vie des gens qui découvrent XMPP plus simple.
Je crois que je réponds à cette question dans la première section de ce billet :) : « Et puis depuis le milieu de l’année dernière environ, on peut passer des appels audio et vidéo depuis l’application Conversations, ainsi que Movim ou Siskin. »
Côté bibliothèques python, je sais que le dépôt slixmpp est plus actif que celui de sleekxmpp mais à ma connaissance il n'y a toujours pas de version Debian. Est-ce prévu?
Normalement python3-slixmpp est disponible dans debian depuis quelques temps; pas dans sa dernière version mais pas loin (je ne dirais pas que c'est beaucoup plus actif par contre, surtout ces derniers temps :P). On a presque poezio dedans aussi (le seul problème qui restait était une licence pas claire pour le logo, mais ça s’est arrangé), il suffirait d’une petite poussée dans la bonne direction.
En effet, il n'y a aucune garantie de stabilité de l'IP, il est même dit à peu près partout qu'elle est dynamique. Étant chez eux depuis 3 ans, j'ai quand même conservé la même IP malgré les plantages intempestifs de la box et les coupures réseau (parfois pendant des semaines).
Ah ben oui, ça ne fonctionne pas sur le 443, vu que le 443 c'est pour HTTPS. Par défaut il y a une couche TLS, c'est même obligatoire (cf les RFC). Je ne suis pas sûr de comprendre le problème d'avoir deux ports ou de bien voir quels sont les deux trucs à faire…
Ce n'est pas tout à fait exact, Conversations est libre, mais payant sur le Google Play Store; par conséquent si on veut l'obtenir sans payer il faut au choix : le compiler soi-même, l'obtenir depuis une source tierce (f-droid, ou autre), ou installer un de ses forks gratuits sur le play store.
La visio avec Skype, ça fonctionne bien, tout le temps.
Pas exactement, sous linux ça a rarement été simple (pendant plusieurs années skype refusait tout simplement de détecter les webcams sur ubuntu), et il y avait des problèmes de compatibilité entre les versions également. Niveau qualité et lag, ce n'est pas non plus aussi rose que tu le dis (et là je parle d'audioconférences pro, avec des pc sous windows et sur un réseau d'entreprise). Donc pour commencer, c'est peut-être une question de ressenti, parce que c'est toujours facile de taper sur l'audio/vidéo dans XMPP, mais fétichiser des systèmes fermés qui font à peine mieux, je trouve ça plutôt malsain.
Je reconnais ne pas apprécier la communication audio/vidéo (en plus de la désactivation des micros et webcams sur mes machines pour des raisons de sécurité), donc je n'en ai pas vraiment l'expérience en dehors du dépannage des soucis de la famille et du boulot, mais à chaque fois que j'ai pu tester Jitsi Meet (qui utilise XMPP) sur meet.jabberfr.org ou meet.jit.si, je n'ai pas eu de problème liés à la solution de visioconf ou de traversée de NAT ou autre.
J'ai quand même l'impression que la plupart des reproches qui sont faits sont de l'ordre de "de toute façon on peut pas lutter contre les machins fermés pleins de thunes, donc une armée de développeurs et un matraquage maerketing", et à ce compte là, on peut fermer linuxfr.
Les serveurs ont en général des modules pour pallier à ce problème et préremplir automatiquement les listes de contacts des nouveaux arrivants (un script externe pourrait faire ça, mais c'est un peu lourd).
Sans oublier l'inscription de l'état d'urgence dans le droit commun, actuellement en débat à l'assemblée, avec des conséquences graves sur les libertés numériques.
Pour les clients de bureau, 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 ; on peut citer également swift qui part plutôt pour un look et une utilisation "minimaliste" mais moderne, ou encore Salut à toi qui avance quotidiennement (mais pas forcément sur la partie desktop, cela dit).
Côté Android, je ne suis pas d’accord, il y a un paquet de clients fonctionnels assez simples d’utilisation, et en particulier conversations qui prend en charge toute les extensions récentes (voire qui est un des vecteurs d’adoption de ces extensions) et essaie de fournir le même genre de workflow que les messageries privatrices hypes du moment.
# Pas trop convaincu
Posté par mathieui (site web personnel) . En réponse à la dépêche La communauté GNOME remplace ses listes de discussion par Discourse. Évalué à 10.
Pour cette décision en particulier, je ne sais pas (vu que je ne fréquentais pas les mailing lists de la communauté GNOME), mais de mon expérience personnelle, remplacer les mailing lists par discourse ça change complètement l’usage et la population d'utilisateurs présents.
Utiliser discourse sans javascript, c’est impossible, utiliser discourse comme une mailing list avec l'interface mail, c'est impossible (c’est techniquement possible, mais en pratique ce n'est pas tenable, car il n’y a pas de threads corrects, pas de citations au format mail, et surtout, beaucoup plus de messages entrants qui sont aussi beaucoup moins construits).
Je vois après le passage de l’espace de discussions des CHATONS vers discourse, je n'ai simplement pas l'énergie pour aller consulter un forum périodiquement (où des décisions importantes sont prises par ailleurs), et après avoir activé l'interfaçage email je l'ai vite désactivé car c’est beaucoup trop de messages, dans un format pas très agréable à lire.
Ce n'est pas pour critiquer la décision du passage à discourse dans un cas où dans l'autre (les pour et contre ont certainement été pesés, même si ça m'affecte négativement), mais c'est plus honnête de dire qu'on supprime les mailing lists et qu’on ouvre un discourse, que dire qu’on va remplacer un avec l’autre.
# guerre de chapelles ?
Posté par mathieui (site web personnel) . En réponse au message sip, visio, sms, linphone, xmpp, la petite grande interrogation. Évalué à 1.
Je ne suis pas sûr de visualiser ce que tu appelles "guerre de ptites chapelles". Chaque protocole, chaque produit a une histoire, des fonctionnalités, des développeurs différents, et s’ils sont pour beaucoup en concurrence sur leurs modes d’utilisation principaux, ça n’en fait pas une querelle de clochers soluble d’une quelconque façon.
Par exemple, je suis plutôt impliqué dans l’écosystème XMPP, je développe une lib, un client, j’administre un serveur public. Ce n’est pas le fait que matrix ait de la hype et du pognon (et du HTTP+JSON) qui va me faire bouger d’un écosystème à l’autre (sans compter les tensions entre les communautés, pour des raisons justifiées et moins justifiées).
Du coup je ne vois pas ce que cible "une chapelle revendiquée", puisqu’évidemment un projet va faire des choix techniques, et donc "choisir une chapelle", généralement dès le tout début de son existence.
Du reste la difficulté reste de proposer une expérience d’onboarding fluide, maintenant que les gens sont habitués à ne plus avoir à choisir de serveur/instance ou de mot de passe pour quoi que ce soit, le tout sans regrouper tout le monde sur un seul serveur (ou cluster). Et après on peut rentrer dans le détail de "Il manque à cette fonctionnalité INDISPENSABLE pour faire migrer les gens depuis Whatsapp" (et une fois que la fonctionnalité est là, en fait non, il fallait juste un effet réseau et de la pub, pas la Xème feature gadget).
Sur XMPP le projet libre qui a le plus une ambition grand public est Snikket, l’idée étant de proposer un client unique au même nom sur toutes les plateformes, et d’avoir une approche basée sur les invitations. Pas mal de choses ont déjà abouti depuis la création de cette initiative, mais il reste bien sûr beaucoup à faire.
[^] # Re: XMPP
Posté par mathieui (site web personnel) . En réponse au journal Signal envoie des signaux inquiétants. Évalué à 5. Dernière modification le 13 avril 2021 à 21:10.
Alors c’est plus une question de moyens, intérêts et de temps disponible que de temps pur. Jingle ça marche depuis un bail (Google s’est d’ailleurs basé dessus pour concevoir webrtc, il reste quelques traces dans libwebrtc), toute la cohorte de XEP audio-vidéo est plutôt stable, les trucs à résoudre n’étant pas dans le "domaine" XMPP et donc sont fatalement plus compliqués (codecs, dépendances externes, libs pour faire de la vidéo sur le desktop, etc).
On peut constater que Conversations a pu ajouter le support de la vidéo dans un temps raisonnable avec un financement, Movim l’a fait rapidement également avec la voie un peu plus tracée, Dino est en train de finaliser l’ajout (via un financement, c’est déjà testable dans une branche mais encore très alpha). Gajim l’implémentation qui marchottait il y a 10 ans et laissée à l’abandon a été remise peu à peu au goût du jour et l’audio commence à remarcher.
[^] # Re: Configuration serveur et écosystème de clients
Posté par mathieui (site web personnel) . En réponse à la dépêche Messagerie instantanée : ce n’est pas une question d’applications. Évalué à 5.
C’est une tradition, qui ne me fait pas beaucoup rire personnellement, mais c’est le prétexte le plus bidon pour dire qu’un protocole est pourri. On peut jeter tout ce que fait l’IETF, quitte à dire ça, ça te paraît être une bonne idée ?
[^] # Re: mcabber (ou profanity ?)
Posté par mathieui (site web personnel) . En réponse au sondage Quel est selon vous le client XMPP à l'interface la plus adaptée pour une équipe soudée de gens inconnus?. Évalué à 3. Dernière modification le 30 janvier 2021 à 11:23.
C’est un débat un peu maudit dans la mesure où c’est “damned if you do, damned if you don’t”, si le compte a des clefs OMEMO publiées (ou déjà utilisées par le passé), alors le client va tenter de façon opportuniste de chiffrer les messages pour ces clefs. Personnellement ça m’insupporte mais je comprends le raisonnement.
Si le client ne le fait pas, les gens pour qui le chiffrement bout en bout est indispensable, vont immédiatement être scandalisés de la faille de sécurité que ça implique (le serveur pouvant donc "désactiver le chiffrement" s’il est malicieux, même si le client affiche un gros warning en rouge il sera probablement ignoré).
Si le client le fait, ça veut dire qu’on a des messages OMEMO qui arrivent sur des clients ne le prenant pas en charge, ce qui amène une expérience utilisateur pas terrible si un des clients derrière ne gère pas OMEMO (ce qui se passe actuellement).
[^] # Re: mcabber
Posté par mathieui (site web personnel) . En réponse au sondage Quel est selon vous le client XMPP à l'interface la plus adaptée pour une équipe soudée de gens inconnus?. Évalué à 7.
Alors en tant que mainteneur de poezio je n’ai aucun problème avec ça (et mcabber est en effet un bon client), par contre je suis preneur des fonctionnalités à désactiver avant que ça soit "raisonnablement utilisable" :).
[^] # Re: non
Posté par mathieui (site web personnel) . En réponse au journal Signal la bonne alternative à Whatsapp ?. Évalué à 8.
Alors "XMPP était sensé être la réponse contre whatsapp" alors que whatsapp est basé sur XMPP, je suis pas sûr de suivre… Whatsapp ça montre juste ce qu’on peut faire d’XMPP avec de l’argent et des pratiques prédatrices.
[^] # Re: signal
Posté par mathieui (site web personnel) . En réponse au journal Signal la bonne alternative à Whatsapp ?. Évalué à 10.
Même avec un hash "relativement lent", comme l’ensemble de départ fini et qu’il est impossible de les saler (puisque le but c’est de pouvoir retrouver ses contacts avec leur numéro de téléphone), obtenir l’intégralité des hashs reste totalement faisable. La seule solution envisageable serait de faire une sorte de rotation en forçant la mise à jour de l’application régulièrement pour que les identifiants changent, mais ce n’est pas réaliste.
[^] # Re: signal
Posté par mathieui (site web personnel) . En réponse au journal Signal la bonne alternative à Whatsapp ?. Évalué à 10.
(ce qui revient au même puisque générer ou obtenir les hashs de tous les numéros de téléphone possible a un coût marginal, même pour moi)
[^] # Re: Messages de groupes
Posté par mathieui (site web personnel) . En réponse au journal XMPP en 2021. Évalué à 5.
J’utilise cette fonctionnalité assez peu, mais pour alimenter le dossier :
# Petite typo
Posté par mathieui (site web personnel) . En réponse au journal XMPP en 2021. Évalué à 1.
Avis aux modérateurs : on m’a fait remonter la typo "recherrche", je croyais l’avoir corrigée mais visiblement pas !
[^] # Re: Audio / Video
Posté par mathieui (site web personnel) . En réponse au journal XMPP en 2021. Évalué à 2.
Il me semble que gajim 1.3 (qui vient de passer en beta 2, depuis l’écriture de ce journal), a également des nouveautés côté audio/vidéo, même si ce ne sera pas complet. Je ne suis pas sûr et tout ça sera de toute façon dans les notes de sortie quand la version finale sera disponible.
# Un petit oubli
Posté par mathieui (site web personnel) . En réponse au journal XMPP en 2021. Évalué à 10.
Quelque chose que j’aurais dû rajouter, car ça rajoute pas mal de lisibilité à l’écosystème, c’est le travail fourni (principalement par Link Mauve) pour pousser l’utilisation de DOAP (Description Of a Project) dans XMPP. DOAP est un format (se basant sur RDF) permettant de décrire de façon sémantique un projet logiciel. Grâce à des extensions spécifiques à XMPP, il va permettre d’apporter les modifications suivante au site xmpp.org, ainsi qu’à n’importe quel site qui souhaite présenter ces données :
C’est un travail qui n’est pas terminé, certains projets n’ont pas encore renseigné les informations, certains partiellement, et certains n’ont pas encore référencé leur fichier DOAP sur xmpp.org, mais c’est quelque chose qui devrait rendre la vie des gens qui découvrent XMPP plus simple.
[^] # Re: Audio / Video
Posté par mathieui (site web personnel) . En réponse au journal XMPP en 2021. Évalué à 6.
Je crois que je réponds à cette question dans la première section de ce billet :) : « Et puis depuis le milieu de l’année dernière environ, on peut passer des appels audio et vidéo depuis l’application Conversations, ainsi que Movim ou Siskin. »
# Lien invalide
Posté par mathieui (site web personnel) . En réponse à la dépêche Un nouveau logiciel : WemaWema !. Évalué à 3.
L'url du site "as a service" dans les liens est cassée, il manque le .fr.
[^] # Re: Fonctionnalités pour mobile
Posté par mathieui (site web personnel) . En réponse à la dépêche Sortie du très attendu Prosody 0.10. Évalué à 2.
Normalement python3-slixmpp est disponible dans debian depuis quelques temps; pas dans sa dernière version mais pas loin (je ne dirais pas que c'est beaucoup plus actif par contre, surtout ces derniers temps :P). On a presque poezio dedans aussi (le seul problème qui restait était une licence pas claire pour le logo, mais ça s’est arrangé), il suffirait d’une petite poussée dans la bonne direction.
[^] # Re: Pourquoi ?
Posté par mathieui (site web personnel) . En réponse au journal Pourquoi Jabber n'a pas plus de succès, même chez les informaticiens?. Évalué à 2.
Oui, mais BOSH est assez moche conceptuellement même s'il peut s'avérer pratique ; de nos jours c’est mieux de passer par du websocket.
[^] # Re: engagement de Bouygues
Posté par mathieui (site web personnel) . En réponse au journal Bouygues et IP fixe... qui change (où l'on parle aussi de fake MX). Évalué à 2.
En effet, il n'y a aucune garantie de stabilité de l'IP, il est même dit à peu près partout qu'elle est dynamique. Étant chez eux depuis 3 ans, j'ai quand même conservé la même IP malgré les plantages intempestifs de la box et les coupures réseau (parfois pendant des semaines).
[^] # Re: Pourquoi ?
Posté par mathieui (site web personnel) . En réponse au journal Pourquoi Jabber n'a pas plus de succès, même chez les informaticiens?. Évalué à 3.
Ça se fait en une seule demande au SI, ce n'est pas bien différent d'un seul.
Non, XMPP n'a pas de mode de transport, XMPP est un protocole à part entière, et à ce titre utilise du TLS par-dessus TCP.
Il faut le configurer, comme toute application qui utilise TLS, mais une grande partie des serveurs vont refuser de te parler si tu n'actives pas TLS.
[^] # Re: Pourquoi ?
Posté par mathieui (site web personnel) . En réponse au journal Pourquoi Jabber n'a pas plus de succès, même chez les informaticiens?. Évalué à 2.
Ah ben oui, ça ne fonctionne pas sur le 443, vu que le 443 c'est pour HTTPS. Par défaut il y a une couche TLS, c'est même obligatoire (cf les RFC). Je ne suis pas sûr de comprendre le problème d'avoir deux ports ou de bien voir quels sont les deux trucs à faire…
[^] # Re: Pourquoi ?
Posté par mathieui (site web personnel) . En réponse au journal Pourquoi Jabber n'a pas plus de succès, même chez les informaticiens?. Évalué à 3.
Ce n'est pas tout à fait exact, Conversations est libre, mais payant sur le Google Play Store; par conséquent si on veut l'obtenir sans payer il faut au choix : le compiler soi-même, l'obtenir depuis une source tierce (f-droid, ou autre), ou installer un de ses forks gratuits sur le play store.
[^] # Re: parce que ça ne marche pas bien ?
Posté par mathieui (site web personnel) . En réponse au journal Pourquoi Jabber n'a pas plus de succès, même chez les informaticiens?. Évalué à 1.
Pas exactement, sous linux ça a rarement été simple (pendant plusieurs années skype refusait tout simplement de détecter les webcams sur ubuntu), et il y avait des problèmes de compatibilité entre les versions également. Niveau qualité et lag, ce n'est pas non plus aussi rose que tu le dis (et là je parle d'audioconférences pro, avec des pc sous windows et sur un réseau d'entreprise). Donc pour commencer, c'est peut-être une question de ressenti, parce que c'est toujours facile de taper sur l'audio/vidéo dans XMPP, mais fétichiser des systèmes fermés qui font à peine mieux, je trouve ça plutôt malsain.
Je reconnais ne pas apprécier la communication audio/vidéo (en plus de la désactivation des micros et webcams sur mes machines pour des raisons de sécurité), donc je n'en ai pas vraiment l'expérience en dehors du dépannage des soucis de la famille et du boulot, mais à chaque fois que j'ai pu tester Jitsi Meet (qui utilise XMPP) sur meet.jabberfr.org ou meet.jit.si, je n'ai pas eu de problème liés à la solution de visioconf ou de traversée de NAT ou autre.
J'ai quand même l'impression que la plupart des reproches qui sont faits sont de l'ordre de "de toute façon on peut pas lutter contre les machins fermés pleins de thunes, donc une armée de développeurs et un matraquage maerketing", et à ce compte là, on peut fermer linuxfr.
[^] # Re: Ici ça marche
Posté par mathieui (site web personnel) . En réponse au journal Pourquoi Jabber n'a pas plus de succès, même chez les informaticiens?. Évalué à 1.
Les serveurs ont en général des modules pour pallier à ce problème et préremplir automatiquement les listes de contacts des nouveaux arrivants (un script externe pourrait faire ça, mais c'est un peu lourd).
[^] # Re: en amont
Posté par mathieui (site web personnel) . En réponse à la dépêche Inauguration d'un « bureau ouvert » à l’Assemblée nationale française. Évalué à 8.
Sans oublier l'inscription de l'état d'urgence dans le droit commun, actuellement en débat à l'assemblée, avec des conséquences graves sur les libertés numériques.
[^] # Re: Super!
Posté par mathieui (site web personnel) . En réponse à la dépêche Sortie de poezio 0.10. Évalué à 3.
Pour les clients de bureau, 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 ; on peut citer également swift qui part plutôt pour un look et une utilisation "minimaliste" mais moderne, ou encore Salut à toi qui avance quotidiennement (mais pas forcément sur la partie desktop, cela dit).
Côté Android, je ne suis pas d’accord, il y a un paquet de clients fonctionnels assez simples d’utilisation, et en particulier conversations qui prend en charge toute les extensions récentes (voire qui est un des vecteurs d’adoption de ces extensions) et essaie de fournir le même genre de workflow que les messageries privatrices hypes du moment.