Sommaire
(pour lire les épisodes précédents, suivez l'étiquette correspondante)
En plus de cette partie centrale, des fonctionnalités peuvent être ajoutées, d'où le X de XMPP (pour eXtensible).
Les extensions sont rédigées sous la forme de « XEP » (XMPP Extension Protocol), idée héritée — si je ne m'abuse — de Python. C'est de cela qu'on parle quand on voit les cryptiques XEP-0XXX dans les fonctionnalités gérées d'un serveur ou d'un client. Pas besoin évidemment de savoir cela pour utiliser un client XMPP, mais il peut être utile de lire une extension (elles se trouvent sur https://xmpp.org/xmpp-protocols/xmpp-extensions/) pour bien comprendre à quoi sert une fonctionnalité. Deux parties sont particulièrement utiles sans avoir à entrer dans les détails d'implémentation : la partie « abstract » (résumé) tout en haut qui indique ce que la XEP fait, et la section « introduction » (la toute première section) qui explique un peu plus les raisons et les cas d'utilisations de l'extension.
Une XEP peut décrire une fonctionnalité, une procédure (par exemple la XEP-0001 explique le cycle de vie des XEPs elles-mêmes), un héritage historique (c'est à dire le fonctionnement de quelque chose créé avant la XMPP Standard Foundation), une information (comme des bonnes pratiques), voire une blague (si si, y'a des histoires de toto dans les XEPs aussi !). Elle peut avoir plusieurs statuts (expliqués dans la XEP-0001, je ne sais pas s'il existe une version traduite en français quelque part). Il est intéressant de noter que beaucoup de XEPs sont « experimentales », et donc techniquement pas (encore) des standards, mais souvent implémentées tout de même. De telles XEPs peuvent changer fortement avant le passage au statut de « brouillon » (« Draft »), puis de standard final.
Pourquoi je vous parle de tout ça ? Pour que vous compreniez bien une chose: XMPP ce n'est pas que de la messagerie instantanée !
Voici quelques exemples d'extensions intéressantes:
Extended Stanza Addressing (Adressage de « stanzas » étendue, XEP-0033): permet d'envoyer un message à plusieurs destinataires à la fois, ou de faire des copies carbones ou des copies carbones invisibles (comme le … oui oui vous voyez où je veux en venir)
Multi-User Chat (Discussions multi-utilisateurs, XEP-0045): les discussions de groupes, à la IRC.
Ad-Hoc Commands (commandes de circonstance, XEP-0050): un système générique pour gérer tout type de commandes. Lié aux permissions des utilisateurs, c'est un outil absolument génial !
vcard-temp (Cartes virtuelles, version temporaire, XEP-0054): la façon historique de gérer des cartes de visites, une sorte de profil public. Une nouvelle extension va la remplacer à terme (la XEP-0292)
Jabber Search (Recherche Jabber/XMPP, XEP-0055): pour chercher des jid, utilisé en général par les annuaires.
Publish/Subscribe (Publication/Abonnement, XEP-0060): un très gros morceau, qui permet la publication de tout type d'information, et sa récupération en fonction de permissions, avec un système de notification en temps réel.
XHTML-IM (XEP-0071): pour publier avec un sous-ensemble de XHTML, c'est à dire avec une mise en forme (écrire en gras ou mettre une image par exemple).
Gateway Interaction (Communication avec les passerelles, XEP-0100): permet de gérer les passerelles, c'est à dire des liens avec des réseaux extérieurs
Personal Eventing Protocol (protocole d'événements personnels, XEP-0163): une sorte de Publish/Subscribe simplifié
Jingle (XEP-0166): Négociation de session pair à pair (P2P), avec un grand nombre d'applications possibles, la plus connue étant la visioconférence.
Serverless Messaging (Communication sans server, XEP-0174): permet, comme indiqué, de se passer des serveurs
Message Archive Management (gestion des archives des messages, XEP-0313): permet de récupérer des messages ou autre (ça fonctionne aussi avec publish/subscribe) selon certains critères comme une date. Utilisé notamment pour avoir votre historique de conversations sur votre serveur (et ainsi y accéder depuis tous vos clients).
Et dites-vous bien qu'on ne vient que de gratter la surface.
Plusieurs de ces extensions seront expliquées dans de futurs articles.
À noter aussi qu'on utilise souvent des noms courts pour désigner les extensions par exemple « MAM » pour « Message Archive Management ». Ces noms sont normalement indiqués en fin de XEP, dans les appendices (« Document information »): c'est le « short name » (nom court).
Avec toutes ces extensions, on va se retrouver avec des clients ou serveurs qui gèrent l'une ou l'autre, comment se mettre d'accord ? Eh bien grâce à une autre extension (mais tellement indispensable et couramment implémentée qu'on peut presque la considérer comme standard de base): « Service Discovery » (découverte de services, XEP-0030, nom court : « disco »)).
Le principe est simple, chaque client ou serveur ou composant (un composant est un service qui vient se greffer à un serveur, voir plus bas) dit qui il est, ce qu'il sait faire, ou les éléments associés.
qui il est
Une adresse XMPP (le jid) peut être utilisée par beaucoup de monde: un serveur, un client, un « bot » (robot, nom qu'on utilise pour un programme qui automatise des tâches, agissant souvent comme un client), une passerelle, etc.
Quand un client (ou autre) en voit une, il est utile de savoir à quoi on parle, par exemple pour afficher de telle ou telle façon dans l'interface (c'est grâce à cela que votre client peut afficher une passerelle d'une autre façon que les clients normaux).
C'est l'identité de disco qui permet ça, et elle donne une catégorie (par exemple « client » ou « serveur »), un type (dans client par exemple ça peut être « bot », « web », « game » — jeu —), et un nom libre (par exemple « ejabberd »). Vous avez une liste des différentes catégories et les types associés ici : https://xmpp.org/registrar/disco-categories.html.
ce qu'il sait faire
XMPP grâce à son côté extensible, est très riche en fonctionnalités, aussi il est indispensable de savoir ce que le logiciel avec lequel on discute est capable de faire. Ce sont les « features » (fonctionnalités) indiquées par disco, c'est pour cette raison que parfois quand vous discutez avec quelqu'un une icône est grisée, par exemple la visioconférence: cela indique que le client en face indique qu'il ne sait pas la faire, ou plus exactement n'indique pas qu'il sait la faire.
Ces fonctionnalités sont liées à des espaces de nommage (namespaces) qui sont indiqués dans les XEPs concernées, vous avez aussi une liste qui permet de retrouver une partie des XEPs depuis un espace de nommage ici : https://xmpp.org/resources/schemas.
les éléments associés
En plus de l'identité et des fonctionnalités disponibles, une entité XMPP peut avoir des éléments associés. Ce peut être un serveur qui indique que des salons de discussions sont disponibles à telle adresse, ou une passerelle vers tel réseau.
essayons
Pour que cela soit plus clair, prenons un exemple. « jp », l'interface en ligne de commande de Salut à Toi, permet d'obtenir le disco d'une entité avec la commande « jp info disco », essayons avec le serveur jabber.fr :
% jp info disco jabber.fr
Features:
http://jabber.org/protocol/commands
http://jabber.org/protocol/disco#info
http://jabber.org/protocol/disco#items
http://jabber.org/protocol/stats
iq
jabber:iq:register
jabber:iq:time
jabber:iq:version
msgoffline
presence
presence-invisible
urn:xmpp:time
vcard-temp
--
Identities:
ejabberd (server/im)
--
Extensions:
http://jabber.org/network/serverinfo
--
Items:
[chat.jabberfr.org]
[irc.jabberfr.org]
[j2j]
[presence.jabberfr.org]
[proxy.jabberfr.org]
[users.jabberfr.org]On voit ici que jabber.fr sait gérer la version historique des vcards (vcard-temp, XEP-0054) ou les commandes ad-hoc (http://jabber.org/protocol/commands, XEP-0050), qu'on discute avec un serveur (server/im) qui s'appelle « ejabberd ». On voit également que plusieurs services sont disponibles, par exemple chat.jabberfr.org. Regardons de plus près :
% jp info disco chat.jabberfr.org
Features:
http://jabber.org/protocol/disco
http://jabber.org/protocol/muc
http://jabber.org/protocol/muc#unique
jabber:iq:browse
jabber:iq:last
jabber:iq:register
jabber:iq:time
jabber:iq:version
urn:xmpp:ping
vcard-temp
--
Identities:
Public Chatrooms (conference/text)
--
Items:
[...]
JabberFR (13) [jabberfr@chat.jabberfr.org]
[...]On voit qu'on a affaire à un service de salons de discussions (conference/text), qui utilise le protocole « Multi-User Chat » (discussions multi-utilisateurs, http://jabber.org/protocol/muc), qui est à ce jour le seul disponible pour les discussions de groupes (nous y reviendrons). Les éléments « Items » contiennent ici la liste des salons, avec le nom, le nombre d'occupants, et le jid correspondant, j'ai tronqué la liste qui était très longue.
Dans les informations de jabber.fr, vous avez peut-être remarqué la section « extensions », il s'agit d'une XEP (la XEP-0128) qui permet d'étendre disco pour tout type d'informations, dans le cas d'ejabberd ici, c'est pour indiquer les adresses de contact du serveur, mais elles ne sont pas renseignées pour jabber.fr.
Ci-dessous, la fenêtre disco de Gajim:
La première fois que j'ai essayé XMPP, avec Psi au début des années 2000, j'ai été un peu intimidé par le menu « service discovery », qui permet d'afficher quasi directement les informations que nous venons de voir. Ce genre de menu est souvent, à mon sens, affiché un peu trop « brut » dans les clients XMPP : utiliser disco directement (c.-à-d. en dehors de ce qui est automatisé par le client) relève déjà de l'utilisation avancée.
En bonus, je vais rapidement évoquer l'extension « software version » (version logicielle, XEP-0092) qui permet, comme son nom l'indique, de savoir à quel logiciel on parle, et le système d'exploitation utilisé. jp permet d'afficher ces informations avec « jp info version », essayons sur jabber.fr :
% jp info version jabber.fr
Client name: ejabberd
Client version: 2.1.13
Operating System: unix/linux 3.2.0On connaît désormais la version d'Ejabberd utilisée, pratique quand on veut savoir si une fonctionnalité est présente, ou un bogue corrigé. Et cela fonctionne avec toute entité qui implémente la XEP, pas uniquement les serveurs:
% jp info version chat.jabberfr.org
Client name: MU-Conference
Client version: 0.9-svn (Jan 27 2014)
Operating System: Linux 3.2.0-4-amd64Voilà, connaître les extensions permet de vraiment savoir ce qu'on peut faire avec un client ou un serveur. La prochaine fois je pense m'attaquer aux discussions de groupes, et voir ce qui change par rapport à IRC.
# Merci et une question
Posté par Julien.D . Évalué à 10.
XMPP est modulaire et c’est l’une de ses plus grandes force et faiblesse. Quand on parle à un connaisseur d’XMPP, il nous le présente comme un protocole multi-usages qui permet de faire des choses merveilleuses (et c’est vrai dans l’absolu). Mais quand on doit le présenter à quelqu’un, on ne peut le présenter que comme un protocole de messagerie, en mentionnant qu’il y a des projets en cours pour de la visio-conférence ou du microblogging tout simplement parce que dans les faits c’est loin d’être au point et quand ça l’est, ce sont les logiciels qui ne suivent pas. Tel serveur supporte ça, tel client supporte ça…
Bref, XMPP et les XEP c’est génial mais pour l’utilisation c’est assez « ça tombe en marche quand tout va bien ».
Pourquoi ne pas instaurer des versions d’XMPP ?
« pour prétendre faire du XMPP version 1, il faut implémenter pleinement et de manière fonctionnelle les XEP a, b et c ».
Pour la version 2, il est nécessaire d’implémenter en plus les XEP d, e et f.
Cela inciterait les développeurs à implémenter les XEP, offrirait plus d’homogénéité et facilité la vie des utilisateurs.
Je suis un utilisateur d’XMPP, j’aime ce protocole, mais je suis déçu de ne pas pouvoir en utiliser toute la puissance.
[^] # Re: Merci et une question
Posté par Goffi (site web personnel, Mastodon) . Évalué à 7.
Pour la visio-conférence, ça devrait être au point au moins chez Jitsi (même si j'ai moi même eu des soucis, comme avec la quasi totalité des logiciels que j'essaye pour ça, XMPP ou pas), si ça n'est pas le cas il faut remonter les problèmes. Pour le microblogage on avance à grands pas.
Le problème majeur, est de bien choisir un serveur, ou, comme je le disais dans un commentaire sur un des articles précédents, de l'installer soi-même ou de demander à une assoce locale afin de pouvoir contacter facilement les admins et demander d'installer ce qu'il nous manque.
Pour les clients, il ne faut pas forcément en chercher un qui fait tout. Certains clients (comme le notre) cherchent à implémenter le maximum de fonctionnalités, mais XMPP est prévu pour utiliser plusieurs clients en même temps, et il est tout à faire logique d'avoir un peu de fonctionnalités un peu partout: par exemple un salon de discussion pour un jeu, ou un client qui ne fait que la vidéo, avoir du transfert de fichier intégré au bureau, etc. Donc si tu utilises un client, rien ne t'empêche d'en utiliser un autre pour une autre utilisation.
ça c'est effectivement une bonne idée, et y'a des débuts de réponse avec la XEP-0302 qui indique les XEPs à implémenter pour avoir un client moderne (enfin moderne en 2012 :-/), et https://xmpp.org/about-xmpp/technology-overview/ qui donne des XEPs à implémenter pour différents cas (on m'a donné le lien sur le salon XSF).
moi aussi, et c'est une des raisons qui m'a fait commencer SàT ;).
[^] # Re: Merci et une question
Posté par Fabien PRORIOL . Évalué à 4.
Bonjour, et merci pour tes articles…
Personnellement, j'utilise mon propre serveur, mais une question me reviens toujours…
Quel est aujourd'hui le meilleur serveur ? Je veux dire par la, avec un maximum d'XEP d’implémenté par exemple.
Je pensais après différente lecture a jabberd2, mais bizarrement, il n'existe pas sous Debian… pourquoi ???
Je cherche souvent a éviter les truc usine a gaz (en Java par exemple), et privilégie les serveur écrit en C++ ou autre langage compilé, mais bon, pour le moment, du coup, j'ai mis ejaberd, mais je ne sais pas vraiment si c'est un bon choix…
A terme, j'aimerais proposer des truc comme video-conference, voir SaT, mais je ne sais pas si c'est possible avec ce serveur…
Encore Merci
[^] # Re: Merci et une question
Posté par Goffi (site web personnel, Mastodon) . Évalué à 4.
salut, difficile de répondre à ça vu que ça part assez vite en guerre de religion. En général mon critère de choix quand plusieurs logiciels semblent équivalent, c'est d'être dans un langage que je connais ou facile à apprendre, pour pouvoir corriger en cas de soucis, mais c'est parce que je suis développeur que j'ai ce réflexe ;).
jabberd est le serveur le plus ancien, je ne l'ai moi même jamais utilisé et je ne sais même pas s'il est encore développé.
ejabberd est une version en Erlang, et un des serveurs les plus complets et les mieux suivis actuellement, une référence. Par contre de mémoire les logs ne sont pas super pratiques à lire, enfin il faut l'habitude quoi. Depuis peu on peut l'étendre avec Elixir, en plus de L'Erlang de base.
J'avais utilisé OpenFire qui était très facile à installer, c'est du Java.
Sinon nous on utilise principalement Prosody: léger, très facile à installer, c'est du lua qui s'apprend très vite pour qui sait déjà programmer, et la communauté est très active. C'est celui que je recommanderais, surtout que c'est à l'heure actuelle le seul qui a des modules pour les XEP-0355 et XEP-0356 qu'on va utiliser pour SàT (cf http://linuxfr.org/users/goffi/journaux/xmpp-et-micro-blogage-la-donne-a-change), même si d'autres serveurs vont très probablement suivre (chez Ejabberd par exemple on est en contact avec un dév).
[^] # Re: Merci et une question
Posté par Fabien PRORIOL . Évalué à 2.
Ok, en gros, y'a pas de choix simple; en effet, j'ai vu:
jabberd14 (C) (j'ai utiliser assez longtemps, mais semble abandonné depuis 2007!!!)
jabberd2 (C++), qui se veux être une ré-écriture, mais encore incomplet, et surtout, pas dans debian
ejabberd (erlang), en effet celui la me convient pour le moment, je l'ai même couplé avec le LDAP de Kolab, et ça fonctionne plutôt bien, mais c'est du erlang… et du coup, j'y comprend rien, même les log ou les fichiers de config sont tordu…
Après étant allergique au Java, j'ai pas testé OpenFire.
Prosody, jamais testé encore… je ne suis pas forcement fan de Lua, mais pas allergique non plus…
[^] # Re: Merci et une question
Posté par Goffi (site web personnel, Mastodon) . Évalué à 5.
Si Ejabberd te convient, c'est un bon choix. Prosody ça vaut vraiment le coup d'œil, Lua est simple à comprendre, et surtout très rapide. Et il y a beaucoup de modules communautaires (en plus des déjà nombreux modules officiels) pour utiliser avec à peu près n'importe quoi: https://prosody.im/doc/modules et https://code.google.com/p/prosody-modules/w/list .
[^] # Re: Merci et une question
Posté par rakoo (site web personnel) . Évalué à 6.
J'irais même plus loin concernant Prosody: le paquet de base répond déjà a 80% des besoins. S'il manque quelque chose, il y a une très forte chance qu'un module fasse l'affaire. Si c'est encore pas suffisant, en effet il faut soi faire du Lua soit passer par un composant externe. Ce qui en pratique revient a coder. Mais pour un usage "standard", il n'y a absolument pas besoin d'aller jusque la.
Prosody ça juste marche, c'est facile a installer et a utiliser, c'est stable, sans écrire une ligne de lua… Que demander de plus ?
[^] # Re: Merci et une question
Posté par Anonyme . Évalué à 4.
si je peux me permettre de profiter de cette perche: un tuto pour faire de la viso/audio conf avec son serveur prosody, c'est la seule chose qui me manque !
[^] # Re: Merci et une question
Posté par rakoo (site web personnel) . Évalué à 4. Dernière modification le 01 juillet 2015 à 23:07.
Les experts confirmeront, mais la visio conf c'est du Jingle, c'est-à-dire que c'est un problème purement client qui ne dépend absolument pas du serveur, puisque ce sont des choses qui se négocient de client à client; ça ne concerne donc pas prosody !
(Bon en réalité, pour ce qui est transport dans Jingle, typiquement la connexion directe de client à client ne marche pas, il vaut mieux passer par un tiers, comme par exemple un proxy SOCKS5. Ça tombe bien, Prosody peut faire proxy SOCKS5)
Par contre je te rejoins à 100% sur le sujet: si quelqu'un avait un tuto, ça serait super, ne serait-ce que pour se donner un coup de pied dans le derrière et implémenter ça un peu partout !
[^] # Re: Merci et une question
Posté par Anonyme . Évalué à 3.
il y aurait également otalk de AndYet qui utilise du WebRTC, mais bien que le code soit libre et disponible sur github, l'absence de docs et d'explications claires pour une mise ne place sur un serveur personnel m'a amené à faire une croix dessus
[^] # Re: Merci et une question
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3. Dernière modification le 02 juillet 2015 à 12:40.
oui jingle c'est pratiquement qu'une question de client, le serveur peut aider à établir une connexion ceci dit, et servir de relais si la connexion directe n'est pas possible. Enfin je ne suis pas spécialiste, n'ayant pas encore implémenté jingle on ne s'est pas trop penchés sur la question (mais on va le faire je pense assez vite pour le transfert de fichiers). Le mieux à faire est de demander directement sur le salon de Prosody: prosody@conference.prosody.im.
[^] # Re: Merci et une question
Posté par Anonyme . Évalué à 3.
pourquoi proxy65 (XEP-0065) ne vous convient pas pour le transfert de fichiers ? parce qu'il oblige à passer par le serveur ?
[^] # Re: Merci et une question
Posté par Goffi (site web personnel, Mastodon) . Évalué à 4. Dernière modification le 02 juillet 2015 à 14:05.
Nous avons déjà implémenté la XEP-0065 (socks 5, proxy65 c'est juste une implémentation - que nous utilisons d'ailleurs -), mais nous l'utilisons avec la méthode « historique » (la XEP-0096) qui est aussi la plus implémentée, mais qui a plusieurs soucis, en particulier elle traverse mal les NAT et firewalls.
Jingle permet aussi d'utiliser socks 5, mais la méthode de négociation est bien meilleure et permet d'établir une connexion dans pratiquement tous les cas, c'est la méthode recommandée aujourd'hui et c'est pour ça qu'il faut qu'on l'implémente.
Petite parenthèse: tu n'es pas obligé de passer par le serveur avec socks5, le proxy serveur n'est utilisé que si la connexion directe ne peut être établie.
[^] # Re: Merci et une question
Posté par Maclag . Évalué à 5.
J'avais lu que Jappix et Movim lui préféraient Metronome, qui est un fork.
Quelque temps est passé. Comment se comparent les 2 projets aujourd'hui?
[^] # Re: Merci et une question
Posté par Goffi (site web personnel, Mastodon) . Évalué à 5.
Jappix et Movim lui préféraient Metronome uniquement parce que Metronome sauve les données PEP/PubSub hors ligne. J'ai vu plusieurs fois le développeur principal de Prosody (à chaque rencontre XMPP, ou au Fosdem), et lui ai posé la question. En gros la philosophie de Prosody c'était de tout garder simple, tout fichier, et pas de SGBD. Le dev de Metronome a fait une implémentation simple (de ce qu'on m'a dit, je n'ai pas été vérifier) mais qui fonctionne.
Là chez Prosody je crois qu'ils sont en train de voir pour faire un système relativement générique pour pouvoir utiliser différentes bases de données, enfin je suis ça de très loin puisque on utilise une autre méthode avec notre propre composant Pubsub. Mais je peux te dire qu'ils sont très compétents techniquement, et je fais toute confiance en l'équipe de Prosody.
Le gars sur Metronome semble être seul, mais très dynamique. Côté prosody y'a une communauté bien en place, très dynamique aussi et accueillante: j'ai pu résoudre les problèmes que j'ai eu très rapidement avec leur aide sur le salon.
Bref, l'un ou l'autre c'est une question de goût et de ressenti personnel. Pour ce qui est des composants nécessaires pour Jappix et Movim, il pourront profiter de ce qu'on a fait avec les XEPs et les modules qui vont bien, ainsi que le service pubsub qu'on a, donc ils seront tout à fait utilisables avec Prosody sous peu (cf http://linuxfr.org/users/goffi/journaux/xmpp-et-micro-blogage-la-donne-a-change ).
# Migration de compte
Posté par Mildred (site web personnel) . Évalué à 6.
Ce qui me gêne toujours avec XMPP, c'est qu'il y a quand même pas mal de choses qui dépendent du serveur. Est-ce qu'il y a facilement moyen de changer de serveur. Déplacer toutes ses données d'un serveur a un autre ?
J'ai vu la XEP-0015, mais elle semble vieille et plus du tout d'actualité. Il faudrait une méthode pour exporter son roster, faire en sorte que tes contacts puissent savoir que tu as changé de jid, et que la migration soit automatique. Qu'ils aient une garantie que ce soit la même personne avant et après, de pouvoir exporter tout l'historique stocké coté serveur et le réimporter sur le nouveau compte.
Est-ce que c'est envisagé ? Qu'est-ce qu'il existe actuellement ?
[^] # Re: Migration de compte
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Et la possibilité d'avoir plusieurs jids pour un seul compte.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Migration de compte
Posté par Anonyme . Évalué à 2. Dernière modification le 05 juillet 2015 à 23:16.
un seul mot: gateways
plusieurs mots: configure une gateway xmpp sur ton serveur (xmpp via xmpp) et ajoutes-y autant de jids que tu le souhaites
[^] # Re: Migration de compte
Posté par Goffi (site web personnel, Mastodon) . Évalué à 2.
plusieurs jids pour une personne tu veux dire ? Si c'est ça, effectivement tu peux utiliser des passerelles XMPP <-> XMPP pour regrouper les comptes, ou alors utiliser un client multi-comptes comme gajim, psi ou SàT (j'ai un compte jabber.fr et libervia.org par exemple).
[^] # Re: Migration de compte
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
désolé pour la réponse tardive, étant aux RMLL, je me connecte peu.
la XEP-0015 a été rejetée, je suppose pour des raisons de sécurité (il faudrait chercher les discussions de l'époque sur les archives pour être sûr). Tu ne peux pas changer de serveur automatiquement, cela pose des problèmes d'une part pour valider ton identité (comment s'assurer que c'est bien la même personne qui a fait le transfert ? Bon il y a probablement des solutions comme avoir un accès à l'ancien et au nouveau compte, ou une identification GPG, mais il y a le risque qu'une clef a été compromise par exemple, il faudrait y réfléchir sérieusement pour voir les problèmes), et d'autre part un réabonnement automatique n'est pas forcément une bonne chose (je n'aimerais pas qu'un contact sur jabber.fr déménage et que je me retrouve à écrire sur facebook.com sans m'en rende compte).
Il y a plusieurs XEPs utilisables: si tu as la main sur le serveur (encore une fois: autohébergez vous ou approchez vous d'une association locale !), tu as un format standardisé pour transférer les comptes (XEP-0227), et pour échanger des éléments sur roster, tu as la XEP-0114. Sans passer par les XEPs, un clients peut proposer de faire un réabonnement massif de tous tes contacts (c'est une chose qu'on va probablement proposer tôt ou tard avec SàT).
Là tout de suite je ne vois pas d'autre solution, peut-être qu'il y en aura un jour, mais comme on ne change pas de serveurs tous les 4 matins, ça ne me semble pas une priorité. Il serait intéressant de pouvoir au moins transférer l'historique (pour l'historique côté serveur, dans le XEP-0313, l'upload d'archive n'a volontairement pas été implémenté, pour éviter de trop compliquer la XEP), et indiquer qu'une adresse n'est plus valide (le plus simple étant probablement d'envoyer un message automatique pour dire qu'on a changé d'adresse, et pas besoin de XEP pour ça).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.