-->[]

De plus en plus de sites web passent à Gravatar. Ce service permet d'afficher sur son site web l'avatar des utilisateurs en se basant sur leur adresse mail. De la part des utilisateurs, il suffit de s'inscrire sur le site gravatar.com et d'y définir leur gravatar.

A priori l'idée est bonne. Cependant, le gros problème que je vois (et qui fait que je n'utiliserai pas ce système que ce soit en tant qu'utilisateur ou en tant que webmaster), c'est que plus l'utilisation de Gravatar se généralise, plus l'architecture qui en résulte devient totalement centralisée, ce qui va complètement à l'envers des bases d'internet.

Premièrement, c'est une architecture fragile: si gravatar.com décide de fermer, de rendre le service payant, etc., pouf, plus personne n'a d'avatar...

Ensuite, il est très facile pour eux de compter l'apparition de tel ou tel utilisateur ici et là. Grâce aux referrers, la boîte qui gère (ou rachètera) Gravatar a accès à la liste des sites où apparaît chaque utilisateur, ainsi qu'aux statistiques de fréquentation des pages qui contiennent les gravatars. En liant les deux, c'est facile aussi de savoir les centres d'intérêt associés aux adresses mail concernées. Jolie source d'info en perspective pour le spam et les collectes de données en tout genre à qui voudra acheter ces informations. Je sais pas pourquoi, je ne serais pas surpris de lire d'ici quelques semaines/mois que Google a racheté Gravatar.com.

De manière générale, il est assez intéressant de voir le fleurissement de ce genre de "services" sur internet: youtube, twitter, etc. (je suis pas fort en services web 2.0 mais vous complèterez de vous-mêmes). Ils souffrent tous du même problème que Gravatar. Si on opère un petit retour mental dans le passé, je me demande à quoi ressemblerait internet si le système DNS s'était développé sous cette forme, si HTTP s'était développé sous cette forme (ça a été tenté par the Microsoft Network alias MSN, et aussi par AOL), si les mails s'étaient développés sous cette forme (tentative toujours en cours par Microsoft), etc.

Pendant que j'y suis, et puisque c'est en plein dans le sujet, Omega a développé un système nommé Omniprésence qui permet de rendre son avatar Jabber accessible à une application web. Le site presence.jabberfr.org fait tourner cette application (mais d'autres le peuvent aussi, c'est là le point important), il est donc possible d'implémenter Omniprésence sur votre site web au même titre que Gravatar (mais en se basant sur l'adresse Jabber des utilisateurs). Cependant, pour ne pas tomber dans les mêmes travers centralisés que Gravatar, il serait intéressant de voir comment on pourrait déduire le "serveur Omniprésence" de l'utilisateur à partir de son adresse Jabber. À défaut, il reste aussi possible d'ajouter un champ pour l'indiquer explicitement. C'est plus lourd (enfin un champ en plus, ça va), mais ça change tout en termes d'architecture.

Quelques idées en vrac, y'a peut-être des grosses conneries, parce que ça vient de me traverser l'esprit. En jouant avec git ces derniers jours, je me suis dit qu'en fait, le processus de développement et la gestion des paquets Debian ont quelques points communs conceptuels avec git.

Par exemple, l'upgrade de paquet, finalement, ça ressemble à git pull, ou git fetch puis git merge. Vu qu'en général un paquet remplace l'ancien, le seul cas de conflit à gérer c'est les fichiers de conf, et c'est de la résolution de conflit typique de git. Si un fichier de conf n'a pas été modifié, il est mis à jour si une nouvelle version existe. Par contre, si le fichier a été modifié, on gère le conflit "à la main" (mais cadré par git). Déjà maintenant avec dpkg, on peut voir un diff, garder l'ancien fichier, écraser avec le nouveau, ou résoudre le conflit à la main. Très "git merge", quoi.

Du coup, dans la même idée, on peut imaginer l'évolution des paquets "côté Debian" comme des branches ("stable", "testing", etc.). Par ailleurs, sur un ordinateur donné, pour chaque paquet, la version installée localement serait une branche à part entière ? (ou bien l'ensemble des paquets serait une branche ?) Du coup :

• juste downloader les paquets c'est une sorte de git fetch d'une branche officielle.
• faire une mise à jour de paquets c'est merger cette branche officielle dans la branche locale.

