C'est une architecture distribuée dans laquelle les données sont persistées, n'importe qui peut déployer son serveur et garder le contrôle de ses données.
Je chipote un peu mais c'est également le cas de XMPP.
historique par défaut
http://xmpp.org/extensions/xep-0313.html XEP-0313: Message Archive Management, déjà implémenté sur de nombreux serveurs et commence à être implémenté dans de nombreux clients
XMPP supporte l'authentification SASL, le chiffrement est maintenant obligatoire entre les serveurs (voir l'initiative https://xmpp.net/) et très souvent sur les clients (via StartTLS). Pour du chiffrement bout en bout des normes comme OTR sont maintenant largement déployés sur les clients XMPP (même si je trouve ça pas très très propre sur le coté protocolaire).
Je me suis penché sur Matrix il y a quelques semaines, car je me suis demandé qu'est ce qui pouvait pousser un groupe de développeurs à vouloir réinventer un nouveau protocole pour une énième fois alors que XMPP semble offrir tout ce qu'il faut.
Mais bon j'ai bien eu l'impression qu'il s'agissait plus d'une envie de repartir sur une nouvelle base au lieu de prendre le chemin de la difficulté et d'avoir à travailler avec la XSF pour améliorer/compléter XMPP.
Si c'est l'interconnexion avec le Web qui les embêtes :
Oui, lire des normes c'est compliqué, et on est pas toujours d'accord avec ce qui est écrit. Mais quand le protocole est utilisé par des dizaines de serveurs utilisés par des universités, entreprises, multinationales, gouvernements, particulier; des centaines de clients sur toutes les plateformes et a plus de 15 ans d'ancienneté avec plusieurs RFC à l'IETF c'est plus compliqué de mettre tout le monde d'accord :) Pour le reste j'ai déjà écrit un commentaire là dessus il y a quelques jours http://linuxfr.org/nodes/105862/comments/1606599.
Le dernier point que je voulais aborder concerne l'une des spécificités de Matrix : fonctionner en HTTP.
Je pense que cette décision est une grave erreur, pourquoi ? Car HTTP amène un overhead énorme (oui c'est considérable quand il s'agit de gérer des listes de 400 contacts avec plusieurs dizaines de connections, des salons et des messages dans tous les sens). De plus cantonner un protocole "social/IM" au Web uniquement a une conséquence terrible : c'est compliqué de faire autre chose que du Web.
Le Web n'est qu'une petite partie d'Internet. Donc quand on base un protocole sur des technologies Web (HTTP en l'occurence) c'est plus difficile d'en sortir.
Getting live state
This will block waiting for an incoming event, timing out after several seconds. Even if there are no new events (as in the example above), there will be some pagination stream response keys. ... If it has been a long period of inactivity, there may be LOTS of events waiting for the user. In this case, you may wish to get all state instead and then resume getting live state from a newer end token.
C'est ce qu'on appelle plus communément du long-polling, j'ouvre une requête HTTP, le serveur me répond quand il a quelque-chose à dire et j'en renvoie une autre derrière. Croyez moi sur des grosses charges ça ne tiens pas. Si vous voulez avoir du temps réel faite du socket (pure TCP ou WebSocket), encore une fois vous vous compliquez la vie et vous allez compliquer la vie des clients qui souhaiteraient faire du "vrais" temps réel et qui devront le simuler en utilisant des librairies comme Curl pour recréer un système évènementiel derrière.
[^] # Re: Ça ca parler de Matrix ou de l'IM en général au final ?
Posté par edhelas (site web personnel) . En réponse au journal Qui veux débattre Messagerie Instantané au Jardin Entropique. Évalué à 9.
Pour la signalisation d'appels WebRTC il y a Jingle dans XMPP avec entre autres :
Jingle est déjà implémenté dans de nombreux clients tel que Jappix (via WebRTC) ou Jitsi (https://jitsi.org/).
Pour l'IoT :
Avec des intérêt par des industriels tel que Cisco (http://blogs.cisco.com/ioe/beyond-mqtt-a-cisco-view-on-iot-protocols).
Je chipote un peu mais c'est également le cas de XMPP.
XMPP supporte l'authentification SASL, le chiffrement est maintenant obligatoire entre les serveurs (voir l'initiative https://xmpp.net/) et très souvent sur les clients (via StartTLS). Pour du chiffrement bout en bout des normes comme OTR sont maintenant largement déployés sur les clients XMPP (même si je trouve ça pas très très propre sur le coté protocolaire).
Je me suis penché sur Matrix il y a quelques semaines, car je me suis demandé qu'est ce qui pouvait pousser un groupe de développeurs à vouloir réinventer un nouveau protocole pour une énième fois alors que XMPP semble offrir tout ce qu'il faut.
Mais bon j'ai bien eu l'impression qu'il s'agissait plus d'une envie de repartir sur une nouvelle base au lieu de prendre le chemin de la difficulté et d'avoir à travailler avec la XSF pour améliorer/compléter XMPP.
Si c'est l'interconnexion avec le Web qui les embêtes :
Et même :
Oui, lire des normes c'est compliqué, et on est pas toujours d'accord avec ce qui est écrit. Mais quand le protocole est utilisé par des dizaines de serveurs utilisés par des universités, entreprises, multinationales, gouvernements, particulier; des centaines de clients sur toutes les plateformes et a plus de 15 ans d'ancienneté avec plusieurs RFC à l'IETF c'est plus compliqué de mettre tout le monde d'accord :) Pour le reste j'ai déjà écrit un commentaire là dessus il y a quelques jours http://linuxfr.org/nodes/105862/comments/1606599.
Le dernier point que je voulais aborder concerne l'une des spécificités de Matrix : fonctionner en HTTP.
Je pense que cette décision est une grave erreur, pourquoi ? Car HTTP amène un overhead énorme (oui c'est considérable quand il s'agit de gérer des listes de 400 contacts avec plusieurs dizaines de connections, des salons et des messages dans tous les sens). De plus cantonner un protocole "social/IM" au Web uniquement a une conséquence terrible : c'est compliqué de faire autre chose que du Web.
Le Web n'est qu'une petite partie d'Internet. Donc quand on base un protocole sur des technologies Web (HTTP en l'occurence) c'est plus difficile d'en sortir.
Et quand je vois ça dans la documentation de Matrix (http://matrix.org/docs/howtos/client-server.html) :
C'est ce qu'on appelle plus communément du long-polling, j'ouvre une requête HTTP, le serveur me répond quand il a quelque-chose à dire et j'en renvoie une autre derrière. Croyez moi sur des grosses charges ça ne tiens pas. Si vous voulez avoir du temps réel faite du socket (pure TCP ou WebSocket), encore une fois vous vous compliquez la vie et vous allez compliquer la vie des clients qui souhaiteraient faire du "vrais" temps réel et qui devront le simuler en utilisant des librairies comme Curl pour recréer un système évènementiel derrière.