-->[]

Il y a quelques semaines, Colin Didier, alias errtu, a annoncé qu'il s'était mis à plancher sur un plugin irssi pour Jabber, nommé irssi-xmpp. Comme je l'ai déjà mentionné il y a quelques mois, il existe aussi irssi-jabber qui fait la même chose, mais le développeur est content avec l'état actuel du plugin et n'est pas spécialement motivé pour avancer le développement, alors errtu a décidé de repartir à zéro.

Pour les gens qui connaissent pas irssi, c'est un programme de "tchat" en ligne de commande qui utilise de base le protocole IRC, mais qui peut utiliser d'autres protocoles par le biais d'extensions ou plugins.

Pour les gens qui connaissent pas Jabber, c'est un protocole de messagerie décentralisé, un peu comme les mails: depuis une adresse toto@hebergeur-truc.com on peut discuter avec tata@herbergeur-machin.net, donc personne ne peut avoir le monopole du réseau, et il ne peut pas y avoir de "panne générale". En ce qui concerne l'apparence du bouzin, il y a plusieurs logiciels Jabber, mais dans le cas le plus fréquent ça ressemble grosso-modo à ICQ, MSN Messenger, Yahoo Messenger et consorts: une liste d'ami·e·s, on voit s'illes sont là ou pas, et on peut chatter avec elleux, à deux ou en groupe.

Le problème avec Jabber c'est qu'il n'y avait pas de bon client en mode texte. Bon, et le problème avec irssi (qui est en mode texte, donc) c'est qu'il ne faisait pas de Jabber. Grâce à l'effort amorcé par errtu, paf, c'est bon. Du coup, je me suis dit que c'était la bonne occasion pour en faire un paquet Debian: ça fait longtemps que je voulais apprendre à faire ça, et par ailleurs ça permet de donner davantage de visibilité à irssi-xmpp. J'en ai donc fait un, avec l'aide de Lunar et de la documentation de Debian. Au début je l'ai mis sur un dépôt personnel, puis Lunar m'a proposé de l'envoyer dans l'archive Debian officielle, ce qui m'a permis de me familiariser avec le processus :

• Signaler un ITP (Intent To Package), c'est-à-dire prévenir que je comptais faire un paquet nommé irssi-plugin-xmpp (pour coller à la convention de nommage Debian).
• Premier moment d'émotion: dernières relectures et envoi (upload) du paquet source et du paquet compilé par la personne qui effectue l'envoi (Lunar, dans mon cas, donc compilé pour amd64, qui est l'architecture de sa machine) sur les serveurs Debian. Les paquets envoyés arrivent dans la NEW queue (file d'attente des nouveaux paquets). Ils doivent être validés par les responsables FTP, ce qui constitue un premier niveau de vérifications (compatibilité de la licence avec les critères de liberté de Debian, etc.). Le paquet est resté 6 jours dans la file, ben je peux vous dire que c'est long :)
• Deuxième moment d'émotion: le paquet a enfin été accepté hier. La suite est donc :
  • L'ITP a été automatiquement fermé.
  • Le paquet source et le paquet compilé pour amd64 se sont retrouvés publiquement accessibles dans la file d'entrée des paquets.
  • Des programmes automatiques de compilation (build daemons) se sont mis à construire le paquet pour les architectures manquantes: i386, mips, sparc, powerpc, etc..
• Quelques heures après, le paquet source et les paquets compilés pour chaque architecture ont été rendus disponibles sur le FTP principal de Debian pour la distribution "unstable", puis synchronisés sur les différents miroirs à travers le monde.

Le résultat concret, c'est qu'une personne utilisant Debian unstable peut maintenant installer le paquet irssi-plugin-xmpp via sa méthode d'installation préférée (apt-get, aptitude, synaptic, etc.).

Mon premier paquet Debian... c'est peut-être bête mais ça fait plaisir. Bon par contre c'est que le début, maintenant faut le maintenir, c'est-à-dire suivre les nouvelles versions et les packager aussi, tenir compte des signalements de bugs, etc.. Quant à irssi-xmpp, l'existence d'un paquet permettra à un peu plus de gens de l'utiliser facilement, et j'espère que ça permettra au programme de s'améliorer encore grâce aux suggestions, signalements de bugs, bouts de code, etc..

