Le Web est déjà social.
J'aime bien lire les news. On apprend des tas de choses et parfois sur des thèmes sur lesquels on n'aurait pas spontanément fait des recherches voire des choses dont on ne soupçonnait pas l'existence.
Mais toutes les news ne m'intéressent pas. J'en trouve une super ici ou là, mais elles ne sont jamais nombreuses au même endroit, que ce soit parce que c'est un blog avec un seul rédacteur et donc peu d'articles ou juste des articles perdus au milieu d'autres qui me passionnent moins.
J'ai cherché pendant un moment un site de news qui aurait une section avec une majorité d'articles qui me plaisent, que je puisse lire le matin, pas réveillé, en sirotant mon café.
J'ai pas trouvé.
Normal, chacun a des goûts différents donc il ne peut pas exister un tel site pour chacun. Sauf… si chacun le fait lui-même ! Certes, écrire des news pour soi-même, ça n'a pas grand intérêt (ou bien ça s'appelle un journal intime) et c'est surtout hautement incompatible avec mon inactivité matinale.
C'est là que RSS entre en scène ! Le concept est à la fois super simple et super tout court : chacun met à disposition ses articles sous le même format pour qu'ils puissent être regroupés de façon cohérente sur une unique page.
Depuis que je sais ça, je ne peux plus me passer de mon lecteur de flux (Leed, avec le thème Greeder pour plus de confort — edit: et bientôt Freeder !) et je maîtrise pleinement mes news : si une source me plaît pas, je la vire, si j'ai trop de news par jour, je retire certains flux de la page d'accueil, etc. En prime, je peux faire ma petite cuisine en notant les articles que j'ai lu, ceux que j'ai aimé, etc.
C'est top, surtout que RSS est vraiment très répandu car simple à mettre en place et inclus dans la plupart des CMS comme WordPress, Drupal ou autre. On peut donc s'abonner à tout et n'importe quoi.
(J'en profite pour remarquer que les flux RSS avec seulement un résumé des articles, c'est pas pratique…)
J'ai tellement adopté RSS que j'ai tendance à vouloir le caser partout. Il peut permettre en plus de s'abonner aux blogs et sites de news de se tenir au courant des mises à jour disponibles, de suivre les commits d'un projet (avec GitHub par exemple), de recevoir ses rapports de sécurité de son serveur (là, il faut un accès sécurisé quand même, mais c'est possible !), et tout ce dont votre imagination peut être capable.
C'est pas le format RSS en lui-même finalement que je trouve vraiment cool, mais le concept de syndication. Un petit tour sur Wikipedia pour voir ce qui se cachait derrière ce curieux terme nous révèle que c'est — dans le cas de ressources Web — un moyen d'accéder au contenu d'un site depuis un autre.
Pour reprendre un terme à la mode, c'est en quelque sorte une API en lecture seule. Ce qui est assez magique, c'est que ça permet de faire de la centralisation personnelle. J'explique : Pour faire très très court, les services centralisés c'est mal parce que ça donne trop de pouvoir au fournisseur du service (et donc ceux capables de le faire chanter) du coup on héberge ses propres services. Sauf qu'on perd dans l'histoire pas mal de choses, et notament le lien avec les autres.
La syndication est le moyen de rétablir ce lien en centralisant à une échelle personnelle les informations dont on a besoin. Là où RSS atteint ses limites, c'est sur la symétrie de ce lien. RSS permet de récupérer du contenu ailleurs, mais pas d'en envoyer en retour.
On peut trouver ça normal : on lit les articles des autres blogs, mais si on veut écrire un article, on l'écrit chez soi ! Et puis pouvoir écrire chez les autres, ça peut poser de petits soucis de sécurité si on fait pas gaffe… Mais quand même, y a des trucs qu'on aimerait bien écrire chez les autres car n'ont aucun intérêt seuls : les commentaires et réactions aux articles par exemple.
Certains ont eu cette idée avant moi, bien sûr. L'exemple le plus évident étant Facebook (Est-il vraiment nécessaire de mettre un lien là ?) : fondamentalement, le fameux Mur n'est ni plus ni moins qu'un agrégateur des flux suivis, dits « amis ». C'est bête, mais j'ai mis pas mal de temps à m'en rendre compte finalement. Sur un format différent, Twitter est un bon exemple aussi. D'ailleurs, dans « micro-blogging », il y a « blog ». (J'ai l'œil n'est-ce pas !)
Bon mais ils sont complètement privés et fermés ces deux exemples. On en fera rien de plus que ce qu'ils sont prévus pour et on récolte tous les problèmes de la tant décriée centralisation.
C'est alors qu'entrent en scène des projets comme Diaspora*, qui se veut concurrent direct de Facebook qui met en avant la décentralisation, ou StatusNet (paix à son âme) qui imitait plutôt Twitter, lui.
Mais ces exemples cherchent trop à copier ce qui existe sans réfléchir à ce que peut apporter un support décentralisé. L'organisation centralisée à ses forces et ses faiblesses et c'est en tenant compte des deux que Facebook, par exemple, s'est développé. Mettre en place une alternative décentralisée, c'est super, mais on ne peut pas se contenter de recopier purement et simplement l'organisation de la version centralisée ! On passerait forcément à côté des avantages apportés par la décentralisation puisque le design de Facebook a justement été pensé pour les éviter. Et d'un autre côté on se retrouve à lutter contre des faiblesses qui ne concernent intrinsèquement pas le service centralisé.
Résultat, lorsqu'on essaye d'utiliser Diaspora* on le compare naturellement à Facebook et on ne comprend alors pas pourquoi il est nécessaire de choisir un « pod » ou bien pourquoi il est si difficile de trouver des amis comme on peut le faire sur Facebook, juste en tapant leur nom. Au final, les gens voient ce qu'il y a de moins bien, et comme aucune nouveauté n'est apportée, on ne voit pas ce qu'il y a de mieux. Outre le côté décentralisé et confidentiel, mais c'est pas ça qui doit faire venir les gens.
Je comprends bien que l'idée est de reproduire un service que les gens connaissent pour les inciter à venir. Mais j'ai deux réponses possible pour ça :
C'est comme ça que beaucoup sont déçus par Diaspora* (un exemple, et un autre) et que StatusNet est tout simplement mort (Pas de news sur le site depuis une annonce de faille il y a un an, identi.ca qui ferme, etc.) au profit d'un autre projet qui n'arrive pas à se lancer puisqu'il ressemble plus à une API qu'à un réseau social.
Je pense qu'il faut plus mettre en regard blogs et réseaux sociaux. La blogosphère est un réseau social. C'est même ce qui devrait être l'exemple canonique de réseau social décentralisé. On a du mal à voir les choses sous cet angle à première vue puisque les paradigmes sont très différents, mais c'est justement à ce genre de différence entre centralisé en décentralisé que je pensais tout à l'heure. Les contraintes sont fondamentalement différentes et c'est pour ça que les blogs et les réseaux sociaux au sens usuel diffèrent tant.
D'autant plus qu'il n'est pas dans l'intérêt de Facebook de mettre en évidence le fait qu'un blog fait la même chose. Ils ont donc énormément travaillé à ce que l'aspect centralisé leur apportait, évidemment (et c'est tout à leur honneur).
Les projets comme Diaspora* me donnent donc vraiment l'impression d'être — pardonnez moi l'expression, mais elle est de circonstance — « le cul entre deux chaises. »
Finalement, qu'est-ce qui est intéressant avec la décentralisation ? C'est le fait de pouvoir conserver ses données, c'est vrai. Mais dans ce cas ça nécessite toujours de pouvoir les héberger quelque part. Ça demande donc un investissement, aussi bien en temps qu'en argent. Bref, c'est pas vraiment ça la cible.
Non, l'avantage d'un système décentralisé et ouvert, c'est l'alternative, le choix entre plusieurs solutions pour une même chose.
Par exemple si on ne veut/peux pas héberger sa propre instance de Diaspora*, on va chercher un pod public. Mais peut-être qu'il est dirigé par des gens mal intentionnés ou qui nous espionnent ? On retombe alors en plein dans les problèmes d'un système centralisé là. Sauf que non : il suffit d'aller voir un autre pod !
En fait, c'est exactement comme pour les e-mails. Héberger son propre serveur mail, c'est pas évident, ça pose des problèmes de sécurité, d'interaction avec les autres serveurs, de stabilité (en cas de panne, plus de mails !), etc. Donc en pratique on (les gens normaux) laisse une boîte compétente s'en occuper pour nous. Et si on est pas satisfait, on va voir ailleurs, simplement.
En économie, ça s'appelle la concurrence, tout simplement. Et même si elle est parfois contestable, elle est profitable dans pas mal de cas : ça permet de faire baisser les prix, d'améliorer (sous certaines conditions) l'expérience utilisateur et tout. C'est en tout cas pas un modèle absurde, alors pourquoi ne pas l'appliquer dans notre cas aussi ? Faut adapter un peu le problème, en remplaçant « prix » par « exploitation des données personnelles » par exemple, mais l'idée reste la même : un service unique freine l'inovation en limitant les branches, les tentatives éventuellement ratés, mais aussi celles qui marchent et apportent quelque chose à tous !
Je pense donc que la décentralisation ne doit pas concerner que les instances, mais aussi les clients ! Pourquoi faudrait-il obligatoirement telle usine à gaz pour aller sur tel réseau ? C'est encore un point qui me gêne avec Diaspora*. C'est ouvert, donc on peut faire des clones qui dialoguent avec, mais il n'a pas été suffisamment pensé pour selon moi. Certes, la doc spécifie bien que ce n'est qu'une implémentation et que l'on peut en faire d'autre, indique ce qu'il est capital d'implémenter et ce qui est secondaire, mais le problème selon moi c'est que Diaspora* veut donner la même impression que Facebook : que le tout est un gros bloc indivisible.
Là encore, c'est une erreur qui vient de la version centralisée : la volonté d'uniformité. La force du décentralisé est justement ce qui me plaît tant dans RSS : chacun en fait ce qu'il veut, avec les outils qu'il veut !
Ce qu'il nous faut, c'est donc un protocole.
Un protocole, contrairement à une API ou un clône de Diaspora*, met généralement en place des fallbacks lorsque telle ou telle fonction n'est pas mise en place. On peut donc l'utiliser partiellement, en ne prenant que ce dont on a besoin, mais aussi l'utiliser avec des gens qui ne l'implémenteraient pas totalement sans problème majeur.
Bon, il faut évidemment des implémentations aussi, faut bien pouvoir l'utiliser. Pour ça, le plus simple, et le plus logique, et le mieux, et tout ce que vous voudrez, c'est de ne pas réinventer la roue. Par exemple, on a déjà RSS pour partager les flux. Eh bien utilisons-le ! Il existe déjà des tonnes de gens qui l'utilisent, des tonnes de moyens de l'utiliser, et même des micro-formats basés dessus pour l'étendre ! Du coup, votre lecteur RSS et votre blog utilise déjà ce réseau social… Magique n'est-ce pas ?
Je vous vois venir : avec ces histoires de protocoles pas finis, d'implémentations dans tous les coins et tout, je vais perdre tout le monde. Les gens ne vont rien comprendre et ne viendront pas. Mais toute l'astuce est dans le fait que les gens l'utilisent déjà et ont peu de chose à faire pour l'utiliser plus. Qu'ils peuvent l'utiliser seulement un peu plus, ou alors beaucoup plus, selon leurs besoins. Et la multiplicité des clients n'est pas un problème pour moi. Un très bon exemple, trouvé dans cet article trouvé par hasard (qui abouti à la même conclusion que moi d'ailleurs), est celui des e-mails. La majorité des internautes s'y est faite, et si les e-mails sont aussi utilisés et n'ont pas été délaissé malgré la vitesse à laquelle les modes changent sur Internet, c'est parce que ce n'est pas un programme, c'est un protocole !
Le réseau social n'est ni le protocole, ni l'application. C'est ce que les gens en font, le fait qu'ils soient plusieurs à l'utiliser et interagissent. De même, les mails ne sont ni un protocole, ni une application.
Le protocole doit être extensible (pour y ajouter ses propres micro-formats), incrémental (pour pouvoir n'être implémenté que partiellement), facile à mettre en place (au moins partiellement), utilisé par un maximum de personnes (donc si possible déjà en place).
Là encore je ne suis pas le premier à avoir l'idée : le protocole n'a pas été oublié, bien qu'aucun n'ait été consacré par l'usage pour le moment. StatusNet a développé OStatus, qui a été repris par GNU Social et a inspiré le protocole de Diaspora*. Tous deux ont tenté de rendre leur protocole souple et ouvert, allant jusqu'à discerner ce qui doit être implémenté de ce qui est accessoire, parlant d'« implémentation de référence » pour insister sur le fait qu'ils n'ont pas pour but d'être la seule instance utilisant ce protocole, etc.
Mais dans les faits ces protocoles ne sont pas du tout réutilisés. Le fait que Diaspora* n'ait pas simplement repris le protocole de StatusNet montre qu'OStatus n'était pas assez souple. Ou que Diaspora* cherche un protocole trop spécifique.
Autant le protocole de Diaspora* est plutôt bien documenté, autant OStatus est vraiment difficile à trouver. En fait je suis parti d'OStatus pour écrire cet article. Je cherchais un protocole social et on m'a parlé d'OStatus donc je suis allé voir ce qu'il en était.
Enfin j'ai essayé.
Les seuls liens que j'ai pu trouver étaient cassés. La page du groupe de recherche sur OStatus sur le site du W3C est grosso modo vide, et les deux seules news datent de 2012.
On trouve quand même un peu de doc dans un coin, mais c'est un wiki de quatre malheureuses petites pages qui ne donnent pour ainsi dire aucun détail technique utilisable.
En fait que ce soit sur les pages officielles, les mailing-lists ou même les projets annexes, tout semble s'arrêter en 2012. J'ai trouvé deux implémentations, une en Ruby et une en Python, toutes deux sans commits depuis deux ans. Le plugin OStatus pour WordPress est mort il y a deux ans aussi.
Mais aucune annonce officielle de l'abandon d'OStatus. Il semblerait donc que StatusNet et identi.ca aient emporté OStatus dans leur tombe, ce qui montre le manque d'indépendance entre le protocole et son implémentation.
En fouillant dans les groupes de travail du W3C, j'ai trouvé tout plein d'autres tentatives de protocoles allant dans le sens d'un web social :
À chaque fois, c'est le même topo : pas plus de trois messages dans les mailing-lists, aucune trace d'un début de standard, ou alors décrite vaguement et clairement à l'abandon.
Puis il paraîtrait qu'Evan Prodromou a trouvé un job donc a un peu tout laissé tomber, du coup tout s'écroule. Il y a clairement un problème d'organisation si le départ d'une seule personne arrête tout… Je pense que Diaspora* a dépassé ce stade par contre, et a été adopté par une communauté un peu plus large que trois personnes et ne pourra donc pas mourir de cette façon.
À ce moment là, j'ai un peu perdu foi en le W3C…
J'ai tout de même fini par trouver un peu de doc sur le site de StatusNet. OStatus partait tout de même d'une bonne intention : il avait pour volonté de ne pas trop réinventer le roue en se basant en grande partie sur des protocoles déjà existants et évitait donc le fameux problème des standards.
Il se base sur Atom (une évolution très répandue de RSS) pour la base (les flux d'info), et y ajoute un petit plus pour chacune de ses lacunes en tant que protocole de réseau social (ce qu'il n'est pas à l'origine).
Il ajoute pour commencer un peu de push à Atom avec PubSubHubbub. Ça c'est une bonne chose : La façon « traditionnelle » de lire des flux RSS est d'aller voir régulièrement s'il y a de nouveaux articles dans les flux. Mais on ne peut pas non plus aller voir toutes les minutes si de nouveaux messages sont arrivés sinon ça surcharge tout le monde. Et pour rien en plus puisque dans la majorité des cas il n'y a eu aucune nouvelle en fait. C'est ce qu'on appelle le « pull » : on fait une requête au serveur. Le « push », à l'inverse, c'est une sorte d'abonnement. On dit au serveur qui fournit les articles « Préviens-moi dès qu'il y a du nouveau ! » et il nous ajoute à une liste de personnes à prévenir. Indispensable si on veut quelque chose d'un minimum réactif.
Ensuite, pour pouvoir commenter les articles depuis son agrégateur, il inclut le standard Salmon, utilisé également par Diaspora*. Mais je le trouve incroyablement complexe ce protocole…
On trouve aussi ActivityStreams pour « typer » les messages. Ça aussi ça me semble être une bonne idée. Ça permet à l'agrégateur d'afficher différemment ces articles. StatusNet les utilise pour différentier les messages de statut des « retweets » ou des messages du style « Machin vous suit » ou encore « Truc a changé de photo de profil ». Moi je pense plus les utiliser pour indiquer que tel petit articles est une citation, ou tel autre un snippet, etc. Par défaut ils seraient affichés comme tous les autres articles, mais on pourraît aussi les prendre en compte pour les afficher différemment ou les agréger quelque part.
Là encore, je trouve le protocole bien compliqué. Je me serait contenté d'un nom de <category> (les tags dans le format Atom) consacré et puis c'est tout…
Le dernier protocole d'OStatus, Webfinger, est lui aussi utilisé par Diaspora*. Il permet en gros de donner des infos à partir d'un identifiant de type alice@example.com sur où trouver ses flux, ou bien où Alice habite (si elle a décidé de le partager), etc. OStatus et Diaspora* l'utilisent pour trouver les endpoints des différents protocoles utilisés.
C'est donc dommage que le protocole ait l'air d'être un peu mort : il y avait vraiment de bonnes idées.
Je n'ai pas lu le protocole dans ses moindre détails, mais il semblerait qu'il soit pas mal inspiré d'OStatus. On y retrouve les flux Atom, la recherche par Webfinger, Salmon, le push. J'ai aussi vu qu'il y avait eu une discussion un peu houleuse au sujet du protocole à utiliser pour les messages. C'est finalement Salmon qui est utilisé, et non XMPP avec lequel les devs du moment hésitaient.
Par contre, même si c'est prévu d'être corrigé, j'ai été pas mal dérouté par le fait que c'est push-only pour le moment : Si on (notre serveur) n'est pas là au moment où un message est émis, impossible de le lire. Typiquement, pas possible de lire les messages écrits avant notre inscription.
Mais comme je l'ai dit plus haut, je suis loin d'être complètement convaincu par Diaspora*. Sur le principe je veux dire, pas seulement à cause de son état actuel (où il reste encore des tas de petits détails à implémenter, mais c'est normal pour un projet en dev).
Du coup j'ai continué mes recherches et je suis tombé sur Tent.io, par l'intermédiaire d'une issue polémique : Why not OStatus?.
Tent is designed to be the hub of your digital life and remove any centralized authorities that could screw it up.
On retrouve donc bien l'idée de décentralisation et l'importance des protocoles, ce que la page d'accueil vante très bien. Elle fait d'ailleurs elle aussi le parallèle avec les mails. Tent se veut bien plus général que juste le web social. Il veut en fait développer une API pour toutes les données que l'on partage sur le web et qui serait utilisable par des applis, un peu à la façon des applis Facebook, mais en prenant les données chez nous.
Cependant il n'est pas prévu pour que chacun installe sa propre instance. Comme pour les mails (encore une fois), l'idée est qu'il y ait différents hébergeurs et qu'on choisisse celui que l'on veut. Du coup l'accent n'est pas mis sur la simplicité d'installation. Je n'ai pas essayé de l'installer, mais c'est du Ruby, comme Diaspora*.
L'autre problème de cette stratégie de gros fournisseurs, c'est que le protocole risque d'être monolithique je pense. Il est difficile de faire sa propre implémentation en ne commençant par supporter que quelques fonctionnalités. Ceci dit, j'ai pas regardé en détails, c'est peut-être pas si compliqué.
Un autre problème de Tent est qu'il semble réinventer un peu trop la roue à mon avis. C'est pas absurde dans le sens où il n'existe pas vraiment de protocole aussi général que Tent, mais pour l'utilisation que je veux en faire — le web social —, c'est un peu démesuré du coup. Et surtout, on perd tout ce qui est déjà en place, tous ces flux RSS déjà existants. Il faut tout recommencer, et ça, ça compte beaucoup.
Du coup je ne pense pas l'utiliser pour la syndication de blogs. Mais c'est à mon avis un beau projet et pour d'autres utilisations, ça semble être prometteur ! C'est propre et bien documenté, équipé d'un validateur pour vérifier qu'on implémente pas ça n'importe comment, etc.
IndieWeb propose une approche assez différente et qui correspond bien plus à ce que je cherchais. L'idée de base est que, de même que chacun développe son petit moteur de blog, chacun va développer sa propre implémentation de leur suite de protocoles. Il est donc fondamentalement prévu pour gérer de nombreuses implémentations différentes.
the IndieWeb movement is different from just "everyone blog on their own site", and also different from "everyone just install and run StatusNet/Diaspora".
Chacun sert de chez lui tout le contenu qu'il produit. Il n'est donc pas question de développer une grosse implémentation de référence mais plutôt de fournir tous les outils possibles pour que chacun puisse facilement intégrer sa plateforme au système.
Il réfléchit donc en détail sur la façon de faire interagir ces différentes implémentations alors que par exemple pour Diaspora*, la fédération entre les pods est loin d'être évidente. C'est un peu moins une priorité et on considère qu'il faut commencer par faire tout marcher sur un seul pod avant de s'étendre aux autres.
IndieWeb prévoit donc réellement que chacun conserve ses propres données. Il ne cherche pas à faire un protocole entre différent réseaux sociaux mais entre les agents humains, à leur échelle.
Il doit également être prévu pour n'être que partiellement implémenté. Il doit par exemple être tout à fait possible de désactiver les commentaires sur ses publications sans que ça n'ait d'autre influence. Chacun fait les choix qu'il veut sur son implémentation. Le standard doit prévoir la phase de transition vers son utilisation complète. Il ne se place pas uniquement dans le cas idéal où tout le monde l'utilise.
Un aspect un peu différent d'IndieWeb est POSSE : Publish (on your) Own Site, Syndicate Elsewhere. L'idée est de mettre en place un mécanisme qui relaie les articles et autres statuts écrits sur son blog directement sur les sites sociaux classiques (Facebook, Twitter and co). C'est une sorte de rétro-syndication : On fait syndiquer aux réseaux sociaux son propre contenu pour ne pas priver les gens ne migrant pas à notre système de nos nouvelles.
C'est encore une fois une façon d'accepter le fait que tout le monde ne veut/peut pas utiliser ce protocole et de permettre tout de même au maximum d'accéder à son contenu.
Bon par contre c'est un peu galère à mettre en place je pense. Pour avoir jeté un œil à l'API Facebook, j'ai pas très envie d'y mettre les mains. Ça mord.
Là où l'approche d'IndieWeb trouve toute sa force, c'est que mécaniquement elle mène au développement de tout un écosystème d'outils pour aider les développeurs à l'utiliser.
Le premier est son Wiki. Y a vraiment un max de doc sur le site. Aussi bien de la doc de référence, pour connaître le fonctionnement rigoureux que les implémentations doivent avoir, qu'une doc didactique pour expliquer les choix qui ont été faits et le fonctionnement des divers protocoles. Je conseille cette page pour comparer avec les solutions d'OStatus celles d'IndieWeb qui se veulent plus simples.
On trouve ensuite des outils comme indiewebify.me permettant de faire facilement ses premiers pas dans l'univers d'IndieWeb. On y trouve des étapes clefs et divers validateurs pour vérifier qu'on a bien mis en place correctement tout ça.
Pour finir, il y a même un début de service en ligne, webmention.io, qui permet de gérer les webmentions sur une plateforme externe au site (que l'on peut bien sûr installer chez soi), sans avoir à implémenter soi-même de quoi les gérer.
Autre point capital : IndieWeb est loin d'être mort. Des évènements ont lieu régulièrement (généralement outre Atlantique par contre) et il y a du monde sur IRC !
La page des projets montre un grand nombre de moyens d'intégrer IndieWeb à des projets déjà existants type WordPress, MediaWiki, etc. La communauté a donc déjà pas mal travaillé et travaille encore (les solutions ne sont donc pas obsolètes comme celles pour OStatus).
Il y a toujours des inconvénients.
Celui qui m'embête le plus ici, c'est l'abandon de RSS/Atom. Le deuxième principe de base d'IndieWeb, « data for humans first, machines second », est clair sur ce point : les flux traditionnels (RSS/Atom) ne sont pas fait pour les humains donc ne sont pas recommandés.
Il utilise à la place le micro-format h-entry qui est une nomenclature à intégrer à la page web montrant l'article permettant à la machine de comprendre son sens. Ça évite de répéter l'info en la présentant à la fois dans les flux et les articles (risquant des différences non repérées entre les deux) mais ça rend le boulot de l'agrégateur clairement plus difficile.
Si l'humain lit généralement un article à la fois, et visualise des listes d'articles souvent limitées à dix ou vingt articles (après y a un bouton « Suivant »), la machine préfèrerait lire tout d'un coup…
IndieWeb part du principe que chacun est identifié par un nom de domaine. C'est pas forcément évident pour tout le monde, le côté Indie, mais pour la communauté de hackers du style de celle utilisant Diaspora*, c'est à mon avis ce qui est le plus adapté !
On garde tout chez soi, dans un beau flux avec des types (lien, citation, article, etc). Même les réponse, avec le type commentaire, qui est grosso-modo une webmention. Pas besoin d'inventer 36 façons de communiquer. Une seule suffit, puis on fait des sous-format après si on veut.
L'idée de base, c'est qu'on prévient le serveur que l'on mentionne lorsque l'on crée ou modifie un commentaire (et éventuellement régulièrement s'il n'a pas répondu, mais sans abuser puisque c'est sûrement qu'il supporte pas ce protocole). Puis le serveur vient voir ce qui se passe et l'interprête comme il veut : un commentaire, une simple mention ou je-ne-sais-quoi d'autre.
Simple, et fonctionnel.
Comme dit plus haut, je ne suis pas forcément favorable à l'idée du « human first, machine second ». J'aurai plutôt tendance à penser que tout part d'un flux, puis que l'on crée ensuite des interfaces. Par exemple le blog lui-même n'est qu'un lecteur de flux configuré pour lire son propre flux. Comme ça, pas de redondance.
Au final, on ne fait que révéler au grand jour une étape de la génération de la page. Il n'est pas question de savoir qui de l'homme ou de la machine doit lire le premier l'info. Ils ne la lisent pas au même moment, et comme de toutes façons pour générer la page que l'homme lira la machine doit passer par des étapes un peu brutes, ça ne mange pas de pain de les révéler.
Donc côté rédaction, on peut se contenter d'éditer un flux de données brutes, puis on code/installe l'interface qu'on veut derrière !
Voilà, j'ai fait un peu le tour de tout ce que j'ai pu trouver.
La question n'est finalement pas de savoir si tous ces projets décentralisés pour un web social doivent ou non développer un protocole. Ils le font, nécessairement. Et le fait qu'ils soient ouverts rend mécaniquement les protocoles ouverts eux aussi. Les écueils à éviter sont différents. Il faut vraiment penser décentralisé et on ne peut donc pas se contenter de reproduire les service propriétaires existants.
IndieWeb l'a bien compris en suivant la logique du « chacun chez soi ». Chacun doit pouvoir mener son petit bateau comme bon lui semble. Donc clairement, c'est IndieWeb qui m'a convaincu, même si j'en implémente pas grand chose pour le moment. Le côté Indie me plaît vraiment, tout comme son petit côté KISS. Juste un petit bémol concernant les h-entries. Je vais essayer d'implémenter le reste tout en conservant ce bon vieil RSS.
Cette liste de lien me servait d'aide mémoire lors de la rédaction de l'article. Je la laisse là même si elle est un peu en désordre. Je pense qu'elle n'est pas complètement équivalente aux liens internes de l'articles.
OStatus
Autres standards
ActivityPub
Tent.io
IndieWeb
Diaspora
Syndication
Réflexions
http://berjon.com/web-2024/ Web of Data
Standardisation
Atom