Pour un microbloging décentralisé, libre et indépendant.

D’aucun me pousse à ouvrir moi aussi un compte là bas. Mais après ? Car quels que soient les avantages fonctionnels supposés ou avérés de cette plateforme de Short bloging (comme elle aime à se définir), elle garde exactement les mêmes défauts que (presque) toutes les plateformes existantes :

• centralisée
• au main d’un acteur unique à qui je confie toutes mes données, sans aucune maîtrise dessus
• en échange de la gratuité d’un service, je donne une part de mon identité et de mon graphe social à une entreprise qui devra bien trouver un modèle économique... [1]
• je perds tout mon historique et mes connexions quand je change de plateforme (donc quand j’arrive, et quand je repars)
• la pérennité de la plateforme dépend de la capacité du prestataire à la maintenir en vie
• le code n’est pas libre, je n’ai aucune idée de sa solidité, de sa sécurité [2]...

Bien sûr Status.net est une initiative intéressante qui ne présente pas les deux derniers défauts. Mais hormis ce point elle ne fait qu’encourager à reproduire le même schéma centralisé qu’un Twitter [3].

Alors je me prends à rêver de ce que serait un outil de micro-bloging (micro, short ou long, peu importe) vraiment décentralisé, libre et indépendant, avec les même facilités qui font le succès d’un Twitter ou autre.

Libre

Cela va sans dire, l’outil serait totalement Open Source, installable sur presque n’importe quel hébergeur. Mais pas seulement.

Il convient en premier lieu que le format de publication soit standardisé et ouvert, et que l’API externe le soit aussi. Il ne s’agit pas de proposer un outil unique qui installerait une nouvelle dépendance, mais d’ouvrir la voie pour une pluralité d’outils qui peuvent communiquer ensemble indifféremment de leur technologie sous-jacente [4].

Décentralisé

Un outil décentralisé serait un outil dont j’ai la maîtrise :

• je peux l’installer chez moi (sur un serveur à moi, chez un hébergeur, peut-être même sur mon ordi ?)
• tout ce que j’écris m’appartient, je l’archive selon mes règles, et je ne suis pas tributaire de conditions générales susceptibles de changer à tout moment

Comme il ne s’agit pas non plus de faire un outil de geek réservé à ceux qui savent installer un serveur Web, il faut que je puisse installer mon outil en ligne aussi facilement que j’ouvre un compte Twitter actuellement [5].

Indépendant

Mais je veux pouvoir tout de même partir à tout moment avec mon compte et mes données (mes messages, les gens que je suis, et même si possible sans que les gens qui me suivent ne me perdent au passage)

La grosse différence est donc que j’utilise éventuellement un fournisseur du service pour faire tourner mon outil qui m’appartient, avec mes données, et avec lequel je peux partir à tout moment.

Fonctionnel

Je veux retrouver tout ce que j’apprécie dans Twitter.

Suivre

Une des composantes du succès de Twitter est la facilité avec laquelle on suit quelqu’un, d’un clic. Il faut donc que lorsque je suis sur la timeline de quelqu’un (que ce soit sur Twitter, sur identi.ca, ou sur sa timeline auto-hébergée), je puisse l’ajouter aux flux que je veux suivre d’un seul clic (un bookmarklet dans mes favoris par exemple, avec un fallback à peine plus compliqué si je ne suis pas sur mon ordinateur).

La composante technique sous-jacente à laquelle je pense tout de suite pour faire du suivi est le flux RSS, sans doute en utilisant PubSubHub pour plus de réactivité. Par contre, hors de question que je cherche le flux RSS par moi même : je dois simplement cliquer « Suivre » depuis la timeline Twitter ou autre, et l’outil se débrouille pour retrouver le flux (quand il n’est pas annoncé, il faut fournir la méthode pour chaque plateforme connue).

Mais dès lors, pourquoi me limiter à suivre des gens ? Je peux suivre avec le même outil un site internet dès lors qu’il dispose d’un flux.

Me voila avec un outil de bloging communautaire qui sait aussi faire de la veille technique classique !

Poster

OK, je ne veux pas seulement suivre, mais aussi poster mes status (micro), messages (short), billets (long). Je veux me fixer ma règle sur le format de mes posts.

Je veux aussi que ceux qui me suivaient déjà sur Twitter continuent à lire ce que je publie (je dis Twitter, mais ça vaut aussi pour Identi.ca, SeenThis, ma page FaceBeurk ...) : il ne s’agit pas de faire la révolution du grand soir en demandant à tout le monde de changer d’outil d’un coup.

Après tout cela ne me gêne pas que nombre d’utilisateurs se satisfassent d’une plateforme centralisée. Il en faut pour tout les goûts.

Symétriquement au suivi qui se fait par RSS, ma publication se fait de la même façon, ce qui alimentera automatiquement ceux qui me suivent par leur microblog individuel.

Par contre, il est évident que l’outil va devoir faire un peu de Push vers les outils centralisés : je devrai donc pouvoir y déclarer mes comptes existants sur ces plateformes, charge à lui de relayer automatiquement via leur API. Rien de compliqué en la matière (ne pas oublier de couper correctement les messages trop longs, en y ajoutant une URL pour lire le message complet).

Répondre

Les réponses sont justes un format particulier de Message. On l’indique explicitement dans le flux RSS en référençant le message source.

Pour qu’une réponse depuis mon outil à un message Twitter (ou autre) fonctionne, il faut que mon outil garde la source, et l’id du message d’origine. Charge au push d’y mettre ensuite les bonnes formes. Il va de soi qu’on ne push une réponse que sur la plateforme de laquelle vient le message source

