Les salons sont distribués sur tous les serveurs qui y participent. Il n'est donc pas possible de faire fermer un salon en supprimant un serveur qui l'hébergerait
Je ne pense pas qu'une réplication systématique soit une bonne chose pour beaucoup de raisons (maîtrise des données et ressources notamment), mais elle est très intéressante si elle est optionnelle.
Note qu'il est possible de le faire avec XMPP aussi (XEP-0282 et XEP-0289), mais c'est vrai que je ne connais aucune implémentation en pratique (je ne sais même pas trop ce que les XEPs valent, il faudrait regarder ça en détails). Aussi MIX (le nouveau protocole de chat en court d'élaboration/implémentation) devrait permettre aussi la réplication.
Enfin qu'on aime ou pas cette fonctionnalité, c'est vrai que Matrix le fait aujourd'hui, et XMPP en pratique non, reste à voir si c'est une fonctionnalité critique pour la personne qui choisi.
Par contre je crois me souvenir que le serveur principal de matrix était tombé il y a quelque temps, et que ça avait sacrément perturbé le réseau (à confirmer, je suis ça de très loin). Est-ce qu'en pratique la réplication permet vraiment de fonctionner sans accroc quand notre serveur principal tombe ?
Le protocole est versionné au lieu d'avoir un cœur simpliste et toute une collection d'extensions optionnelles. C'est ce qui fait que XMPP ne marche pas dans le monde réel : pour pouvoir utiliser des fonctions élémentaires, il faut que toute la chaîne (ton client, ton serveur, le serveur de ton interlocuteur, le client de ton interlocuteur) supporte les mêmes XEP et que tout soit bien configuré. Comme c'est rarement le cas, et qu'il n'y a aucune façon de le garantir ... On fini par ne plus l'utiliser pour envoyer des fichiers par exemple (puisque trop de risque que ça ne passe pas). Je parle même pas d'appels audio/vidéo. Avec Matrix, ça juste marche.
Ça c'est faux. Il y a très peu de fonctionnalités qui demandent que toute la chaîne implémente quelque chose (en fait je n'en vois aucune là tout de suite), excepté PEP qui est implémenté par absolument tout le monde (c'est nécessaire pour publier des infos comme des clefs publiques). L'audio vidéo peut fonctionner si uniquement les clients l'implémentent, le serveur ne fait que fournir une aide pour traverser les réseau difficiles, et même là il suffit qu'un des 2 serveurs implémente ce qu'il faut.
L'envoi de fichier marche à ma connaissance avec tous les clients et serveurs, ça fait combien d'années que tu n'as pas essayé ?
Matrix utilise justement XMPP pour les appels audio/vidéo (via Jitsi Meet qu'il embarque), sauf pour les appels 1:1 qui sont du webRTC (et là c'est les navigateurs qui font le boulot principal).
Et en pratique, combien de clients autres que le client principal de Matrix (Element) implémentent toutes les fonctionnalités ? Est-ce qu'il y a un seul client tiers qui le fait ? Ils ont exactement le même problème pour la même raison : c'est une question de ressource, et le client principal de Matrix avance bien parce qu'ils ont de l'argent pour payer des équipes de développement à plein temps (tant mieux pour eux), mais les clients tiers n'ont pas souvent les moyens de suivre au même rythme.
[^] # Re: Matrix vs XMPP
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Messagerie instantanée : ce n’est pas une question d’applications. Évalué à 7. Dernière modification le 02 février 2021 à 13:40.
Je ne pense pas qu'une réplication systématique soit une bonne chose pour beaucoup de raisons (maîtrise des données et ressources notamment), mais elle est très intéressante si elle est optionnelle.
Note qu'il est possible de le faire avec XMPP aussi (XEP-0282 et XEP-0289), mais c'est vrai que je ne connais aucune implémentation en pratique (je ne sais même pas trop ce que les XEPs valent, il faudrait regarder ça en détails). Aussi MIX (le nouveau protocole de chat en court d'élaboration/implémentation) devrait permettre aussi la réplication.
Enfin qu'on aime ou pas cette fonctionnalité, c'est vrai que Matrix le fait aujourd'hui, et XMPP en pratique non, reste à voir si c'est une fonctionnalité critique pour la personne qui choisi.
Par contre je crois me souvenir que le serveur principal de matrix était tombé il y a quelque temps, et que ça avait sacrément perturbé le réseau (à confirmer, je suis ça de très loin). Est-ce qu'en pratique la réplication permet vraiment de fonctionner sans accroc quand notre serveur principal tombe ?
Ça c'est faux. Il y a très peu de fonctionnalités qui demandent que toute la chaîne implémente quelque chose (en fait je n'en vois aucune là tout de suite), excepté PEP qui est implémenté par absolument tout le monde (c'est nécessaire pour publier des infos comme des clefs publiques). L'audio vidéo peut fonctionner si uniquement les clients l'implémentent, le serveur ne fait que fournir une aide pour traverser les réseau difficiles, et même là il suffit qu'un des 2 serveurs implémente ce qu'il faut.
L'envoi de fichier marche à ma connaissance avec tous les clients et serveurs, ça fait combien d'années que tu n'as pas essayé ?
Matrix utilise justement XMPP pour les appels audio/vidéo (via Jitsi Meet qu'il embarque), sauf pour les appels 1:1 qui sont du webRTC (et là c'est les navigateurs qui font le boulot principal).
Et en pratique, combien de clients autres que le client principal de Matrix (Element) implémentent toutes les fonctionnalités ? Est-ce qu'il y a un seul client tiers qui le fait ? Ils ont exactement le même problème pour la même raison : c'est une question de ressource, et le client principal de Matrix avance bien parce qu'ils ont de l'argent pour payer des équipes de développement à plein temps (tant mieux pour eux), mais les clients tiers n'ont pas souvent les moyens de suivre au même rythme.