IM2 | OQP

[Je voulais publier ça tout de suite, même s'il manque la conclusion, les URL et les titres. J'y reviens plus tard. J'attends quand même vos commentaires !]

Si les blogues se veulent de plus en plus épurés, proposant des textes mieux polis, il n’en reste pas moins que leurs auteurs demeurent humains avec tout ce que cela implique. Manger, communiquer, penser, s’informer, etc. C’est ainsi je crois que sont nés les microblogues et les tumblelogs. Twitter est problablement l’exemple le mieux connu, ou le status de Facebook mais quand on y pense, nos réseaux IM supportent depuis longtemps une notification de notre status. Mais le microblogue, c’est plus que ça. Sans parler de l’effet purificateur sur les blogues mais ça ce n’est qu’une théorie.

D’ailleurs, Twitter est loin d’être la seule option. Une compagnie de Toronto vient de lancer Plurk qui comporte plusieurs particularités, dont une visualisation sur une ligne de temps et l’échange de commentaires en temps réel (chat) sur un post. Jaiku, maintenant propriété de Google, promet de revenir en force quand on pense à Android pour le support mobile et son agrégateur natif. Un dernier exemple dans le genre, Pownce permet l’échange de fichier.

Côté tumblelogs, soup.io se démarque par son look et son interface qui permet entre autre de facilement partager et reprendre du contenu dans son réseau. tumblr, un des services originaux est toujours là, bien sûr. jaanix propose une version tunée du web. Ce n’est pas le choix qui manque.

On peut même utiliser del.icio.us pour indiquer ce qu’on est en train de lire, ou encore plus spécifiquement, claimid pour avertir quand on s’inscrit à un site web. Dans tous les cas, il s’agit de partager, le plus rapidement et le plus simplement possible, soit un lien ou un bout de texte, une image, un vidéo, une chanson, etc.

Plusieurs médiums sont disponibles. Du site web, on utilise souvent un bookmarklet ou une extension quand on ne se contente pas de l’interface web native. Par exemple, avec plurk, c’est intéressant de voir défiler les posts sur une ligne de temps et de pouvoir répondre comme dans un chat, en temps réel. Souvent, on pourra aussi compter sur une interface par IM comme Jabber (Google Talk) ou MSN et AOL par exemple.

D’autres fois, on optera pour un logiciel spécifique à cette tâche. Ils sont de plus en plus nombreux à supporter une ou plusieurs plateformes. J’avais commencé Nitwit, un client pour Gnu Linux, Mac OS X et Windows pour parler à Twitter et Jaiku et Pownce quand ce dernier est apparu. Twhirl est très populaire, il en existe des tonnes d’autres.

Certaines plateformes, comme Jaiku mentionné précédemment, peuvent aussi agréger vos fils RSS externes. D’autres, comme Brightkite, vont publier automatiquement sur Twitter ou d’autres services. Il n’est pas rare de voir quelques alliances se former, le plus souvent autour de standards ouverts heureusement. Les alliances tacites, comme celle entre Brightkite et Twitter par exemple, on l’avantage sur le RSS d’être beaucoup plus rapide au niveau de la diffusion. Un fil RSS doit être lu régulièrement pour savoir s’il a été mis à jour, tandis que l’autre modèle, le push, envoie quasi simultanément un message équivalent aux services abonnés. Tôt ou tard, il va falloir réaliser les limites de la syndication par RSS, du moins pour les messages et la communication.

Parlant de Brightkite, je ne peux passer sous silence Fire Eagle, un service de Yahoo! qui permettra à ses utilisateurs d’avoir un point d’accès pour donner notre position et la révéler selon la précision voulu à des individus ou des groupes voulus. Il s’agit presque de micromicroblogging et j’imagine assez facilement un autre service du genre pour enregistré notre état d’âme actuel ou toute autre donnée assez générique et personnelle à la fois.

Dans la majorité des cas, on trouvera aussi une API qui permettra aux développeurs et aux applications de communiquer entre eux. C’est un aspect non négligeable des services disponibles, comme le respect des standards existant. Parfois, il s’agit de widgets mais le plus souvent, on aura droit à une API REST, c’est à dire utilisable dans toutes sortes d’applications, soit web, soit sur notre poste de travail, soit inter-services.

On voit apparaitre depuis peu des services spécialisés qui permettent de publier sur plusieurs plateformes à la fois. Je pense à ping.fm et hellotxt. ping.fm vient avec trois interfaces : Web, API et IM. Des trois, ont peut s’adresser à notre réseau social sur des dizaines de plateformes simultanément. (à tester : http://www.presencr.com/ et http://alpha.brabblr.com/ )

De l’autre côté, on a des outils comme friendfeed et profilactic pour faire l’agrégation de nos courtes publications (ou états d’âmes, c’est selon) et celles de notre réseau. Que ce soit notre réseau sur digg, del.icio.us ou twitter, à travers une seule fenètre on pourra découvrir absolument tout ce qui circule via un de nos services préférés. On pourrait tout aussi bien utiliser un service d’agrégation plus générique comme Google Reader, mais les services spécialisées devraient en théorie être en mesure d’offrir un service mieux adapté qu’un simple feed reader qui n’aura souvent pas la notion de contact et d’identité.

Ce qui m’amène à énumérer quelques protocols importants et un aperçu de leur utilité dans cet écosystème qui se cherche toujours un équilibre.

Tout d’abord, OpenID. Si vous rencontrez des sites qui ne permettent toujours pas l’utilisation d’OpenID pour se connecter, il faut le demander. Si vous n’avez pas votre OpenID, il existe plusieurs moyens de l’obtenir. Maintenant, vous voudrez probablement le personaliser si vous possédez votre propre nom de domaine vous identifiant.

Idéallement, vous aurez un hCard au bout de votre OpenID, ce qui permettra, en complément à OpenID, d’obtenir facilement votre email, votre nom, votre adresse, photo ou toute information que vous décidez de partager avec la planète. Un hCard c’est l’équivalent d’un vieux format, le vCard, qui sert déjà dans plusieurs logiciels pour les données de contact. D’ailleurs un hCard se converti facilement en vCard.

Une fois abonné à un nouveau service, il faut en général y retrouver ses contacts. Certains sites demandent le mot de passe d’un autre site pour accomplir cette tâche. Bien pratique en apparence, c’est un vrai casse-tête de sécurité. D’un côté on nous répète depuis la nuit des temps qu’il faut conserver notre mot de passe à tout prix, et voilà maintenant que sur chaque nouveau site, on nous demande notre mot de passe GMail (par exemple) pour importer nos contacts. C’est en faut une très très mauvaise habitude dont il faut se départir au plus vite pour ne pas perdre tout acquis de sécurité qu’on avait gagné aux cours des dernières années.

Pour corriger ce problème, plusieurs services supportent maintenant le protocol OAuth. Un peu comme le petit frère de OpenID mais celui qui se réveille plus tôt et qui fait le café quand on dort encore. Plus sérieusement, c’est un protocol qui permet à deux services de communiquer avec notre authorisation, sans que l’on doit révéler notre mot de passe.

Une autre façon d’aborder le problème est de décentralisé notre réseau. Deux protocols assez répendus sont utilisés dans ce cas : FOAF et XFN. FOAF signifie “Friend of a Friend” et permet de représenter dans un fichier XML nos contacts et nos relations avec ces derniers. XFN, pour “XHTML Friend Network” utilise le XHTML comme son nom l’indique pour relayer cette même information.

L’initiative OpenSocial tente de ralier toutes ces idées et offre des services en lignes accessibles aux développeurs et utilisateurs.

Un autre protocol a récemment vu le jour, semant un peu de cntroverse. OEmbed permet tout simplement de remplacer un URL par sa représentation la plus pratique. Par exemple, si on donne l’URL de la page d’une photo sur Flickr, on obtiendra à sa place un thumbnail de la photo. Pour une page Youtube, ce sera le vidéo lui-même, etc. Ainsi, c’est ce qui se produit automatiquement sur Pownce, un service qui consomme les OEmbed. Sur Twitter, comme ce n’est pas supporté nativement, il faudra faire appel à un script Greasemonkey ou bien il faudra lire son Twitter à partir d’un agrégateur qui supporte OEmbed.

En quoi un protocol du genre peut-être controversé ? Il se trouve que le protocol HTTP, utilisé par OEmbed, supporte lui-même depuis 1996 au moins le header Content-Type qui permet de demander au serveur la représentation voulue. Bref, OEmbed fails REST.

Un avantage à tout ce réseautage, c’est une amélioration significative du signal par rapport au bruit. On peut pratiquement dire au revoir au spam, puisqu’ici, nous choissisons qui nous voulons entendre, et selon quels médiums.

Quelques mots sur cette Tradition orale 2.0 qui nous englobe un peu plus chaque jour. Je dis tradition orale, à cause des nombreuses relectures et citations que peuvent recevoir les messages lancés dans un réseau et du sens qui s’y déforme ou bien des positions qui s’y galvanisent. Mais en fait, chaque message écrit, dès la touche [ENTER] relâchée, est protégé, en votre nom, par le droit d’auteur. Seule une licence en permet un usage ultérieur. D’où l’intérêt des licences toutes faites comme celle de la Free Software Foundation (GFDL et GPL par exemple) ou de Creative Commons (BY, BY-SA, etc.).

Finalement, qui est responsable de vos paroles ? Étrange question, n’est-ce pas ? Avant d’aller trop loin, notons que les mêmes règles s’appliquent que dans la “vie réelle”. Dites vous que le monde virtuel n’est pas si grand que ça après tout, et que si vous cherchez des ennuis, ces ennuis risquent de vous suivre très très longtemps. En s’en tenant à la netiquette de base, soit le respect d’autroi et l’attention aux questions et réponses précédentes, on évitera la plupart des tracas sans effort particulier.

Selon votre pays, le pays qui héberge le service, le pays d’un plaignant, plusieurs personnes peuvent être considérées comme responsables de vos paroles sur internet, vous en premier. L’identité dont nous parlions plus tôt n’est pas infaillible, on peut aussi utiliser des services anonymement pour toutes sortes de raisons (parce qu’on a oublié notre mot de passe ou encore pour dénoncer un geste sans risquer de représaille). Ainsi, l’administrateur d’un service pourra parfois être tenu responsable, ou encore même les modérateurs du service. Disons le tout de suite, la diffamation et les injures n’ont jamais leur place et internet ne fait pas exception.

[Je répète, je vais écrire une conclusion plus tard]