Sans vouloir nous mettre trop en avant, je pense qu'on est en plein dans ce que tu recherches (et Movim aussi sur certains points). Plus en détails:
Pourquoi est-ce que personne ne fait de la messagerie un peu plus poussée avec les fonctionnalités qu'on attendrait aujourd'hui (historique illimité, recherche, multi-appareils, chiffrement end-to-end, asynchronicité,...) ?
Si si, on fait ! historique illimité, recherche, multi-appareils c'est MAM + Message Carbons et les implémentations sont de plus en plus courantes.
Chiffrement de bout en bout c'est un peu plus compliqué parce qu'il n'y a pas de bonne solution avec XMPP (c'est une vieille marotte et il y a eu plusieurs tentatives, mais rien n'a encore été largement adopté). La seule solution un peu populaire c'est OTR, et elle n'est pas (encore) standardisée en XMPP ! C'est des bidouillages de l'utiliser, mais ça fonctionne tant bien que mal, d'ailleurs on l'implémente dans SàT (et même 2 fois parce qu'on a décidé de faire une implémentation dans le navigateur pour l'interface web). Asynchronicité c'est de base dans XMPP, quel est ton problème avec ?
XMPP a tout sur le papier pour remplacer SMTP et faire du chiffrement par défaut (dans la veine du point précédent); personne n'en fait rien...
Le chiffrement est de base dans XMPP et même obligatoire depuis plus d'un an. Et pour SMTP là encore on peut par dire qu'on ne fait rien: c'est un truc dont on parle depuis plus de 4 ans (lire ici), on a un serveur IMAP, un serveur SMTP et un stockage Maildir dans SàT, et on fera certainement une passerelle SMTP pas pour cette version mais pour la prochaine.
XMPP a tout sur le papier pour remplacer twitter, et j'ai pas vu de grand mouvements de ce côté là.
Il me semble que ce journal montre justement le contraire. Tu peux essayer Movim ou Jappix, ou la démo de Libervia pour voir ce qu'on peut déjà faire, mais il y a encore du boulot c'est sûr.
C'est parce que XMPP a pour philosophie de tout faire sur le serveur ce qui est une aberration immense à mon avis
L'idée de base c'était - je pense - de se dire qu'il y a moins besoin de serveurs différents que de clients différents, et donc de simplifier la vie des développeurs de clients. La philosophie est toujours valable: si tu veux utiliser juste la partie messagerie instantanée de XMPP, ou juste la partie messagerie style courriel, tu peux facilement. Si tu veux des choses avancée, il faut de toute façon souvent des implémentations côté serveur et client (MAM par exemple).
il n'y a pas besoin de demander l'autorisation à qui que ce soit pour tenter quelque chose
Ben les nouvelles XEPs vont justement sacrément faciliter les choses de ce côté maintenant.
Et la standardisation est un avantage énorme sur tout nouveau protocole, et à qui il faudra un temps fou (ça se compte en années) avant d'arriver au niveau de XMPP.
Nous ça faisait longtemps qu'on attendait d'être débloqué pour le microblogage, maintenant je ne vois plus rien de majeur qui va nous gêner, et je pense ne pas trop m'avancer en disant que l'utilisation et les fonctionnalités de XMPP vont exploser sous peu.
[^] # Re: XMPP et messagerie instantanée, la donne est pourrie ?
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal XMPP et (micro)blogage: la donne a changé. Évalué à 5.
Sans vouloir nous mettre trop en avant, je pense qu'on est en plein dans ce que tu recherches (et Movim aussi sur certains points). Plus en détails:
Si si, on fait ! historique illimité, recherche, multi-appareils c'est MAM + Message Carbons et les implémentations sont de plus en plus courantes.
Chiffrement de bout en bout c'est un peu plus compliqué parce qu'il n'y a pas de bonne solution avec XMPP (c'est une vieille marotte et il y a eu plusieurs tentatives, mais rien n'a encore été largement adopté). La seule solution un peu populaire c'est OTR, et elle n'est pas (encore) standardisée en XMPP ! C'est des bidouillages de l'utiliser, mais ça fonctionne tant bien que mal, d'ailleurs on l'implémente dans SàT (et même 2 fois parce qu'on a décidé de faire une implémentation dans le navigateur pour l'interface web). Asynchronicité c'est de base dans XMPP, quel est ton problème avec ?
Le chiffrement est de base dans XMPP et même obligatoire depuis plus d'un an. Et pour SMTP là encore on peut par dire qu'on ne fait rien: c'est un truc dont on parle depuis plus de 4 ans (lire ici), on a un serveur IMAP, un serveur SMTP et un stockage Maildir dans SàT, et on fera certainement une passerelle SMTP pas pour cette version mais pour la prochaine.
Il me semble que ce journal montre justement le contraire. Tu peux essayer Movim ou Jappix, ou la démo de Libervia pour voir ce qu'on peut déjà faire, mais il y a encore du boulot c'est sûr.
L'idée de base c'était - je pense - de se dire qu'il y a moins besoin de serveurs différents que de clients différents, et donc de simplifier la vie des développeurs de clients. La philosophie est toujours valable: si tu veux utiliser juste la partie messagerie instantanée de XMPP, ou juste la partie messagerie style courriel, tu peux facilement. Si tu veux des choses avancée, il faut de toute façon souvent des implémentations côté serveur et client (MAM par exemple).
Ben les nouvelles XEPs vont justement sacrément faciliter les choses de ce côté maintenant.
Et la standardisation est un avantage énorme sur tout nouveau protocole, et à qui il faudra un temps fou (ça se compte en années) avant d'arriver au niveau de XMPP.
Nous ça faisait longtemps qu'on attendait d'être débloqué pour le microblogage, maintenant je ne vois plus rien de majeur qui va nous gêner, et je pense ne pas trop m'avancer en disant que l'utilisation et les fonctionnalités de XMPP vont exploser sous peu.