Jabbim est un client Jabber tchèque assez prometteur, j’en avais déjà parlé l’an dernier sur le blog de JabberFR, et en un an le petit client a fait du chemin, il a subit une réécriture presque complète, et en fait est encore mieux qu’avant (il aurait été plus mauvais j’en aurais pas parlé).

Les principales fonctionnalités

Derrière ses alures classiques, ce client cache un potentiel assez important. Non seulement il gère toutes les fonctionnalités de bases qu’on se doit d’attendre d’un client Jabber actuellement, à savoir pouvoir parler, rejoindre des salons de discussions et envoyer des fichiers, il supporte les commandes ad-hoc (qui permettent d’intéragir facilement avec des bots, comme par exemple presence.jabberfr.org, il gère PEP (l’humeur, la musique et l’activité), ainsi que la fonctionnalité que j’attends depuis longtemps dans les clients Jabber, les plugins.

Ces plugins peuvent permettre un peu tout et n’importe quoi. Pour l’instant les plugins fournis permettent déjà des trucs pas mal, comme par exemple EasyShare qui permet de partager des fichiers avec d’autres personnes, les personnes pouvant initier le transfert de fichiers quand il le souhaite.

Ces plugins permettent aussi une intégration avec certains services du serveur Jabber de Jabbim comme par exemple JDisk qui est un disque dur par Jabber (on peut stocker des fichiers avec), et JGames un service de jeux. Je n’ai pas testé ces deux intégrations, ça ne semblait pas marcher au moment où j’ai testé.

Une autre fonctionnalité assez rare sur les clients Jabber actuels est la possibilité d’utiliser des thèmes, aussi bien pour les fenêtre de chat, que pour la liste de contact ou que le reste de l’interface. Personnellement je n’aime pas trop ça, je préfère un client intégré à l’OS, mais je sais que plein de gens aiment les clients avec des jolies couleurs qui font tâches sur l’écran.

Les avantages

Le client a vraiment de nombreuses fonctionnalités, l’interface semble assez bien pensée et arrive assez bien à permettre une utilisation même pour les utilisateurs de base tout en donnant accès aux fonctionnalité avancés.

Les inconvénients

Le client est encore jeune, et quelques bugs sont visible, mais le client reste quand même tout à fait utilisable pour n’importe qui. Comme il est issue d’une communauté tchèque, le changelog est en tchèque ainsi que le site des développeurs, ce qui rebute un peu pour contribuer, bien que les développeurs soient ouverts et parlent anglais. J’aime pas trop l’interface de la liste de contact, pas assez sobre à mon gout, mais je suis sur que ça plaira à pas mal de monde, et les thèmes permettent éventuellement de changer ça.

Les screenshots

Évidemment je ne peux pas passer à coté des screenshots pour ce clients, donc en voici une petite liste.

Aspect technique

Techniquement ce client est fait en python, utilise Qt4 pour l’interface grâce au binding PyQt4, et le framework twisted pour la partie Jabber. Il est diffusé sous la licence GPLv2.

Conclusion

Je pense que ce client est vraiment prometteur, et qu’il pourrait bien attirer pas mal de monde, grâce à son ergonomie et à son nombre de fonctionnalité qui risque d’augmenter rapidement si le nombre d’utilisateurs augmente grâce aux plugins.

Je regrette juste que leur serveur utilise LIghttpd et pas Apache qui est quand même bien et qui en plus est sponsorisé par les gentils gens de Microsoft.

Je me dois de répondre au troll billet de xbright sur openid qui démontre soit son ignorance d’openid, soit un plaisir à démolir une superbe initiative. Ce billet s’adresse directement à xbright et aurait plus sa place dans ses commentaires, mais j’aime pas écrire des trop gros commentaires.

Reprenons ses arguments dans l’ordre :

D’après plusieurs billets (comme celui ci), la page d’OpenID affichait avant ce texte :

What about trust?
This is not a trust system. Trust requires identity first.

What about spam?
Again, this is not a trust system.

Ce n’était peut-être pas très malin de mettre ça sur le site d’openID, mais ce qui est dit est vrai. OpenID n’est pas un captcha anti-spam ou un système de confiance à la GPG, OpenID est juste fait pour associer une URL avec identité sur internet. Ca ne permet pas de savoir que derrière cette identité ce trouve M. Machin, et ça ne permet pas non plus d’avoir confiance en lui.

D’ailleurs, ce billet explique bien en quoi OpenID est très vulnérable au phishing et donc au spam :[...]

C’est effectivement un des problèmes d’OpenID, mais ce problème se retrouve sur tous les méthodes d’authentification, d’accord tu vas me dire que sur un site c’est moins grave vu que ça ne donne accès que à ce site. Ok pour un utilisateur avancé (et encore), mais l’utilisateur lambda va utiliser le même login mot de passe partout, et pire encore en général son mot de passe est aussi celui de son compte email. Et lorsqu’on récupère un accès au compte email principal d’une personne on peut en général se connecter à tes les sites qu’il utilise (sauf certains cas spéciaux comme les sites des banques), bref on peut comparer le vol d’email au vol d’OpenID.

Il suffirait de vous piquer vos identifiants OpenID pour aller se connecter à votre place partout où vous allez sur Internet !

Il suffit de vous piquer vos identifiants mails pour aller se connecter à votre place partout où vous allez sur Internet !

À quoi ça sert ? Ne pas avoir à s’identifier sur chaque site, en proposant une seule identification pour tous les sites. Sauf que cet argument, en 2008, il n’est pas très séduisant : tous les bons navigateurs se rappellent de nos identifiants (pseudonyme / mot de passe) et les bons sites écrivent un cookie afin qu’on puisse être identifié dès la connexion.

Tu te connectes toujours depuis chez toi ? Moi non. Tu te connectes toujours avec le même navigateur ? Moi non (certains sites peuvent ne plus bien marcher avec ton navigateur par défaut par exemple). Les cookies durent à vie ? Non. Les URLs de login des sites que tu consultes ne changent jamais ? Parce que si ça change en général le fabuleux principe des mot de passe sauvegardé dans le navigateur ne marche plus.

Et pour combattre tout ça, on nous propose des solutions vraiment très drôles. Ça va du captcha image (« Go fuck yourself with your accessibility and other shits like that », comme disait l’autre) à la question personnalisée du genre « Quel âge à votre grand-mère ? ». C’est vraiment super. Et puis, on trouve des rustines assez drôles à lire, de l’image personnelle à SSL (pourquoi ne pas y avoir pensé plus tôt ? ah oui, ce n’était pas un système de confiance, à la base !).

Le captcha a l’avantage de n’être fait qu’une seule fois par adresse openid, donc pas besoin de le refaire sur chaque site. Alors oui le captcha c’est de la merde, mais vaut quand même mieux le faire qu’une fois que sur tous les sites qui le demandent.

Pour les problèmes de phishing c’est comme pour des sites normaux, oui ce n’est pas parfait, non on a pas encore trouvé mieux de manière simple. Et je ne vois pas pourquoi le SSL doit être considéré comme une rustine. OpenID se veut flexible, l’authentification via un certificat SSL est une méthode, qui est une des plus sécure. Mais comme le commun des mortels peut avoir du mal avec ça, c’est pas ce qui est proposé par la plupart des provider openID, mais au moins ceux qui veulent peuvent l’utiliser. Alors que sur certains sites on a juste du SSL avec un certificat auto-signé (autant dire inutile) pour protéger son mot de passe. Et au passage le coup de l’image perso est faite par plein de site, genre Yahoo!.

Toujours sur ce même blog, voici une description des étapes à suivre si je veux ajouter un commentaire à un blog en étant identifié (parce que c’est vrai que c’est chiant pour le développeur du logiciel de blog d’écrire un cookie où y mettre les infos à sauvegarder dans ce formulaire) : [...]

Ton argumentaire ici ne tiens pas du tout la route, en fait tu fais presque l’apologie d’openID. Tu dis qu’avec openID c’est beaucoup plus compliqué pour poster sur un blog, alors que c’est le contraire. Il y’a beaucoup de blogs où l’on doit s’inscrire, donc sans openID les étapes sont :

1. Remplir un formulaire qui demande l’email, l’identifiant et un mot passe
2. Aller checker ses mails pour cliquer sur le lien de vérification de l’email
3. Retourner sur le blog
4. S’authentifier
5. Et finalement écrire son message

Après pour ce blog ça sera beaucoup plus simple. Pour openID on s’authentifie une fois et ensuite pour tous les blogs qui supportent openid :

1. Entrer son URL openID
2. Dire j’accepte de donner les infos pour ce blog
3. Et écrire son message

C’est en fait beaucoup plus simple, et la seule information qu’il faut écrire c’est son URL openid, pas besoin de taper n fois son email, son adresse jabber, son adresse web, …

En plus, comme vous allez utiliser OpenID pour vous connecter sur le plus de sites possible, le serveur pourra dresser un profil sympathique

Rien ne t’empèche d’utiliser une adresse OpenID du genre http://example.org/openid/domaine_du_site en remplaçant domaine_du_site par le nom de domaine du site sur lequel tu te connectes, ainsi pas de risque d’être tracé. Et puis bon actuellement on peut tracer de la même manière avec les adresses mails.

Et si tu parles du provider openid qui peut avoir des informations sur toi, oui c’est vrai, mais rien ne t’empèche soit de te créer ton propore fournisseur OpenID (c’est ça l’intérêt d’un truc décentralisé), soit utiliser un provider en qui tu peux avoir confiance, soit utiliser le provider de ton FAI si il existe, ton FAI dispose déjà de ces informations, donc ça ne va pas changer grand chose.

Et puis, qui est le couillon qui a eu l’idée d’utiliser une URL comme moyen d’identification ? C’est pas du tout fait pour ça. Comme le dit Wikipédia :

Les URL ont été inventées pour pouvoir indiquer avec une notation (d’où l’adjectif « uniforme ») aux navigateurs web comment accéder à toutes les ressources d’Internet.

Sur wikipedia anglais :

Uniform Resource Locator (URL) is a compact string of characters used to represent a resource available on the Internet.

Mon identité est une ressource disponible sur internet, donc je ne vois pas le problème. Et je ne vois pas du tout en quoi c’est couillon d’utiliser une URL pour openID, au contraire dès qu’on veut un truc décentralisé c’est ce qu’il y’a de plus logique à utiliser.

Certains disent qu’il en est de même pour l’identification sur certains sites via un identifiant Jabber et la XEP 70. Mais non. Avec cette méthode, je ne risque pas de phishing, il me suffit d’inscrire mon identifiant Jabber et quelques bêtises dans un autre champ pour vérifier que c’est bien moi, et mon client Jabber me demande si j’accepte.

Cool, tu viens de démontrer que OpenID n’est pas sensible au phishing, vu que de la même manière tu peux t’authentifier par OpenID en passant pas le XEP 70.

Certes, Jabber n’est pas fait pour à la base, mais XMPP est extensible, prévu pour être amélioré et pour gagner en fonctionnalités. Pas les URLs.

Les URL, comme XMPP, ont été prévu pour pouvoir servir partout. Arrête de FUDer.

Puisque en intégrant OpenID, je donne les clefs d’accès aux zones « restrictives » de mon site à tous ces serveurs inconnus, sur lesquels je n’ai aucun contrôle, vulnérables au phishing/spamming, tenus par des organisations parfois peu recommandables.

Dommage, tu fais déjà confiance à des serveurs qui ne t’appartiennent pas. Comme j’ai dit plus haut, en envoyant les mots de passe par mail, tu donnes autant de pouvoir a des serveurs tiers qu’avec OpenID, ça ne change rien sur ce point.

En fait tous les arguments que tu opposes à OpenID tu peux les opposer aussi aux mails, et au fait d’envoyer par mails les mots de passes des utilisateurs pour tous les sites où l’on peut s’inscrire. En fait le mail c’est un peu l’ancètre d’OpenID, avec moins de choix …

Maintenant que nous avons vu pourquoi ne pas pas adopter OpenID, voyons réellement pourquoi adopter OpenID :

• Création de comptes beaucoup plus facile sur les sites supportant OpenID, il suffit de rentrer son URL OpenID et de valider les informations qu’on veut donner au site, et voila, le site va créer automatiquement un compte pour nous (et oui en général avec OpenID on a quand un compte sur le serveur et même la possibilité de se logguer avec login/mot de passe, on a la liberté de faire comme on veut).
• Pas besoin de faire confiance à tous les sites sur lesquels on va, juste besoin de faire confiance à un seul site. Et oui comme on met souvent le même mot de passe sur tous les sites, il suffit que un site dans lequel on a pas forcément confiance, ou où l’admin est pas très compétent pour que son mot de passe se fasse récupérer par des crackers.
• Pas besoin de se rappeler de tous ses mots de passe.
• On peut choisir la méthode d’authentification : par mot de passe, par Jabber, par certificat, … Bref on est plus flexible.
• etc.

Bien sur OpenID n’est pas parfait, bien sur y’a des risques de phishing, y’a des problèmes de confiance, etc. Mais on a pas mieux pour le moment, et même si toi xbright tu ne vois pas la nécessité de n’avoir qu’un seul mot de passe (parce qu’en fait le problème est là, tu n’en veux pas parce que tu ne vois pas l’intérêt), sache que certaines personnes voient cette nécessité, et donc même si toi tu ne l’utilises pas, le proposer sur tes sites serait une bonne chose.

Si jamais vous avez tué firefox depuis la console, il est important de pouvoir le relancer, cette piqûre de rappel va vous apprendre comment lancer firefox si vous l’avez tué.

Trois méthode s’offrent à vous : (attention, il ne faut pas taper le premier $, c’est le prompt du shell ! Par contre si y’en a d’autres dans la ligne faut les taper.)

La première méthode

$ firefox

La deuxième méthode

$ `which firefox`

La troisième méthode

$ $(locate firefox|grep bin|head -n1)

Oui je sais ce billet ne sert à rien, désolé, mais j’ai un quota à respecter si je veux devenir un bloggeur respecté.

PS: Si vous avez des meilleures méthodes encore je suis preneur.

Ça fait un petit moment qu’on parle de PEP et de Pubsub dans le monde de jabber, ça commence gentillement à arriver, c’est donc le moment de faire un petit point sur ce que sont ces deux technologies et ce qu’elles permettent de faire.

Pubsub : comme RSS, mais en différent

Le principe de Pubsub est extrèmement simple (comme beaucoup de technologies géniales), une personne (ou un logiciel d’ailleurs) peut s’inscrire pour recevoir les messages que poste un autre utilisateur, on a donc un utilisateur qui publie (publish) et un qui souscrit (subscribe) d’où le nom Pubsub (publish-subscribe). Ok ça n’a pas vraiment grand chose de révolutionnaire à première vue, ça ressemble grandement à ce que fait RSS.

En effet RSS et Pubsub sont assez proches mais se distinguent par une grosse différences. Pour RSS la personne qui a souscrit doit activement récupérer le fil RSS pour savoir si il y’a eu des nouveaux items, pour pubsub c’est le serveur pubsub qui va pousser les nouveautés vers les personnes qui ont souscrits. Ça a deux gros avantages : on n’utilise que la bande passante nécessaire (pas besoin de télécharger 50 fois le fil pour n’avoir qu’une fois des nouveautés) et en plus c’est instantanée, les notifications arrivent en temps réel chez les personnes qui ont souscrits.

Cependant tout n’est pas rose dans le monde de pubsub, le protocole est assez compliqué, en fait il est prévu pour plein de cas de figures particuliers, ce qui rend son implémentation à la fois dans les serveurs et dans les clients Jabber compliquée. Un autre de ses inconvénients c’est qu’il faut connaitre l’adresse des nœuds (c’est la terminologie pubsub pour les endroits où des items sont publiés) auxquels on veut souscrire. Pour simplifier tout ça PEP a été inventé.

PEP : Une utilisation concrète de la puissance de Pubsub

PEP signifie Personnal Eventing via Pubsub, ce n’est pas simple à traduire mais en gros ça veut dire publication d’évènements personnels par Pubsub. Ça ne nous avance pas beaucoup plus. En fait PEP est une version simplifiée de Pubsub qui permet de diffuser des informations personnels du genre la musique en cours d’écoute ou son humeur. Je vous vois déjà objecter qu’on dispose déjà du message d’état dans lequel on peut mettre ces informations. Certes on peut, mais ce n’est pas idéal parce que dans ce cas là on ne laisse pas le choix à ses correspondant de recevoir ou non ces informations.

Prenons un exemple simple, supposons que je sois connecté sur Jabber en passant par un téléphone portable, je paie en fonction du débit, je souhaite donc avoir le moins de débit possible, je ne souhaite donc pas recevoir toutes les 3 minutes un changement d’état de la part de mes correspondants pour voir la musique qu’ils écoutent (ce qui en plus ne m’intéresse pas particulièrement). Si mes correspondants mettent la musique en cours dans leur message d’état, et bien je n’ai aucun moyen de filtrer ça, alors que si ils font ça avec la bonne méthode (c’est à dire avec PEP), et bien mon client ne va pas dire que ces informations l’intéresse, et le serveur ne les lui enverra pas.

PEP et Pubsub, c’est quoi les différences ?

Cette partie est un peu plus technique et demande certaines connaissances du protocole XMPP, désolé pour ceux qui ne comprennent pas tout.

Mais revenons à nos moutons, j’ai dit que PEP était une version simplifiée de Pubsub, en fait c’est un sous ensemble des fonctionnalités de Pubsub permettant une utilisation plus facile. Comme je l’ai dit un des problèmes de pubsub est la difficulté de connaître les nœuds où souscrire, avec PEP c’est facile, chaque identifiant Jabber est un serveur PEP, par exemple omega@im.apinc.org est un serveur PEP sur lequel je peux poster, je suis d’ailleurs le seul qui puisse poster dessus. Sur ce serveur les nœuds PEP correspondent aux namespace XML des extensions qui utilisent PEP. Par exemple pour la musique le nœud à utiliser est http://jabber.org/protocol/tune.

Cela simplifie donc déjà grandement le travail du client qui va publier, vu qu’il sait déjà où publier. Pour le client qui veut souscrire au nœud c’est encore plus simple, il n’a quasiment rien à faire, il faut qu’il soit autorisé à voir la présence de l’autre personne, et il doit en plus mettre dans ses capacités (c’est la liste d’informations renvoyées par disco#info, associé à un hash de ces informations qui sera placé dans les paquets de présence) qu’il supporte par exemple pour la musique : http://jabber.org/protocol/tune+notify (il faut donc rajouter +notify au namespace du protocole), et voila c’est tout, il recevra ensuite les notifications PEP pour ce protocole.

Et concrètement ça donne quoi

Dans les clients supportant PEP il est possible de mettre son humeur, la musique qu’on écoute, etc. (ça dépend de ce que supporte le client). Et après vos contacts verrons quelques choses du genre :

En plus omnipresence supporte déjà quelques profiles de PEP, ça permet par exemple d’afficher son humeur sur son blog, comme je l’ai fait dans ma boîte « Jabber ».

Pour la publication de la musique en cours d’écoute certains clients musicaux le permettent déjà, c’est par exemple le cas de Bluemindo, où c’est possible en natif. Pour ceux que ça intéresse j’ai aussi un petit bot pour MPD.

J’espère que ce petit article aura permis de clarifier un peu ce qu’est PEP et à quoi ça peut bien servir.

La rencontre JabberFR du 5 juillet a été un succès, il y avait du monde (15 personnes, pour un évènement à peine annoncé), des gens sympa et une bonne ambiance. C’est vraiment bien de pouvoir voir en vrai des gens avec qui on a longuement discuté par internet. Encore merci à tous les participants.

La prochaine rencontre devrait avoir lieu à Lyon à l’occasion des Journées Du Logiciel Libre le 18 octobre 2008 au soir.

Et pour finir voici quelques photos de la soirée, je vous laisse deviner qui est qui sur les photos.