Prosody est un serveur XMPP moderne, facile à mettre en place et léger. Il est flexible et extensible pour les développeurs. Il est codé en Lua et est publié sous licence MIT.
Cette nouvelle mouture, sortie le 2 octobre 2017, apporte la copie carbone et la gestion de l’archivage des messages (MAM). Ces deux nouvelles fonctionnalités permettent une meilleure synchronisation de la totalité des conversations entre différents clients, qu’il s’agisse d’un ordinateur de bureau ou d’un mobile qui subit de multiples reconnexions.
Ceci est une traduction collaborative de l’annonce de sortie de Prosody 0.10.0. Merci à tous les participants (cf. l’en‐tête pour avoir les noms).
Sommaire
Ce n’est pas le premier avril, mais bien le 2 octobre. Ça signifie que les rumeurs sont donc vraies, Prosody 0.10.0 est sorti !
Il s’agit de la première version de la branche 0.10. Les versions sorties récemment ont fait partie de la branche stable 0.9. Ceci nous a été bien utile depuis la sortie initiale de la 0.9.0 en 2013.
Cependant, le temps file et nous avons une longue liste de nouvelles fonctionnalités et de modules que nous souhaitons partager avec vous.
Cette nouvelle version contient plus de 1 500 nouvelles révisions faites par de nombreux contributeurs, ajoutant et modifiant plus de 30 000 lignes de code.
Fonctionnalités
Copie carbone
Bien qu’elle ait été disponible depuis un certain temps dans notre dépôt de modules communautaires, cette nouvelle version apporte la prise en charge des copies carbones (XEP-0280: Message Carbons).
Cette fonctionnalité permet à plusieurs clients connectés au même compte d’avoir la même vision d’une conversation, autorisant un changement de terminal pendant une conversation sans avoir à s’inquiéter de rater des messages.
Démonstration d’une conversation avec des messages reçus en copies carbones dans les clients Yaxim, Gajim et Conversations.
Gestion de l’archivage des messages (MAM)
La gestion de l’archivage des messages XEP-0313: Message Archive Management devient également officielle.
Comme la copie carbone, cette fonctionnalité permet aux clients de synchroniser les conversations. Et, grâce à une archive côté serveur, elle permet aussi aux clients qui étaient hors ligne de « rattraper » les conversations qu’ils ont pu manquer. Combinée aux copies carbones, elle fournit une solution complète au besoin d’avoir « tous les messages sur tous les terminaux », fonctionnalité clef sur les systèmes de messagerie modernes.
Notre implémentation est flexible, elle permet de configurer le temps de rétention des messages et la destination des archives entre des fichiers simples, une base de données SQL, ou ce que vous aurez interfacé avec notre API de stockage modulaire.
Sécurité : Channel binding pour SCRAM
En utilisant de la sorcellerie cryptographique, ce nouveau mécanisme d’identification permet à un client de vérifier qu’il est bien en train de parler au bon serveur, même s’il ne reconnaît pas le certificat TLS. Ceci est rendu possible par une fonctionnalité du protocole d’identification SCRAM qui force le serveur à prouver qu’il connaît également le mot de passe de l’utilisateur.
Merci à Tobias Markmann pour cette contribution.
Vérificateur intégré de la configuration
Prosody inclut désormais un outil très utile qui tente d’identifier les soucis habituels d’un déploiement. Il va non seulement vérifier les erreurs de syntaxe dans le fichier de configuration, mais aussi la configuration DNS, les certificats, et d’autres points de la configuration du serveur.
C’est un bon réflexe à avoir dans cas où quelque chose ne fonctionne pas comme vous vous y attendez.
Statistiques
Cette version ajoute également la gestion native du regroupement des statistiques sur les opérations du serveur. Même s’il y avait déjà quelques modules communautaires capables de mesurer différentes choses dans les versions précédentes, ils étaient limités par le code principal.
Cette nouvelle API fait partie du cœur de Prosody et, même si elle en est à son début (bien plus de statistiques vont être ajoutées dans les futures versions), la base est là et les développeurs de modules peuvent d’ores et déjà l’utiliser.
Pour le moment, ces statistiques peuvent être regroupées en interne ou envoyées en externe à n’importe quel serveur conforme à « Statsd ». D’autres plates‐formes (N. D. T. : « backends ») peuvent être utilisées via des bibliothèques externes : nous avons par exemple l’intégration de « Datadog ».
Gestion simplifiée des certificats
Une des choses les plus difficiles dans la configuration d’un nouveau service XMPP était l’installation des certificats. En mettant les certificats à part, configurer une nouvelle instance de Prosody sur un serveur Debian/Ubuntu ne demande pas plus qu’une commande (apt install prosody) et l’édition d’une ligne dans le fichier de configuration (remplacer localhost par votre nom de domaine). Mais, obtenir et mettre en place les certificats, et savoir si vous deviez ajouter ou non un certificat « intermédiaire » n’étaient pas simple.
Mais, heureusement, les nouveaux projets Let’s Encrypt et le protocole ACME résolvent les problèmes associés à l’obtention et la gestion des certificats.
Nous avons fait des progrès similaires pour simplifier la gestion des certificats dans Prosody. Par exemple, si vous utilisez Let’s Encrypt, vous n’avez pas besoin d’ajouter quoi que ce soit pour modifier les paramètres de certificat dans le fichier de configuration de Prosody ! Une simple commande va automatiquement « importer » un nouveau certificat (ou le mettre à jour) pour les hôtes de votre fichier de configuration Prosody, et les activer immédiatement sans redémarrage.
Nous nous attendons à ce que cette fonctionnalité soit utilisable par la grande majorité des installations. Cependant, pour ceux qui ont besoin d’une configuration plus fine, la vieille méthode « manuelle » fonctionne toujours pour apporter plus de contrôle sur la configuration des certificats.
Tout ce que vous devez savoir sur la gestion des certificats de Prosody est dans la documentation.
Prise en charge de Lua 5.2
Lua 5.2 fut une étape importante dans l’évolution du langage. Cette version est sortie depuis un moment. Prosody s’est cantonné à l’usage de Lua 5.1 pendant un certain temps pour de nombreuses raisons (incluant la volonté que Prosody reste compatible avec LuaJIT). Mais, ça y est. Cette nouvelle version apporte la gestion initiale permettant de faire fonctionner Prosody avec Lua 5.2. Il peut toujours y avoir quelques problèmes (N. D. T. : « edge cases »), donc nous encourageons les personnes à utiliser Lua 5.2 et à remonter les problèmes. Pour l’instant, un serveur de production devrait continuer à utiliser Lua 5.1.
Gestion native des WebSockets
Cette version ajoute également la prise en charge officielle des connexions WebSocket. Beaucoup de clients Web peuvent déjà les utiliser, pour se connecter à Prosody depuis du JavaScript sans avoir à implémenter BOSH.
Un grand merci à Florian Zeitz pour la contribution initiale à ce module.
Autres améliorations
En fin de compte, nous avons réalisé beaucoup d’améliorations et de corrections dans cette branche. Cela inclut la gestion d’un nouveau et plus simple protocole de blocage (mod_blocklist), et de nombreuses améliorations de l’API interne pour les développeurs de modules, leur permettant de bénéficier des montées de version.
Mise à jour
Si vous mettez à jour, n’oubliez pas de lire les notes de version qui vous simplifieront la vie !
La série 0.9.x de Prosody continuera d’être maintenue pour les failles de sécurité importantes jusqu’à au moins juin 2018.
Téléchargement
Comme d’habitude, les instructions de téléchargement pour différentes plates‐formes peuvent être trouvées sur notre page de téléchargement.
Si vous avez des questions, commentaires ou autres problèmes avec cette version, faites‐nous‐le savoir !
Initialement publié le 2 octobre 2017 par l’équipe Prosody.
Aller plus loin
- Annonce « Prosody 0.10.0 released » (140 clics)
- Site de Prosody (374 clics)
- Notes de version (84 clics)
# Fonctionnalités pour mobile
Posté par jnanar (site web personnel) . Évalué à 6.
Merci beaucoup pour cette dépêche.
Est-ce qu'un spécialiste pourrait indiquer ce qu'il manque à Prosody pour que ses utilisateurs puissent avoir une expérience moderne optimale?
Je trouve XMPP très intéressant et je m'en sert au quotidien mais c'est vrai qu'il n'est pas toujours facile de trouver l'information pour faire des choses modernes. Cela semble changer et j'espère bien pouvoir expérimenter ces nouvelles possibilités prochainement.
Sinon, à titre personnel, je trouve l’ambiance sur les salons officiels de SàT, Movim, JabberFR très conviviale et on y apprend souvent des choses intéressantes.
[^] # Re: Fonctionnalités pour mobile
Posté par Goffi (site web personnel, Mastodon) . Évalué à 7.
je viens de jeter un œil au code qui teste ça, ça teste uniquement la présence de la fonctionnalité
#publish-optionset ça me semble un peu curieux voire trompeur. Cette fonctionnalité permet de configurer un nœud Pubsub à sa création. En d'autres termes et dans le cas présent, ça permet d'autoriser des gens qui ne sont pas dans la liste de contacts (roster) à accéder aux infos OMEMO (clef publique je suppose) au moment où on créé le nœud, c'est à dire l'endroit où sont enregistrées ces infos.Sauf que si cette fonctionnalité n'est pas présente, il est tout à fait possible de faire la configuration dans un deuxième temps (avec une autre requête XMPP), c'est juste un peu moins efficace.
Bref, je ne vois pas l'intérêt ce test, ou alors j'ai loupé quelque chose.
La fonctionnalité
#publish-optionsne semble pas pas présente dans ejabberd (je viens de tester surpubsub.movim.eu), et je ne sais pas pour mod_pep_plus (utilisant SàT pubsub, je ne suis pas le développement du composant interne de très près).Oui, et je pense qu'il sera toujours (longtemps du moins) utile et pas que pour Prosody, je dois écrire un billet de blog sur le sujet depuis un moment mais je manque de temps. En gros Pubsub c'est plus ou moins la base de donnée de XMPP (ou plutôt une interface standard pour les bases de données), et c'est un composant complexe à écrire. Les implémentations serveurs sont inégales, et quand une fonctionnalité apparaît, on est dépendant du bon vouloir/des possibilités des équipe de dév et du cycle de sortie des serveurs pour en profiter.
Avec SàT Pubsub, on a un composant générique et indépendant, on est sûrs d'avoir tout ce qu'on veut (si ça manque on implémente nous même) et il peut fonctionner potentiellement partout.
Outre ce que j'ai dit plus haut, je crois que c'est la seule implémentation libre actuelle qui implémente MAM qui permet notamment la recherche, il implémente l'attribut
publisher(qui permet de vérifier qui a publié un élément), RSM (résultats par pages), a la persistance, les modèles d'accèsopen,presence, etwhitelist(cf. l'épisode 8 de Parlons XMPP), et d'autre bricoles. Il est testé en permanence avec un client qui fait du blog, donc adapté à ça.En plus de ces fonctionnalités, c'est aussi un terrain d'expérimentation avec notamment un accès spécifique
publisher-rosterqui couplé aux permissions fines permet d'avoir des éléments (billets de blog par exemple) réservés à un groupe (fonctionnalités appelée par ailleurs « cercles » ou « aspects »), et depuis récemment des « schémas de nœud » qui permettent entre autre de contrôler ce que les gens peuvent publier. Là aussi je dois écrire un billet sur le sujet, et je compte proposer ceci à la standardisation (quand j'aurai du temps là encore :-/ ).Pour le 3ème point, je pense que Link Mauve ou mathieui pourront te répondre.
Oui c'est vrai, et il y a un travail fait par différents acteurs pour améliorer ça, espérons que ça porte les fruits rapidement.
:).
[^] # Re: Fonctionnalités pour mobile
Posté par jnanar (site web personnel) . Évalué à 1.
Merci pour toutes ces précisions. J'ai un serveur privé qui implémente une bonne partie de ces fonctionnalités et je vais commencer à m'amuser avec pubsub (celui de prosody dans un premier temps) et peut-être PEP. Effectivement, les nœuds disparaissent au redémarrage du serveur. Je peux configurer les nœuds PEP avec gajim mais pas créer d'entrée de blog. J'essayerai avec Salut-à-Toi (jp) pour mieux comprendre.
[^] # Re: Fonctionnalités pour mobile
Posté par Goffi (site web personnel, Mastodon) . Évalué à 4.
jp a été pas mal amélioré sur ce point dans la version de dév, mais la 0.6.1 le permettait déjà. Tu as un tuto sur mon blog si tu veux, sinon
jp blog --helpetjp pubsub --helpdevraient te permettre de t'en sortir, ou alors viens sur le salon de SàT je peux t'aider.[^] # Re: Fonctionnalités pour mobile
Posté par mathieui (site web personnel) . É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: Fonctionnalités pour mobile
Posté par Link Mauve (site web personnel) . Évalué à 2.
Plus précisément, c’est la version 1.2.2 qui est présente en ce moment, dans Stretch, Buster et Sid.
# Off The Record
Posté par Anonyme . Évalué à 4.
Comment fonctionne carbon copy avec OTR ?
[^] # Re: Off The Record
Posté par Goffi (site web personnel, Mastodon) . Évalué à 5.
Si l'implémentation est faite correctement (en suivant les recommandations de la XEP), le message n'est pas copié (seul le destinataire aura le message).
Si ça n'est pas fait correctement, le message chiffré sera copié, et ignoré par les appareils qui ne peuvent pas le lire, donc un peu de bande passante/processeur utilisés pour rien.
Je pense que la plupart des clients actuels sont dans le premier cas (donc le message n'est pas copié inutilement).
[^] # Re: Off The Record
Posté par Anonyme . Évalué à 2.
Oui, ça me paraissait logique, je voulais en être sûr.
Est-ce qu’il y a une solution pour chiffrer les communications tout en gardant la possibilité de faire du multi-périphériques ?
[^] # Re: Off The Record
Posté par Goffi (site web personnel, Mastodon) . Évalué à 5.
Oui c'est ce que font OMEMO et OX (OpenPGP fait correctement), c'est d'ailleurs le principal intérêt par rapport à OTR.
# Conséquences ?
Posté par Apichat (site web personnel) . Évalué à 2. Dernière modification le 06 octobre 2017 à 09:05.
Ces évolutions (en particulier la gestion native des WebSockets) permettent-elles d'utiliser prosody pour faire tourner un client web comme Movim ?
Par ailleurs, Aeris m'avait indiqué lors d'un bref échange sur Twitter qu'un outils à la Mastodon, avec des flux publics, ne pouvait pas fonctionner à base de XMPP. Qu'en pensez-vous ?
Voici l'échange :
[^] # Re: Conséquences ?
Posté par Goffi (site web personnel, Mastodon) . Évalué à 7.
Movim peut fonctionner avec Prosody, mais il sera en mode « dégradé » : la fonctionnalité qui manque principalement est la persistance des données en PubSub (le problème est pour la partie blog : les billets ne seront pas conservés après un redémarrage du serveur).
Le composant que nous développons pour SàT, SàT Pubsub mentionné plus haut, permet la persistance et fonctionne avec Prosody, donc il règle ce problème mais il faut attendre la sortie d'une version stable (enfin c'est utilisable en l'état, mais pas trivial à installer).
c'est des conneries.
On a déjà des flux publics, et côté blog mis à part XMPP a depuis longtemps montré qu'il était capable de tenir de très forte charges, notamment avec des serveurs comme Ejabberd. Mais bon, c'est pas la première fois et sans doute pas la dernière qu'on lit n'importe quoi à propos de XMPP.
[^] # Re: Conséquences ?
Posté par Anonyme . Évalué à 2.
Faut voir de qui ça vient aussi…
[^] # Re: Conséquences ?
Posté par edhelas (site web personnel) . Évalué à 4.
Petite précision ici, Movim utilise bien la technologie WebSocket, mais coté navigateur, il se connecte à XMPP de façon standard (flux TCP avec TLS), rien de particulier n'est à configurer coté serveur pour qu'il fonctionne donc :)
# XMPP, Pas facile de s'y retrouver
Posté par guildem . Évalué à 6. Dernière modification le 06 octobre 2017 à 11:18.
On ne peut que féliciter le travail fait sur Prosody, bien entendu.
Mais j'ai toujours autant de mal avec XMPP. Un protocole de messagerie instantanée open-source multi-serveur est primordial, et de par son ancienneté, XMPP s'est fait une belle place (limitée bien sûr, par rapport aux messageries fermées Facebook/Hangout/Skype/…).
Seulement, à chaque fois que je regarde ce qui est disponible comme serveurs/clients, je me trouve confronté à son plus grand inconvénient : savoir quel serveur et quel client prend en compte chaque extension.
Au final, j'en retire toujours la même impression (peut être fausse, ce n'est qu'une impression) : que XMPP est un protocole open-source fragmenté.
Existe-t-il un site qui répertorie tous les serveurs/clients les plus connus/utilisés, avec leurs fonctionnalités, sous forme d'un tableau, et à jour ?
Edit: Je n'avais pas vu celui de wikipédia : https://en.wikipedia.org/wiki/Comparison_of_instant_messaging_clients
C'est une bonne base, mais ça ne m'enlève pas cette impression ;)
[^] # Re: XMPP, Pas facile de s'y retrouver
Posté par Goffi (site web personnel, Mastodon) . Évalué à 5. Dernière modification le 06 octobre 2017 à 11:54.
ce n'est pas que de la messagerie instantanée, c'est beaucoup plus large que ça.
Ça complique bien sûr, mais c'est aussi l'intérêt : tu as le choix et surtout des outils adaptés à des cas particuliers. C'est un peu comme pour les courriels, tu as le choix entre des dizaines/centaines de clients, mais ils fonctionnent tous ensemble.
D'un autre côté, si tu regardes en dehors de XMPP pour la messagerie aujourd'hui c'est pire : tu as le choix entre des dizaines/centaines de logiciels, mais qui ne fonctionnent pas ensemble la plupart du temps.
Après si tu ne veux pas t'embêter, tu as des solutions tout en un (client + serveur), je crois qu'OpenFire et MongooseIM vont dans ce sens.
« fragmenté » n'est pas le mot qui convient, c'est un protocole qui a de nombreuses implémentations, mais elle fonctionnent ensemble.
Wikipédia en effet, également https://xmpp.org/software/clients.html, https://xmpp.org/software/servers.html ou encore https://www.zash.se/xmpp-features.html. Mais ça n'est pas super simple pour un nouveau venu et ces tableaux sont difficiles à lire/utiliser, il y a des améliorations à faire dessus c'est évident.
[^] # Re: XMPP, Pas facile de s'y retrouver
Posté par guildem . Évalué à 1.
Merci pour ta réponse, ça m'apporte pas mal de pistes. Le dernier tableau que tu as mis est assez indigeste, mais c'est le genre de tableaux que je recherche.
Bien aussi pour MongooseIM, qui sur son site donne des liens pour des bibliothèques d'implémentations de XMPP afin de créer son propre client.
Je vais continuer de m'y intéresser et tester Prosody (qui a la bonne idée d'avoir un docker).
[^] # Re: XMPP, Pas facile de s'y retrouver
Posté par dani . Évalué à 6.
Qui fonctionnent partiellement et/ou peut être ensemble. C'est bien là le problème. Dans le cas de la messagerie instantanée (certes pas l'unique but de XMPP, mais un des principaux), selon ton client, ton serveur, et idem pour l'autre côté, les chances que les bonnes XEP soient implémentées, activées, et correctement configurées sont si faibles, que dans la pratique, on ne peut pas vraiment compter dessus. À moins de contrôler l'ensemble de la chaîne (donc, hors fédération), on est donc obligé de retomber sur les fonctions minimales, celles définies dans le core du protocole, et quelques XEP suffisamment anciennes et simples pour être disponibles à peu près partout.
[^] # Re: XMPP, Pas facile de s'y retrouver
Posté par Goffi (site web personnel, Mastodon) . Évalué à 5. Dernière modification le 06 octobre 2017 à 14:53.
C'est très à la mode de critiquer le côté modulaire de XMPP alors que c'est au contraire son grand point fort.
Tous les protocoles qu'on utilise ou presque évoluent, y compris ceux qu'on utilise actuellement: HTTP et HTML et Javascript. Il y a des fonctionnalités qui évoluent, qui sont améliorées, abandonnées, etc. C'est le cycle de vie de pratiquement tout ce qui touche à l'informatique.
Sur HTML/Javscript les fonctionnalités sont testées dans le navigateur, souvent de manière assez crade (on teste si une méthode existe pour javascript par exemple, avant on testait carrément le nom du navigateur ce qui était très, très moche). C'est sans doute moins visible de nos jours parce que les butineurs ont de grosses équipes et sont mis à jour très vite (et je suppose que sur ce site la plupart des visiteurs ont des butineurs récents), et aussi parce qu'il y a des « polyfills », ces rouleaux de papier adhésif pour essayer de faire marcher des fonctionnalités un peu partout.
Sur XMPP c'est fait proprement (annonce des fonctionnalités, découverte, négociation, espaces de nommage, etc), je ne vois pas trop ce qu'il y a à critiquer de ce côté.
D'autre part il y a de nombreux logiciels qui utilisent XMPP, avec des anciennetés, des objectifs, des équipes et moyens différents, et donc des implémentation différentes. C'est normal que des fonctionnalités ne soient pas disponibles partout, et ça fonctionne tout de même (et on peut même encore utiliser un client qui a été écrit il y a 10 ans sur le réseau, même s'il n'a pas été maintenu).
Aussi je dois avoir beaucoup de chance parce que les fonctionnalités que j'utilise sont souvent implémentées. Je ne contrôle même pas tous mes serveurs (mon compte principal est sur
jabber.frque je n'administre pas, même si je peux demander quelque chose aux admins si j'en ai besoin), et bien évidement je n'ai aucun contrôle sur le client que la personne utilise en face.Alors bien sûr si vous prenez comme étalon un trucs très récent et en cours de standardisation comme OMEMO, forcément ça n'est pas partout pour tout un tas de raison (débats sur les spécifications, certains n'en veulent pas, dans certains cas comme le web ça n'est pas trivial, etc.), mais c'est déjà présent dans un bon nombre de clients.
Et pour des tas de fonctionnalités, il n'y a pas besoin que ça soit implémenté partout. Le blog par exemple, rien n'empêche d'utiliser Gajim ou Xabber qui ne l'implémentent pas, et d'avoir Movim sur le web.
[^] # Re: XMPP, Pas facile de s'y retrouver
Posté par dani . Évalué à 6.
C'est à la fois son grand point fort, et son principal défaut
Non, je parle de fonctions de base, comme l'envoi de fichiers, ou les appels audio vidéo. Ou encore le carbon copy, l'historique côté serveur. Pour tout ça, c'est au bon vouloir de celui qui administre le serveur. Puis l'utilisateur doit vérifier si son client supporte ça aussi. C'est déjà trop compliqué (ou plutôt pénible) pour un technophile. C'est pas unique à XMPP, c'est simplement un fait. Sur un réseau fédéré, on est forcé de se limiter au dénominateur commun, c'est extraordinairement difficile d'évoluer ensuite. Le problème d'XMPP par contre (selon moi) est que ce dénominateur commun est trop limité. Tout est défini dans des XEP, et l'on ne peut pas garantir qu'elles seront disponibles sur toute la chaîne.
[^] # Re: XMPP, Pas facile de s'y retrouver
Posté par Zenitram (site web personnel) . Évalué à 4. Dernière modification le 06 octobre 2017 à 16:08.
La critique est que des truc de base ne sont pas implémentés partout.
C'est en option? Techniquement super! mais l’utilisateur s'en fout. il voit juste que des trucs de base sont pas dispos sous XMPP, que ce soit en option ou pas n'est pas son problème.
tiens, ça me rappelle ATM, avec la même publicité (Ethernet et IP c'est pas propre, on vous a fait un protocole propre, nous ha ha ha on va vous niquer), mais qui utilise ATM de nos jours (à part en couche basse d'ADSL que personne ne voit vraiment et plus la par historique qu'autre chose)? Le truc pas propre, ben il a un avantage : il répond au besoin, lui.
C'est normal, à condition qu'on ne vienne alors pas demander aux gens "normaux" de l'utiliser dans la vie de tous les jours.
Faut se décider : soit c'est une protocole ayant pour but de concurrencer les logiciels proprios, soit c'est un marché de niche.
Le discours des défenseurs de XMPP est incohérent : d'un côté, ils militent pour une utilisation par la "masse", de l'autre ils font le nécessaire pour que XMPP réponde à des besoin de niche uniquement.
On s'en sort plus, donc on fuit XMPP en tant que "masse", normal.
Ben voila, c'est bien le problème : en fit, pour des trucs de base, on devrait se dire que la personne en face va forcément le supporter, car c'est de base. Mais en fait, ben non, car pas de chance en face il y a un logiciel pourri conseille par un fan XMPP qui n'a pas compris qu'il y a un minimum à fournir de base pour conseiller un logiciel client.
Je crois que les gens prennent surtout comme étalons ce que fait la concurrence.
Tant que les gens faisant la pub de XMPP ne comprendront pas qu'il faut un minimum syndical dans tous les logiciels dont il font la pub, il y aura juste un problème de compréhension.
Ici, tu montres que tu n'as pas compris le problème avec XMPP pour les gens "masse", qui est que prendre un logiciel au pif dans la liste "en pub" ne garantit pas d'avoir un minimum des fonctionnalités attendues de base par un utilisateur de base (sérieux, "copie carbonne" mis comme révolution dans la dépèche alors que ce n'est que rattraper un retard de 10 ans, transfert de photo, voix, vidéo, c'est la base depuis 10 ans ailleurs, ou à la sortie pour les logiciels ayant moins de 10 ans)
On te parle expérience utilisateur, tu répond technique propre, c'est très démonstratif du fossé qu'il y a entre les utilisateurs potentiels et les développeurs passionnés. Et tant que ce problème ne sera pas compris, ça n'avancera pas : XMPP sera pris pour un truc inadapté à la messagerie instantanée moderne (d'il y a 10 ans) à utiliser que par les geeks aimant bidouiller (et pour les autres, on vous oblige à utiliser Skype, WhatsApp et compagnie, faute d'offre correcte compréhensive en XMPP pour vous)
[^] # Re: XMPP, Pas facile de s'y retrouver
Posté par Torrone . Évalué à 1.
Faux dilemme. XMPP est un protocole, pas une application. Et son point fort est justement que sa modularité permet de l'utiliser pour une application de niche ET pour une application grand public.
Ce n'est pas pour rien que les messageries qui ont du succès actuellement on démarré en implémentant XMPP (Google, WhatsApp, Signal…)
"Le discours" que tu critique n'existe pas, car il n'y a pas d'utilisateur type de XMPP. C'est un protocole ouvert aux implémentations multiples. Les usages peuvent être très différent d'une application à une autre.
Si un discours dur XMPP ne te plaît pas, n'écoute pas.
La seule voix officielle, c'est celle là : https://xmpp.org/
C'est quoi un "truc de base" ?
Un exemple :
Les appels vidéo dans WhatsApp ne sont disponible que depuis moins d'un an.
Jingle sur XMPP ça date de 2005.
Tant que tu ne comprendras pas que le but dans la vie d'un développeur ce n'est pas forcément de prendre la place de WhatsApp mais que ça peut être de répondre aux besoins d'un client, d'une communauté, à ses propres besoins, tu auras toujours un problème de compréhension.
[^] # Re: XMPP, Pas facile de s'y retrouver
Posté par Frank-N-Furter . Évalué à 9.
Une XEP sans implémentations, qui fonctionnent, ça sert a rien.
Depending on the time of day, the French go either way.
[^] # Re: XMPP, Pas facile de s'y retrouver
Posté par Maclag . Évalué à 9.
Soyons honnêtes, tu ne peux pas dire que XMPP c'est juste un protocole et pas une appli quand ça t'arrange et mettre en avant des XEP quasiment implémentées par personne pour dire que "c'est disponible" quand ça t'arrange.
Ça fait un moment que je recommence à suivre ce qui se passe dans le petit monde XMPP pour la communication instantanée en général, et j'ai repris un peu espoir, mais là si j'acquiesce à ce que tu dis, autant que j'abandonne en même temps!
La question du journal c'est pourquoi XMPP n'est pas plus populaire.
Ta réponse: c'est parce que les dévs des clients actuels n'en ont rien à carrer de ce que veut la majorité des gens.
Ils visent chacun un marché de niche, et plusieurs marchés de niche même mis ensembles ne feront jamais une masse critique.
Si tu veux que XMPP soit plus populaire, il faut une appli qui fasse aussi bien et même mieux que Whatsapp pour inciter les utilisateurs à migrer.
Si l'attitude des dévs consiste à dire "m'en fous de ce que veulent 90% des utilisateurs potentiels", ben ils resteront avec une base utilisateurs faible, ce qui serait d'autant plus dommage que les 2 plus prometteurs pour le grand public (Movim et SàT) auraient bien besoin de ressources (dons ou sponsorisation pour le dév de certaines fonctions).
J'espère donc que leur but est de développer des outils "pour tout le monde", et c'est bien l'impression que j'en ai.
[^] # Re: XMPP, Pas facile de s'y retrouver
Posté par Torrone . Évalué à 6.
Ça tombe bien, je ne le fais pas.
Il suffit d'une seule implémentation pour que ce soit utilisé. Et il y en a bien plus qu'une, moi je n'appelle pas ça "quasiment personne" :
Asterisk PBX
Coccinella
Empathy
FreeSWITCH
Gajim
Google Talk
iChat
Jabbin
Jitsi
KDE Telepathy
Kopete5
MCabber
Miranda IM
Monal IM-Client
Pidgin
Psi
QIP Infium
Yate/YateClient
Tu voudrais quoi de plus ? WhatsApp, c'est une seule implémentation, pourtant ils ne doivent pas être loin du milliard d'utilisateurs. Tu te trompes de critères.
Il me semble plutôt que c'est la présentation de Prosody 0.10.
Ce n'est pas ce que j'ai dit. J'ai dit que XMPP était un protocole aujourd'hui sous la direction de L’Internet Engineering Task Force (IETF). Le but de l'IETF est de proposer et maintenir des standard, pas de mettre à mort WhatsApp.
Les développeurs, eux répondent aux besoins de leurs clients, aux ordre de leur employeur, à leurs propre volonté etc. Tout dépend de leur situation, tu ne peux rien en déduire de général.
Les utilisateurs, ils se foutent du protocole, ce qu'ils veulent c'est un produit qui répondent à leurs besoins. Ces besoins dépendent des personnes et de leur situation. Encore une fois, tu ne peux rien en déduire de général. Le produit pour tous le monde n'existe pas et n'existera jamais dans ce domaine.
Donc "90% des utilisateurs potentiels", ça ne veut rien dire. Il faut un contexte pour définir quels sont les utilisateurs potentiels. Ce contexte peut-être :
XMPP sert ou à servi dans tous ces cas de figure, des centaines de millions d'utilisateurs se sont servi de ce protocole à travers ses divers implémentations et services commerciaux. Ça fait longtemps qu'il a fait ses preuves.
Donc concrètement, tu veux quoi de plus ? Qu'il deviennent le standard quasi unique comme HTML ou le mail ?
Peut-être que ça arrivera un jour, mais pour l'instant, ce qui rapport du fric, ce sont les communautés fermées qui servent à capter les données personnelles des utilisateurs. Et pour ça, l'interopérabilité ne sert à rien.
Tant que le fric sera le plus puissant moteur et que le meilleurs moyen d'avoir ce fric ne passe pas uniquement par XMPP, alors il y aura d'autres alternatives au moins aussi rependues.
[^] # Re: XMPP, Pas facile de s'y retrouver
Posté par Maclag . Évalué à 5. Dernière modification le 10 octobre 2017 à 00:49.
Euh…
Donc on ne compare pas parce que c'est un protocole.
Donc on compare un peu quand même.
Je suis en train de parcourir la liste et je ne pense pas qu'on se comprenne:
Tous ces clients implémentent Jingle Video et peuvent s'appeler les-uns les-autres?
Depuis 2005?
Sujet du commentaire, pas du journal. D'ailleurs c'est une dépêche.
Lapsus ou confusion, au choix, ça change pas le fond.
Exactement!
Quel est l'intérêt d'un standard à tout faire pour tout le monde si à la fin il ne sert que des marchés de niche ou des applications bien spécifiques?
Je ne veux pas Skype pour la famille, Whatsapp pour les potes et bon, aller: XMPP pour les 3 geeks dans mon entourage.
Je veux un standard unique et respectueux de ma vie privée pour dialoguer avec tout le monde.
Tu mélanges le but des éditeurs et des utilisateurs.
Les éditeurs veulent les revenus. Les utilisateurs veulent un outil qui fait tout ce qu'ils veulent et plus et qui soit répandu. Si ça ne rapporte rien aux dévs ils s'en carrent pas mal pour la plupart.
Le fric est un atout dans le développement, c'est tout. Si tu as un meilleur outil Libre et sur standard ouvert disponible, un gros compte en banque ne suffira pas à faire migrer les utilisateurs.
[^] # Re: XMPP, Pas facile de s'y retrouver
Posté par Torrone . Évalué à 0.
On compare protocole avec protocole et application avec application.
On s'en fout, ce n'est pas la question. Le fait est que des centaines de millions de personnes utilisaient jingle via Google 10 ans avant que WhatsApp ne propose une fonction équivalente.
Aujourd'hui, Google ne permet plus cela mais de nombreuse application le permettent.
Demande aux millions de personnes qui l'utilisent au quotidien…
C'est ça le problème dans un monde libre, toi tu veux ça, les autres pas forcément. Tu ne pourras pas imposer ta vision des choses à tout le monde.
Le standard existe déjà. L'usage est du ressort des éditeurs/développeur et des utilisateurs qui sont les juges ultimes.
En quoi ça s'opposerait à ce que j'ai dit ?
Sans fric, tu m'expliqueras comment tu fais pour promouvoir ton produit et gagner des part de marcher dans un contexte ultra concurrentiel.
Illustration avec 3 applications mobiles qui ont à peu près les même fonctionnalités :
- WhatsApp : vaut 19 milliards pour Facebook, plus d'un milliards d'utilisateurs
- Signal : budget annuel de quelque million de dollars, de 5 à 10 millions d'utilisateurs
- AstraChat : budget consacré à la messagerie probablement équivalent ou inférieur à celui de Signal, entre 10 000 et 50 000 installation sur google play
- Conversation : un développeur seul, entre 10 000 et 50 000 installation sur google play (propose maintenant moins de fonctionnalités que les 3 premiers)
Toutes ces applications son un dérivée de (WhatsAPP, Signal) ou sont actuellement basées sur (Astrachat, Conversation) XMPP. Ce qui fait la différence dans le nombre d'utilisateurs, c'est la force de frappe commerciale.
[^] # Re: XMPP, Pas facile de s'y retrouver
Posté par Maclag . Évalué à 5.
Faudrait savoir. Un coup tu dis que Jingle était disponible avant la vidéo sur Whatsapp. Je te signale que non faute d'implémentations, maintenant ça n'a pas d'importance!
Hangout gère les appels vidéo.
La vidéo sur XMPP c'est encore délicat (Jingle à "l'ancienne" vs WebRTC).
Signal est arrivé après que Whatsapp eut raflé le marché sans apporter rien de plus que Whatsapp n'ait encore pu ajouter.
Astrachat ne fait pas les appels vidéo à ma connaissance, seulement audio.
Et dans les 3 cas tu confonds popularité avec valeur financière: Whatsapp n'a pas utilisé 19milliards pour devenir populaire. Il a été valorisé à partir de sa base utilisateur et son potentiel de croissance.
Non, tu mélanges toute la séquence!
Whatsapp a d'abord été populaire pour sa simplicité (pas d'inscription formelle) et ses fonctionalités. Ensuite il a eu de plus en plus d'utilisateurs, ensuite le pognon est tombé!
Tu ne crois quand même pas que FB a laché 19milliards pour financer juste une bonne idée??
Développer une telle appli, c'est des ressources, et oui, ça manque, mais tu n'as pas besoin de milliards pour que ça prenne! Il faut que ce soit bon, simple et que ça apporte des choses nouvelles!
[^] # Re: XMPP, Pas facile de s'y retrouver
Posté par oinkoink_daotter . Évalué à 4.
Euh, t'es sûr de ça ?
De mémoire, historiquement, WhatsApp utilisait XMPP tout seul dans son coin. Ils ont switché sur le Signal Protocol il y a quelques temps. Les gens derrière Signal n'ont pas l'air de trop aimer XMPP. Le seul rapport que je vois avec XMPP est un protocole crypto, Double Ratchet, inventé (en partie ?) par les gens d'Open Whisper, et qui a ensuite été repris et standardisé par une XEP.
[^] # Re: XMPP, Pas facile de s'y retrouver
Posté par dani . Évalué à 5.
Que l'argent y joue, probablement. Mais ce n'est pas le cœur du problème. Ce qui pousse tout ces géants à se fermer à la fédération, même si ils utilisent XMPP, c'est pour contrôler l'expérience utilisateur, et assurer que tout fonctionnera. Comme XMPP a été créé pour être modulaire, et que tout est définie sous forme d'extensions, tu ne peux pas t'assurer que la personne en face supportera quoi que ce soit, en dehors des fonctions de base. Du coup, un utilisateur de ton service qui discute avec un autre, par la fédération aura l'impression que mon service est nul parce que "ça marche pas, je ne peux pas envoyer des fichiers", alors que le problème vient de son contact, qui utilise un serveur et/ou client qui n'implémente pas ce qu'il faut. Donc pour éviter ça, on coupe la fédération, et on garantie aux utilisateurs de notre service une expérience optimale. Et ça, c'est bien un problème qui provient de la modularité d'XMPP.
[^] # Re: XMPP, Pas facile de s'y retrouver
Posté par devnewton 🍺 (site web personnel) . Évalué à 10.
Si quelqu'un demande un client et un serveur http/html/javascript, on peut citer de tête des couples qui vont implémenter 99% de fritures et juste marcher: Firefox et Nginx, Chromium et Apache.
Avec XMPP, c'est loin d'être le cas.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: XMPP, Pas facile de s'y retrouver
Posté par Zenitram (site web personnel) . Évalué à 2.
l'exemple est pas mal : je ne connais aucun agent mail parmi des centaines qui n'ont pas la possibilité basique de faire "répondre à tous".
Le problème de XMPP, c'est bien ça : des trucs de base ne sont pas dans tous les clients XMPP, du coup on (utilisateur) pète un câble : obligé de faire comme si on devait chercher un client mail qui a la fonctionnalité "répondre à tous" car c'est compris comme un cas particulier par les développeurs?
Sérieusement, que la "copie carbone" soit une nouveauté en 2017 dans un logiciel de messagerie instantanée est un sérieux problème sur la compréhension entre ce qui est sensé être de base (Skype le faisait il y a 10 ans quand même…) et ce qui est est "cas particuliers", et répondre que c'est juste super et normal qu'il y ai des cas particulier est ne pas comprendre le pourquoi XMPP n'a pas marché (que ce soit protocole ou logiciels, l'utilisateur s'en fout, il voit juste que ça ne marche pas)
Oui, mais ça fonctionne avec les gens qu'on a en contact, au pire on installe les apps différente et c'est bon on a la "copie carbone" pour sûr (avec les logiciels utilisés par la "masse"), mieux vaut avoir la "copie carbonne" sur 10 apps non XMPP que de chercher parmi 100 app XMPP laquelle a cette fonctionnalité (en risquant d'en trouver aucune), question de temps à consacrer à s'emmerder à chercher.
Bref, le problème de XMPP est peut-être dans le refus de voir les problèmes de XMPP en face (voir les réactions "pas notre faute" dans le dernier journal sur le sujet, alors que la demande était justement de comprendre pourquoi ça n'avait pas marché, sans avoir mis un "mais dites-nous des choses qui nous dédouane, car on veut que ce soit la faute des autres").
Ici, "tu as le choix" est l'opposé complet de la bonne réponse à apporter à une personne qui critique (surtout quand la personne dit justement qu'elle n'a pas tant le choix que ça en pratique, c'est nier le problème de la personne qui te parle d'une des raisons pour lesquelles ce n'est pas utilisé), si on veut avoir des utilisateurs.
[^] # Re: XMPP, Pas facile de s'y retrouver
Posté par Thomas Douillard . Évalué à 9.
Je sais que ce n'est pas du tout ton objectif principal, mais si tu arrétais de personnaloser les débats àtpjt bout de champ ce serait quand même une bonne chose pour l'ambiance.
[^] # Re: XMPP, Pas facile de s'y retrouver
Posté par Crao . Évalué à 6. Dernière modification le 08 octobre 2017 à 11:20.
Non il a raison. Au final XMPP est une plaie pour ceux qui lui ont fait confiance en se disant que les fonctionnalités de base (transfert de fichier, envoi d'images, audio et vidéo, partage d'écran) arriveraient rapidement et facilement, et 10 ans après on reste avec du chat de base parce que le reste ne fonctionne pas. Et encore certains clients comme Gajim régressent et sont de plus en plus buggés, au point que j'ai du arrêter de l'utiliser. Skype est systématiquement utilisé pour tout ce qui n'est pas messagerie instantanée.
Vous ne vous rendez pas compte à quel point la communauté XMPP a été décevante et a perdu toute crédibilité.
[^] # Re: XMPP, Pas facile de s'y retrouver
Posté par Thomas Douillard . Évalué à 4.
Tu entends quoi par "de plus en plus buggué" ? C'est étrange car encore maintenu.
[^] # Re: XMPP, Pas facile de s'y retrouver
Posté par Crao . Évalué à 1.
Je parle de la version Windows de Gajim.
Des palanquées de fenêtres d'erreur qui surgissent de façon aléatoire, qu'on essaie de discuter avec quelqu'un ou non. Le message d'erreur n'est pas vraiment informatif, mais ça a l'air lié au chiffrement.
Il est souvent impossible de discuter avec quelqu'un les messages n'arrivant plus : le seul moyen est que chacun redémarre Gajim de son côté.
Erreur lors de la suppression d'un contact qui n'existe plus sur le serveur. J'ai même créé un bug : https://dev.gajim.org/gajim/gajim/issues/8296
Depuis que je suis passé à Pidgin (toujours sous Windows) il n'y pas plus le moindre problème. L'interface est bien moins sympathique que Gajim mais au moins la messagerie instantanée fonctionne…
[^] # Re: XMPP, Pas facile de s'y retrouver
Posté par TutoMaker . Évalué à 4.
Tu utilises Skype sur Linux pour faire autre chose que de l'IM? Tu dois pas pouvoir faire grand chose vu que microsoft n'a pas fournis de skype à jours depuis des années ancestrales et que la majeure partie des fonctionnalités ne fonctionnaient plus depuis longtemps.
Si vous codez un logiciel sans une interface chatoyante, alors vous faites de la merde. Donation bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: XMPP, Pas facile de s'y retrouver
Posté par qpad . Évalué à 6.
Une nouvelle beta linux est sortie récemment :
https://blogs.skype.com/news/2017/03/01/the-skype-for-linux-beta-version-5-0-is-now-available-for-download/
Je partage avec regrets la déception vis a vis de XMPP exprimée dans les commentaires… par exemple dans mon entourage pro, skype est de facto le système de messagerie.
[^] # Re: XMPP, Pas facile de s'y retrouver
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
J'ai passé un entretien via Skype il y a peu, l'occasion de retester ce service qui soit disant juste marche:
Bref ça marche moins bien que les sites de visioconférences basés sur WebRTC (y compris ma propre solution bricolée à l'arrache™ https://b3.bci.im/visio).
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: XMPP, Pas facile de s'y retrouver
Posté par Maclag . Évalué à 4.
De nos jours, c'est encore plus confus parce qu'il y a Skype et "Skype for business" (feu "Lync").
Skype marchait bien jusqu'à il y a peu (les mauvaises langues diront jusqu'au rachat par Microsoft…).
La version web, récente… et bien j'espère la faire marcher un jour, comme ça j'aurai une opinion.
La version Android me coupe le haut-parleur de temps en temps, ça semble aléatoire. Désactiver et ré-activer le HP résoud le problème, mais ça fait pas super sérieux.
Quant à Skype for business, je n'ai jamais essaté la vidéo, mais on s'en sert au taf pour l'audio et le partage d'écran. Ça marche bien la plupart du temps, mais on perd vite les partages si la connexion est moyenne, et c'est invisible pour le présentateur (il faut parfois 2 slides passés pour que l'auditoire se rende compte que ça ne colle plus et le signale).
L'audio marche plutôt bien par contre. On n'utilise presque plus les téléphones.
[^] # Re: XMPP, Pas facile de s'y retrouver
Posté par Blaise (Mastodon) . Évalué à 0.
Et Whatsapp le fait toujours pas !
(Bon c'est un cas "particulier", Whatsapp n'autorise qu'un seul client, donc ça élimine le besoin de "copie carbone".)
[^] # Re: XMPP, Pas facile de s'y retrouver
Posté par Zenitram (site web personnel) . Évalué à -1.
1/ WhatsApp est une appli pensée pour mobile, qu'on a toujours sur soit, unique. C'est déjà moins utile que pour une appli (ou protocole) pensé pour du multi-machine (comme XMPP, avec une notion de ressource; en gros ils ont pensé à ce que l'utilisateur du protocole ai plusieurs lieux, mais "oublié" de les synchroniser, donc c'est une fonctionnalité non poussée à sa vraie utilité). Pour résumer, WhatsApp a regardé ce qui était important pour sa cible et a fait le taf nécessaire pour répondre au besoin de la cible, quand XMPP fait tout à moitié sans avoir vraiment réfléchi à une cible, du coup quasi personne ne l'utilise et préfère un truc moins "global" mais complet pour son besoin.
2/ Si "Whatsapp le fait toujours pas", et "Whatsapp n'autorise qu'un seul client", je me demande bien comment je fais pour avoir les mêmes messages sur mon Windows que sur mon téléphone… Non, vraiment, entre ce que tu dis et ce que j'ai en vrai, je pense plutôt me dire que tu te trompes (OK, je sais, c'est de la bête synchro, il faut que le téléphone soit actif, c'est un "hack"; mais voila, le "hack" répond au besoin car le téléphone n'a pas vocation a être éteint, c'est la différence antre la beauté théorique de XMPP et la réalité pratique de Skype, WhatsApp…)
note : je sais, je triche, l'app Windows de WhatsApp n'est pas bien vieille… Tout comme la voix dans WhatsApp; mais justement, il faut peut-être se demander pourquoi XMPP n'a pas pris en 10 ans quand une app comme WhatsApp avec "peu" de fonctionnalités décolle instantanément alors que ça fait "pareil" que des clients XMPP depuis 10 ans. Ne pas se dire qu'il manque un truc quelque part, vraiment?
Bref, il faut voir la cible, mais parait (voir commentaire qu'on m'a fait) que le but de XMPP n'est pas de prendre le taf de Skype ou WhatsApp, mais de répondre à un "besoin client", le hic c'est ensuite de voir les défenseurs de XMPP s'étonner que personne ne l'utilise dans la "masse", perso quand je vois autant de schizophrénie ça me fait rester loin de la chose (tiens, comme pas mal de monde, malgré la volonté de certains de vouloir m'enfermer dans "mon expérience perso" pour ne pas voir le problème global), et les réactions "outrées" des défenseurs de XMPP quand on leut montre le problème n'est pas fait pour rassurer sur le futur de XMPP (vous voudriez inciter les gens à fuir XMPP que vous ne feriez pas autrement, ou comment les libristes flinguent tout ce qui pourrait concurrencer le proprio, il faut croire qu'il y a une volonté de se flageller, de trouver une excuse pour dire "on a essayé", c'est dommage de vouloir absolument se dire "on a essayé" sans viser à… Vraiment essayer).
Argh… j'ai trop brodé, alors que c'est peine perdue, ce sera toujours "la faute aux autres par la triche, nous on est parfaits" quoiqu'il soit dit. Arrêtons donc la.
[^] # Re: XMPP, Pas facile de s'y retrouver
Posté par erdnaxeli (site web personnel) . Évalué à 2.
Il y avait un autre journal il y a peu qui se demandait pourquoi le XMPP ne perce pas, je pense qu'on a un début de réponse. Je suis du même avis : que la possibilité de suivre une conversation sur plusieurs devices soit une feature qui apparaît en 2017 est tout simplement aberrant.
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
[^] # Re: XMPP, Pas facile de s'y retrouver
Posté par jnanar (site web personnel) . Évalué à 2.
Comme indiqué dans la dépêche, il existe depuis des années des modules communautaires pour les fonctionnalités carbon et mam. Ces modules n'étaient pas inclus officiellement mais ils étaient tout à fait optionnels depuis longtemps. Les liens ci-dessus reprennent un résumé de ces modules.
https://modules.prosody.im/mod_mam.html (opérationnel depuis prosody 0.9, 2013 )
https://modules.prosody.im/mod_carbons.html (opérationnel depuis prosody 0.8, 2011 )
On est loin des 10 ans de skype mais mam et carbon ne sont pas des nouveautés de 2017.
[^] # Re: XMPP, Pas facile de s'y retrouver
Posté par Goffi (site web personnel, Mastodon) . Évalué à 8.
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.
[^] # Re: XMPP, Pas facile de s'y retrouver
Posté par BAud (site web personnel) . Évalué à 0.
irssi dans un screen permettait de le faire depuis 1999 pour IRC.
À noter qu'un plugin irssi-xmpp entièrement réécrit en 2009 permettait de le faire pour XMPP aussi.
Voir Irssi, GNU_Screen, et https://cybione.org/~irssi-xmpp/
[^] # Re: XMPP, Pas facile de s'y retrouver
Posté par Maclag . Évalué à 6.
Tout comme absolument 100% des applis de chat en terminal depuis 1987, année de création de screen.
Faudrait peut-être pas confondre un hack avec une fonctionnalité.
[^] # Re: XMPP, Pas facile de s'y retrouver
Posté par Tonton Th (Mastodon) . Évalué à 3.
/me pertinente[^] # Re: XMPP, Pas facile de s'y retrouver
Posté par edhelas (site web personnel) . Évalué à 6. Dernière modification le 14 octobre 2017 à 19:30.
En lançant une VM avec une Ubuntu et un client XMPP, puis ne me connectant en bureau à distance dessus j'arrive aussi à garder synchronisé mes messages tout le temps depuis partout! Génial!
[^] # Re: XMPP, Pas facile de s'y retrouver
Posté par dani . Évalué à 2. Dernière modification le 12 octobre 2017 à 13:00.
C'était possible avant, mais ce n'est que maintenant que c'est activé par défaut (d'ailleurs, est-ce que ça l'est, ou faut-il le configurer explicitement ?)
# voip
Posté par tuxicoman (site web personnel) . Évalué à 3.
Et la voip sur smartphone sur base de contacts XMPP c'est pour quand?
Pourquoi Jingle n'est pas/plus/jamais implémenté sur smartphone?
[^] # Re: voip
Posté par Goffi (site web personnel, Mastodon) . Évalué à 5.
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.
[^] # Re: voip
Posté par devnewton 🍺 (site web personnel) . Évalué à 1.
Pourquoi ne pas abandonner Jingle alors? Ca doit faire une dizaine d'années que Jingle ne fonctionne pas bien. WebRTC juste marche. Il faut arrêter l'acharnement thérapeutique :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: voip
Posté par Goffi (site web personnel, Mastodon) . Évalué à 4. Dernière modification le 23 octobre 2017 à 12:13.
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).
[^] # Re: voip
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
J'ai l'impression que c'est la position de tous les projets XMPP: du coup aucun n'implémente le minimum feature set pour un utilisateur normal :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: voip
Posté par yv_2000 . Évalué à 2.
C'est dommage car c'est justement ce qui me manque le plus, un logiciel qui fasse correctement de la communication orale (et facultativement, vidéo, mais c'est moins important) et qui passe correctement et de manière transparente les pare-feux, même si tous les clients sont derrière un pare-feu.
Mon problème est d'arriver à proposer un système alternatif à Skype ou WhatsUp à des usagers lambdas, permettant de substituer avec profit les systèmes téléphoniques (surtout dans des pays où les communications coûtent cher). Malheureusement, les alternatives que je tente de proposer à mes relations (professionnelles ou non) ne sont pas crédibles ou sont difficiles à mettre en œuvre (pour eux). Je suis actuellement sur une option SIP (avec linphone), mais ça ne passe pas bien les pare-feux. Jitsi n'est pas acceptable, trop lourd et plante souvent, ou alors la transmission de la communication s'arrête et on se retrouve avec un grand blanc alors que la communication est encore active.
J'ai du coup beaucoup de mal à justifier mon refus de passer à WhatsUp (bizarrement, les gens ne me parlent pratiquement plus de Skype).
J'ai longtemps espéré une option XMPP, mais je vois que les choses sont plus compliquées que je ne le pensais et que cette option est encore loin de se réaliser. Dommage…
En tout cas, si un jour tu penses à faire un module détaché de SàT qui fasse ça, tu feras un gros groupe d'heureux (maigres). Merci infiniment par ailleurs pour ton énorme contribution au développement d'alternatives libres dans ce domaine.
[^] # Re: voip
Posté par Goffi (site web personnel, Mastodon) . Évalué à 4.
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.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.