Idem, lors des passages d'un paquet entre sid -> testing etc., et aussi pour la sortie d'une nouvelle version de Debian. On peut peut-être voir ça en termes de branches git ? de tags ?

Et l'upload de paquet par un DD ? git push ?

Plein de questions encore...

• qu'en est-il de l'update ?
• est-ce qu'on peut comparer un Changelog.Debian avec ce qui serait le ''git log' sur la "branche" du paquet officiel ?
• comment mettre à profit l'historique de modifications ? (pour la branche locale; pour les branches de paquets côté Debian)
• en quoi l'aspect décentralisé de git est intéressant ? comment ça peut se voir pour les mirrors ? finalement le /etc/apt/sources.list serait une liste de dépôts git...
• est-ce que le concept de backport est comparable au concept de git rebase ? je maîtrise ni l'un ni l'autre alors c'est peut-être une connerie...
• est-ce qu'on pourrait imaginer un frontend "git-like" à dpkg ? ou une réutilisation plus directe des algorithmes et concepts de git par dpkg ?
• vu sous cet angle, comment se voient les outils tels que dpkg-divert ?

bref, des idées en vrac, mais si je les mettais pas ça serait resté dans ma tête, alors que quitte à penser à des trucs idiots, autant les dire aussi, hein.

Je disparais bientôt en Roumanie pour quelques semaines, du coup il se pourrait que je ne blogue pas trop pendant ce temps, mais pas d'inquiétude.

Haha, elle est bonne hein ?

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..

Bon là je suis un peu mort de rire mais je vais quand même mettre le lien ici.

Alors maintenant faut que vous sachiez, la nouvelle feature de Google Images, c'est Google Image Labeller. C'est vraiment trop bien, vous avez le droit de mettre des mots-clés sur les images. Gratuitement, oui ! Sans avoir besoin de vous loguer sur votre compte Google, oui vous avez bien entendu ! Et vous gagnez des points. Des points qui servent à quoi ? Mais à rien, rhooo, c'est pas fini de poser des questions bizarres ? Y'a même une espèce de truc d'émulation mutuelle, on est en paire avec quelqu'un et c'est celui qui tague le plus vite qui a gagné.

Et oui, c'est nouveau, c'est gonflé, mais le pire c'est que ça va peut-être quand même marcher, on sait pas. Google ils sont vraiment balaises. D'ailleurs rigolez pas... matez un peu les All-time Top Contributors, y'a des scores de ouf, alors que le truc a quelques heures.

Non mais j'hallucine, sont vraiment mortels chez Google, hein. Comme dit Nico, je les imagine très bien : "On fait quoi... on le fait, on le fait pas ? Ça va passer tu crois ? Bon allez on le fait."

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 :)

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.

Ouah... je suis fasciné par la liste Swadesh du créole martiniquais. Du coup, je suis comme un con devant mon écran à lire les mots en créole, c'est trop bien...

C'est très instructif d'ailleurs, je viens de capter que le nom du groupe de musique Malavoi a probablement un rapport avec "bay lavwa" qui signifie "chanter" (ça vient certainement de "baye la voix", avec le verbe bayer qui signifie "rester la bouche grande ouverte" (comme dans "bayer aux corneilles")). J'aime beaucoup, aussi, "piébwa" qui veut dire "bois" (probablement dérivé de "pied de bois"), et "lapo piébwa" pour l'écorce, et "tibren" ("un peu", dérivé de "petit brin" j'imagine)... Bon y'en a plein, ok :) Ah oui, j'ai aussi un faible pour "timanmay" pour désigner les enfants ; d'ailleurs quand j'étais petit on nous appelait "la marmaille", mais d'un coup je me demande si c'est à cause des influences créoles dans ma famille ou si c'est un mot commun en français...

Oh, c'est rigolo, il y a pratiquement un an, jour pour jour, j'ai déjà passé une nuit blanche sur le même canapé, devant le même écran d'ordinateur, mais lisant et écrivant dans un autre langage.

Bon bah j'ai une maison (à Barcelone). Ça fait une semaine aujourd'hui... pourvu que ça dure :)

Oui je sais c'est un peu télégraphique comme post, mais c'est fou comme ça prend du temps ces petites bêtes. Allez, zou.