Vous saviez, vous (oui, vous), que Jabber gère les messages "normaux" ? Mais oui, non, pas le tchat à la MSN et ICQ, mais les trucs avec un sujet et tout. Oui, voilà, comme les mails. Ah vous saviez pas ? Pas d'inquiétude, c'est normal, c'est parce que la plupart des clients Jabber le gèrent pas vraiment super bien. La plupart sont, grosso-modo, des clones d'ICQ, qui considèrent les messages normaux comme un mal nécessaire, sans chercher beaucoup plus loin. Oui, comme les messages de type headline, exactement. En même temps, faut avouer, on ne leur jette pas la pierre, Pierre. C'est des clients chat, c'est pas vraiment leur boulot. Oui d'accord, mais alors on fait comment ? C'est le boulot de qui ?

Je dirais... celui des logiciels comme Thunderbird. Bah oui, ce dernier gère déjà très bien les news, ce qui est logique vu que c'est un peu la même structure que les mails, bien que ce soit un protocole distinct. Alors du coup, ça paraîtrait logique d'avoir une jolie gestion des messages normaux Jabber. Pis avec un minimum d'imagination, du coup, ça permettrait une jolie intégration, un peu comme ce qui est fait dans l'interface de GMail. En vrac:

• si on y est autorisé bien sûr, connaître l'état de présence de l'expéditeur d'un mail (le JID peut être indiqué via le header SMTP Jabber-ID) ;
• enclencher une discussion "chat" suite à un mail ;
• répondre via un message Jabber normal à un mail, ou réciproquement ;
• voir la "carte de visite" de l'expéditeur d'un mail ;
• on peut même imaginer faire une intégration tripartite avec les news, vu que l'intégration mail/news est déjà là.

Du coup, j'ai commencé à en parler par là...

Ce soir je faisais une petite recherche pour voir si des gens avaient déjà parlé de faire un plugin irssi pour Telepathy. Ben oui, ça serait malin... On pourrait même carrément modifier irssi pour qu'il implémente Telepathy en natif : vu que Telepathy gère potentiellement tous les protocoles de façon modulaire via l'utilisation de Connection Managers, y'aurait même plus besoin de certains plugins (plugin ICQ, plugin Jabber, plugin SILC, ...).

Sauf qu'en fait j'ai pas eu le temps de chercher bien longtemps, parce que je suis tombé sur un truc qui m'a fait dresser l'oreille: Icecap, qui est censé être un protocole de messagerie instantanée. Tiens, connaissais pas, marrant. C'est pas pour dire que je suis assez renseigné sur ce qui touche à ce domaine, mais quand même, si un peu. En fait il s'avère que c'est ce qui s'appelait jusqu'à il y a pas si longtemps irssi2. Ah bah ok, en fait je connaissais du coup (haha), c'est un "repensage" de irssi et IRC par Timo Sirainen, l'auteur d'irssi et du serveur de mail Dovecot. Les pages du wiki sont assez intéressantes, même si les notions de protocole et logiciel sont parfois utilisées et différenciées de manière bizarre.