Retweeter

Encore un cas particulier de Post. Pour retweeter un message d’origine décentralisée vers une plateforme centralisée il faudra le préfixer en y insérant une URL du message d’origine, non visible sur Twitter, sous la forme « RT short/url/msg/src : ».

DM

Le cas du DM est un petit peu plus compliqué, il ne s’agit pas de le faire apparaître dans la timeline.
Il faut distinguer les différents cas.

DM décentralisé vers décentralisé
Dans ce cas, il faut que mon outil envoit un hit vers celui à qui j’écris, pour dire « Hey, man, j’ai un DM pour toi. Voici sa référence (URL+id) pour venir le chercher ». Charge alors à l’outil de mon correspondant de venir chercher le message si il considère que ce n’est pas du SPAM (basiquement, si il me suit déjà, mais il peut changer cette règle et accepter des DM de tout le monde).

Sans doute faut-il que la référence du DM s’accompagne d’une jeton non prévisible pour éviter à un curieux mal intentionné d’essayer de venir piocher chez moi des DM qui ne lui sont pas destinés.

DM décentralisé vers centralisé
Pour envoyer un DM vers un utilisateur de Twitter, il faut passer par mon compte Twitter et son API. A priori rien d’insurmontable.

DM centralisé vers décentralisé
Quand un utilisateur Twitter me DM, il envoie un fait un message vers mon compte Twitter. Donc mon outil doit relever les DM et me les faire suivre.

Voir les gens que je suis

Rien de compliqué : mon outil les a tout sous la main, dans sa base. Rien de plus facile que de les lister, et de permettre de les classer, grouper, taguer etc... pour permettre ensuite d’avoir des timeline thématiques (l’équivalent des listes de Twitter).

Je m’attends qu’au moment où je migre de Twitter vers mon outil décentralisé, celui-ci récupère automatiquement tous les gens que je suis, pour ne pas devoir refaire cette liste à la main.

Mon outil doit me permettre ensuite de conserver la synchronisation de la liste des gens que je suis avec celle de mes compte sur les plateformes centralisées. Mais ce ne doit pas être une obligation non plus (je peux vouloir suivre silencieusement des utilisateurs de Twitter ou autre).

Voir les gens qui me suivent

Pas compliqué de lister ceux qui me suivent sur les plateforme centralisées où j’ai un compte.

Par contre, pour voir ce qui me suivent par leur outil décentralisé, j’ai besoin qu’ils me le déclarent.

Il faut donc prévoir un mécanisme de ce type déclaration « follow/unfollow » basé sur le volontariat : par défaut actif dans mon outil, je peux le désactiver, auquel cas les gens que je suis ne le sauront pas. Après tout, cela fait aussi parti de ma liberté que de rester caché dans mon coin.

Les recherches

Les recherches concernent les fonctionnalités du type : voir tous les messages avec tel #hashtag, voir tous les messages qui me mentionnent, qui mentionnent tel utilisateur ...

Là c’est clairement le point où je n’ai pas de solution technique simple sur le long terme.

J’entends pas là que si je suis tout seul à migrer vers mon outil décentralisé, je ne perds rien : mon outil peut relayer mes recherches vers les plateformes centralisées, et me présenter les résultats de façon unifiée (y compris en mixant tout ce que je suis hors plateforme centralisée).

En revanche, dans un modèle où l’utilisation de cet outil décentralisé se répand c’est plus compliqué. Je ne vais pas aller interroger chaque instance de l’outil (et d’ailleurs je ne sais même pas les lister, par nature). Je ne peux donc a priori pas faire de recherche généralisée hors les flux que je suis.

L’embryon de solution que je vois reposerai sur la déclaration ET un outil centralisé dédié à la recherche :

• dans mon outil, j’ai une option « Apparaître dans la recherche centralisée ».
• l’outil signalerai son existence et son flux à une plateforme de recherche centralisée.

La question qui reste est comment gérer (techniquement et financièrement) cette plateforme de recherche :

• Celle-ci peut n’être qu’un simple outil qui liste un ensemble de flux et maintient une instance de recherche restreinte à cette liste dans un moteur de recherche public (mais c’est une prestation payante), charge ensuite à mon outil décentralisé d’interroger ce moteur de recherche (en direct ou via la plateforme ?)
• Ce peut être une plateforme qui maintient un index de tous les messages et réponds aux requêtes de recherche des outils décentralisé.

Je pense que cette fonctionnalité ne doit pas être bloquante pour le moment : tant que la proportion de microblog décentralisés reste faible au regard de ceux hébergés par les plateformes centralisées, on peut continuer à se reposer sur celles-ci pour l’assurer. En particulier, si l’outil décentralisé réplique au moins partiellement les messages que l’on envoi avec lui, on n’a pas vraiment de perte de fonctionnalité.

La question se pose plutôt dans une hypothèse (sans doute complètement utopiste) où il y aurait un basculement significatif du parc des utilisateurs vers cet outil décentralisé.

Qu’est ce qu’on attend ?...

A la réflexion, et en dehors de ce dernier point, je ne vois rien de techniquement compliqué dans la mise en place de cet outil de (micro|short|long)bloging décentralisé, tout en proposant des fonctionnalités semblables à celles qui font le succès de Twitter.

Toutes les briques techniques sont là, disponibles, et il me semble qu’il ne reste qu’à les assembler pour changer de modèle.

Mais peut-être suis-je passé complètement à côté d’une évidence, d’un point de blocage essentiel, ou d’une fonctionnalité indispensable que j’aurais oubliée ?

Et vous, qu’en pensez-vous ?