Par la suite, de Icecap en PSYC, je suis tombé sur une "analyse" un tout petit peu acide de Jabber par une personne nommée lynX. Et là, faut bien le dire, Jabber (et, entre les lignes, d'autres gens autour) en prend vraiment, mais alors, plein la gueule. Pis faut bien avouer... tout n'est pas faux, bien que lynX ait visiblement l'habitude de faire dans le sensationnalisme et les paroles mal ou pas pesées, à tel point qu'il y a un disclaimer sur sa page utilisateur. Boah, allez, c'est bien les coups de fouet, pis ça fait circuler le sang :)

Bon, depuis quelques jours ou semaines (ou quelque chose comme ça), j'ai une espèce d'idée de projet un peu bizarre. En même temps, j'ai souvent des idées de projets un peu bizarres, je crois, que je mets pas toujours en pratique, enfin parfois si mais pas toujours. Alors du coup je me dis que j'aurais qu'à l'écrire ici, comme ça si jamais ça tombe dans un trou de mon cerveau et que je le fais pas, au moins ça fait une trace.

L'idée c'est qu'il y a peu de clients MUC corrects, genre aussi aboutis que les clients IRC, par exemple. Pis aussi, les gens ils ont l'habitude de leur client IRC, par exemple irssi, mIRC, etc.. Du coup, je me dis que ça serait marrant d'avoir un serveur IRC qui se baserait en arrière-plan sur un serveur MUC. Une autre manière de le dire c'est que ce serait un client MUC contrôlable via le protocole IRC. Par exemple tu te connectes au serveur IRC en question, tu fais un /list, et pouf tu as la liste des chans du serveur MUC. L'instant d'après, tu rentres sur un des chans du serveur IRC, et paf, en vrai tu es sur un salon MUC. Comme tout client Jabber qui se respecte, le serveur IRC utiliserait son propre JID, et se connecterait au réseau Jabber avec une ressource distincte pour chaque client IRC.

Voilà en gros l'idée, donc au final c'est un peu le symétrique de la passerelle IRC telle que celle présente dans ejabberd.

Après ça pose quelques problèmes "conceptuels", du coup faut que je réfléchisse encore. Par exemple, sur IRC, la notion de nick est générale sur tout le serveur, alors que sur Jabber on peut prendre un nick différent pour chaque chan. C'est un problème un peu chiant, hein, faut bien l'avouer. Une solution de contournement serait de présenter, comme nick IRC, non pas le nick sur le MUC (après tout, c'est un parallèle possible, mais ce n'est pas le seul), mais le JID complet, genre nomdusalon@serveur/nick, ou encore le JID réel de la personne si le MUC l'expose. Du coup ça permettrait de "désambigüiser" le nick, mais par contre c'est moins joli, et le problème aussi c'est que les RFC relatives à IRC n'autorisent pas le @ et le / dans les nicks. Après, c'est pas comme si le respect des RFC était l'aspect le plus marquant du monde IRC, donc faut voir si l'impact réel serait si problématique. Une autre idée serait tout bêtement de n'autoriser qu'un seul chan par connexion, mais par contre d'autoriser plein de connexions pour chaque client, pour se faire pardonner. Ça résoudrait en partie le problème, vu que le nick serait bien sûr différent pour chaque connexion. Par contre ça empêcherait de choisir le même nick pour plusieurs chans, donc au final c'est le problème contraire, du coup c'est pas super malin mon garçon, mais merci d'avoir essayé.

Enfin voilà, y'a évidemment d'autres problèmes, telle que les caractères autorisés ici et là, à commencer par les nicks IRC qui sont trouze-mille fois plus restrictifs que sur Jabber (toi aussi tu aimes ton espace dans ton nick IRC). Après, y'a moyen de faire un mapping entre le nick Jabber et un pseudo-nick IRC forgé en remplaçant les espaces par des underscores, les lettres accentuées sans l'accent, etc. (en gérant bien sûr l'unicité, quitte à rajouter un underscore à la fin si le nick est déjà pris), et de présenter aux gens côté IRC juste le pseudo-nick (idem pour les noms de chans zarb), m'enfin c'est moins drôle, quoi. Les problèmes de charset seraient aussi pas très marrants à gérer, vu que le protocole IRC ne spécifie juste pas de charset (la RFC dit, presque texto, "y'a pas de charset ici, on envoie 8 bits et ça fait 1 octet, faites pas chier avec vos conneries, déjà c'est compatible avec vos terminaux ASCII alors vous plaignez pas.").

Pour le langage, en python ça peut être pas mal, et en plus il existe un mini serveur IRC nommé miniircd, donc ça fait déjà une super bonne base pour démarrer.

Bref au final ça peut être un projet rigolo, avec des fonctionnalités bien sûr limitées en tant que serveur IRC, et clairement aussi en tant que client MUC (mais bon ça c'est normal, si on choisit d'utiliser un client IRC on s'attend pas à avoir toutes les power-features des MUC Jabber), m'enfin ça permettrait déjà de dire « hé, toi, viens sur mon chan #truc, il est sur le serveur IRC "blablabla"», et paf la personne vient et capte même pas que c'est du Jabber, haha, ouah l'autre, trop bête, mouarf, lol. Ahem. Bref. Ça a l'air bien, nan ?

Je réfléchis depuis quelques mois sur un projet nommé DIAS, dont l'objectif est de fournir un mécanisme d'authentification sur internet un tant soit peu global, tout en restant complètement décentralisé et indépendant.

La constatation initiale est que, sur internet, la gestion des comptes utilisateurs est gérée de façon assez "préhistorique". Le meilleur exemple, ce sont les sites web, et plus particulièrement les forums: la plupart du temps, lorsque l'on veut poster un message sur un forum, il faut se créer un compte utilisateur en remplissant un formulaire à rallonge avec toujours les mêmes infos: nom, prénom, adresse mail, blablabla, et surtout à la fin, pouf, création d'un nouveau compte utilisateur, et hop un mot de passe associé. Bien sûr, on choisit généralement toujours le même nom d'utilisateur (et très souvent le même mot de passe), mais c'est pas grave, il faut recommencer à chaque fois. Je parle des forums parce que c'est le plus fréquent, mais c'est valable pour d'autres formes de sites web, et même pour d'autres formes de communication par internet (IMAP, news, ssh, etc.).

Au final :

• C'est chiant pour l'utilisateurice, qui doit s'inscrire ou se faire inscrire partout, se souvenir de là où ille est inscrit·e, là où ille ne l'est pas, mémoriser l'identifiant, le mot de passe, etc.. D'accord, dans le cas des sites web, les navigateurs modernes offrent une manière de mémoriser ces informations, mais ce n'est qu'une manière de contourner le problème initial.
• C'est chiant pour les "serveurs" (site web, etc.), qui doivent à chaque fois réinventer un moyen de stocker les comptes utilisateurs, offrir un mécanisme de création de compte, confirmation, procédure en cas d'oubli du mot de passe, sans parler de la gestion des comptes abandonnés...
• À l'échelle d'internet, c'est complètement crétin. On a beau avoir beaucoup avancé sur des tas de choses, personne ne semble se soucier de ce point, bien qu'il concerne directement la "vie quotidienne" des gens. Ça en est devenu ridicule.

Il y a déjà eu des initiatives pour prendre en main ce problème, l'une des plus connues étant "Microsoft Passport". Je ne connais pas les détails, mais pour ce que j'en ai compris, les gens ont un identifiant "passport" unique qu'ils peuvent donner sur les sites qui participent à l'initiative. Cet identifiant et le mot de passe associé sont stockés de manière centrale chez Microsoft, à qui les sites utilisant se système vont donc déléguer l'authentification. Ce système, bien que semblant résoudre le problème, pose bien sûr un gros problème d'indépendance, de sécurité, et de pérennité: qu'est-ce qui se passe si du jour au lendemain Microsoft rend ce service indisponible, payant, si la base de données est piratée ? Je passe sur la possibilité de faire par exemple des statistiques de qui va sur tel site, combien de fois par semaine, et les possibilités d'abus que ça ouvre (revente de l'information à des tiers par exemple). Je parle ici de Microsoft Passport à titre d'exemple, mais bien sûr le problème est le même pour tout système similaire présupposant un "fournisseur d'identité" central. À ma connaissance, aucun de ces systèmes n'a vraiment accroché, et on comprend pourquoi.

Bon, donc OK, on tient le problème, mais cette approche-là est mauvaise. Du coup, j'ai essayé de réfléchir à un système qui offrirait le même type d'avantage, c'est-à-dire la possibilité in fine d'apparaître sous un identifiant unique, mais qui ne poserait pas le problème de la centralisation en termes de qui maîtrise cette information. Et bien sûr, ça fait penser à quoi, forcément ? Ben oui, les adresses Jabber (JID): tout comme les adresses mail, un JID est formé d'un identifiant et d'un nom de serveur, séparés par un "@". Ce schéma permet d'avoir des adresses globalement uniques, tout en permettant que le stockage des adresses soit complètement décentralisé: chaque serveur Jabber est responsable de son ensemble d'adresses.

Reste le problème crucial: au moment de s'authentifier sur un site web (je dis site web tout le temps, mais c'est pas forcément que ça, hein), il faut donc prouver que l'on possède le JID truc@serveur.com. Facile, me direz-vous, suffit de donner le mot de passe. Ah ben oui mais non. Hors de question de filer son mot de passe Jabber à tout site qui le demande, bonjour la confidentialité. Paf, l'éternel problème: prouver que l'on possède une information, sans pour autant la donner explicitement.

Une solution, un peu chiante, mais qui marche, est de passer par un système intermédiaire de tickets: je fais une demande de ticket à un "fournisseur de tickets" (on n'aurait qu'à l'appeler "agent", c'est plus court), en lequel le site web a confiance, et ceci je le fais via Jabber, par mon adresse truc@serveur.com. En échange, l'agent me répond par un numéro de ticket unique, que je n'ai qu'à montrer fièrement au site web, comme une sorte de "certificat" qui prouve que truc@serveur.com c'est moi. Et pouf c'est tout.

En vrai c'est pas tout, mais c'est déjà un peu long, alors du coup tout est expliqué en détail sur le site de DIAS (c'est en anglais).

Après quelques mois où j'ai été assez "occupé" (haha), cette semaine j'ai eu un peu plus de temps, alors je me suis enfin décidé à parler de ce projet sur la mailing-list jdev. Le truc rigolo est que quelqu'un (Richard Dobson) a fait quelque chose de presque exactement équivalent. C'est moins détaillé, mais ça a le mérite d'être déjà écrit sous forme de XEP. Du coup, on va probablement bosser ensemble pour enrichir cette XEP avec certaines idées présentes dans DIAS.

Il existe aussi un autre système très intéressant, nommé OpenID, qui tente également de résoudre le même problème, et qui l'aborde sous un angle différent. Je n'ai toujours pas bien compris comment ça marche (mais je me soigne), ni tous les points forts/faibles, donc pas de comparatif ici.

Dans les idées que les autres gens ont eues, il y en a une qui s'appelle "Verifying HTTP requests via XMPP" (vérification de requêtes HTTP via XMPP), et son petit nom c'est XEP-0070. Contrairement à DIAS, qui fait une vérification a priori de l'identité, ce système fait une confirmation, c'est-à-dire une vérification a posteriori. Dans l'état actuel des choses il est fortement corrélé à HTTP, mais l'idée a été émise (et aimée) de changer ça.

Enfin voilà, à suivre donc. Je crois que j'ai bien envie de bosser avec Richard Robson sur l'amélioration de la XEP-0101 (Jabber tickets), et en parallèle de mieux comprendre OpenID.

Bon, c'est cool: Christian Häggström a fini de mettre en place un Trac^[1] pour son projet très prometteur (pas seulement prometteur, il marche déjà très bien): irssi-jabber, un plugin permettant à Irssi de communiquer via le protocole XMPP. Ce projet existe déjà depuis quelque temps, mais il était très peu accessible: difficile d'accéder au CVS, page du projet très pauvre, bref pas de moyen simple de suivi ou d'interaction avec le projet, donc peu de motivation pour l'auteur de l'enrichir plus que pour son besoin personnel.

Personnellement je crois énormément en ce projet. À mon sens, Irssi est un excellent logiciel, qui a atteint un certain niveau de maturité, et qui dispose d'une infrastructure de messagerie très bien faite. Par ailleurs, il est pourvu de systèmes de thèmes, de configuration, de plugins, etc. assez puissants. Enfin, il est déjà pensé de façon suffisamment modulaire pour pouvoir gérer d'autres protocoles que IRC (d'ailleurs il existe déjà un plugin pour ICQ).

Le paysage softwarifique de Jabber manque, il faut bien le dire, d'un bon client texte; irssi-jabber devrait combler ce manque, et Trac va pouvoir lui donner le petit coup de pouce qui va bien.

Re.

C'était juste pour dire que bitlbee c'est super vraiment méga pratique kikoulaule. Voilà donc ça c'est dit.

Maintenant, soyons plus clairs. Bitlbee c'est vraiment mal foutu, surtout en ce qui concerne la partie Jabber. Mais genre vraiment. Il fait pas le quart de ce que fait le moindre petit client de PDA: niveau messagerie c'est tout juste utilisable pour taper un message et lire les messages des gens. Ensuite dès qu'on veut manipuler sa liste de contacts c'est déjà un peu plus tendu (hey c'est quoi cette commande "rename", je leur avais mis des noms moi aux gens, arrête d'utiliser la partie gauche du JID...). La gestion de la présence/absence est buggée jusqu'à la moëlle. Il ignore royalement les messages "normaux" (c'est-à-dire pas chat). Quant aux fonctionnalités plus avancées de Jabber qui seraient transposable sur IRC, c'est même pas la peine d'y penser.

J'entends « mais prends tes mains et code au lieu de critiquer ». Sisi, toi là-bas. En fait, même les développeurs de bitlbee disent que la couche Jabber est dégueulâsse, et qu'ils ne comprennent plus rien au code existant. D'ailleurs ils parlent de réécrire entièrement la couche Jabber. Juste, plus tard. Genre après la sortie de la 1.0 (sic).

Donc bref, en attendant c'est bien pratique, le serveur en soi est super stable, fonctionne très bien pour la partie IRC, gestion des commandes, etc., et c'est vraiment un chouette boulot qu'ils ont fait. (d'ailleurs la couche Jabber c'est pas leur faute c'est Gaim).

En vrai, ce qu'il faudrait c'est un truc pile pareil, mais qui gère pas trouze-mille protocoles de discussion comme le fait bitlbee. Du coup on pourrait vraiment avoir des choses bien au lieu du plus grand dénominateur commun (cette opinion qui n'engage que moi concerne tous les clients multiprotocoles).

Ou alors, ce qui serait bien ce serait un vrai client Jabber en mode texte, histoire de ne pas passer par ce hack (parce que bon il faut bien le dire, utiliser une passerelle IRC pour faire du Jabber, s'il y avait des vrais clients en mode texte, on s'en passerait bien...). Ou alors, profiter du fait que irssi sait gérer des plugins, et faire un plugin Jabber pour irssi. D'ailleurs Christian Häggström est en train de faire ça. Contrairement aux apparences le projet n'est pas mort, mais un peu de notoriété ne lui ferait pas de mal.

Du coup j'ai mis un serveur bitlbee sur ma machine (home.weeno.net). Ce n'est pas un serveur public: je l'ai mis pour moi; vous pouvez l'utiliser mais ne venez pas vous plaindre si Noos (ou le modem à la con) coupe la connexion de manière aléatoire, notamment quand je partage mes films de vacances avec mldonkey. Ceci dit ça reste entièrement utilisable et je vous enjoins à tester.

Les esprits attentifs auront décelé une pointe de négativité dans le ton de ma voix. Le problème est actuellement connu de nos services, il sera réglé dans les plus brefs délais.

J'ai enfin fait quelque chose que je voulais faire depuis quelque temps: uniformiser mon adresse mail et adresse jabber. C'est maintenant fait, les deux adresses sont désormais en asocial.info (au lieu de davux@amessage.info pour jabber).

Cela a été possible grâce aux gentils gens de l'APINC (notamment Lucas), qui ont configuré le serveur jabber im.apinc.org pour qu'il puisse également répondre sous le nom "asocial.info", gérer les utilisateurs de ce nom, etc.

Côté DNS, pour que les autres clients et serveurs jabber puissent savoir que le serveur jabber "asocial.info" est en fait "im.apinc.org", il a fallu ajouter les lignes suivantes dans la configuration de la zone "asocial.info" de Bind sur le poivron (qui est le serveur DNS primaire du domaine):

_xmpp-server._tcp 86400 IN SRV 5 0 5269 im.apinc.org.
_xmpp-client._tcp 86400 IN SRV 5 0 5223 im.apinc.org.
_jabber._tcp      86400 IN SRV 5 0 5269 im.apinc.org.

Ceci permet aux clients et serveurs jabber d'effectuer une résolution DNS de type "SRV" pour connaître l'adresse IP du serveur. Si ces lignes étaient absentes, ils se rabattraient sur une résolution "classique" de type A, ce qui échouerait puisque celle-ci renvoie actuellement l'adresse IP du poivron.

Ensuite, le problème est que, justement, dans les faits, seuls les serveurs Jabber effectuent actuellement une requête SRV ; la plupart des clients se contentent encore d'effectuer une résolution de type A, ce qui est contraire à la RFC 3920 qui définit le coeur du protocole XMPP. Pour contourner ce problème, j'ai dû explicitement indiquer à mon client jabber (Psi) le serveur "im.apinc.org" pour ce compte. Actuellement, à ma connaissance, seul exodus effectue les résolutions DNS correctement.

Encore un grand merci à l'APINC, donc, pour fournir ce service. Il est possible de s'enregistrer sur le serveur asocial.info pour les personnes qui le souhaitent, ou d'utiliser un des autres serveurs de la liste.

Le Jabber Journal #20 est plein de bonnes nouvelles. Pour une fois, Peter Saint-André a fait un petit effort et a laissé seulement 3 semaines entre ce journal et le précédent ;)

Le site amessage.info permet maintenant d'envoyer des SMS via Jabber, et ce n'est pas réservé aux utilisateurs de amessage, n'importe quel compte Jabber fait l'affaire. Pour commencer, 50 SMS gratuitement quand on s'inscrit. Le service est encore en phase de test.
J'ai testé, ça marche. Par contre faut pas oublier de signer, car le numéro expéditeur du SMS est un +49xxxx...

Allez, je me re-tais.

Vous connaissez Jabber ? C'est un protocole de communication sous forme de channels ou de messages privés, un peu comme IRC.

Et franchement, Jabber ça poutre. Explications.
- C'est sécurisé au niveau de la connexion au serveur: on peut faire passer ça sur du SSL,
- C'est sécurisé au niveau de l'authentification: on peut choisir de s'authentifier en envoyant le mot de passe sous forme de digest,
- C'est sécurisé au niveau "end-to-end": il est possible d'utiliser le mécanisme de clés asymétriques de GPG et PGP. Impeccable.
- C'est basé sur XML: c'est tout propre !
- C'est libre. En l'occurence, ça permet entre autres que le fait que ça soit sécurisé ait un intérêt (ben oui, c'est quand même bien d'être sûr de ce qui se passe...). Et bien d'autres garanties de qualité, à mon sens.
- Il n'y a pas un seul serveur Jabber: n'importe qui peut faire tourner son propre serveur Jabber, public ou privé, ce dernier cas pouvant être une bonne solution de communication au sein d'une entreprise par exemple. Et c'est vachement simple à administrer.
- Un serveur Jabber peut fournir tout plein de services annexes, notamment un annuaire des utilisateurs, auquel l'inscription est bien entendu facultative.
- Un utilisateur peut être connecté avec plusieurs clients, ou "ressources", simultanément, et choisir de recevoir ses messages sur l'une ou l'autre (maison, bureau, ordinateur portable...). Les gens peuvent bypasser ça en demandant que les messages arrivent sur telle ressource précise.
- Il est possible d'utiliser le protocole Jabber avec les protocoles existants tels que ICQ, AIM, Yahoo Messenger, pour ne pas laisser tomber ses amis.

Il doit sûrement y avoir d'autres choses.

Au niveau des clients, Psi est vraiment bien foutu, mais Gaim, Miranda, centericq, Trillian le gèrent aussi.

Non, franchement, Jabber c'est du bonheur à tartiner.