1Avec toutes leurs implications économiques, sociales et politiques, l’Internet et le Web sont avant tout des protocoles de communication, c’est-à-dire un ensemble de règles permettant à deux parties ou plus de requérir et fournir des données sur un même réseau. Cette suite de protocoles voit d’abord le jour autour de TCP/IP à la fin des années 1960 sous l’égide de la recherche états-unienne, tandis que les deux protocoles HTTP et HTTPS qui constituent l’infrastructure du Web sont développés et distribués par le Centre Européen de la Recherche Nucléaire (CERN), un organisme public de recherche. Ces deux documents sont mis à jour, avec la version 6 du Protocole Internet (IPv6) et la version 3 du Protocole de Transfert HyperTexte (HTTP/3.0).
2Pourtant, l’implémentation et l’adoption de ces protocoles ont abouti à des utilisations bien différentes des usages initialement envisagés, c’est-à-dire le partage de fichiers textes entre centres de recherche. Cette évolution est notamment documentée par Lawrence Lessig dans son ouvrage Code and Other Laws of Cyberspace (Lessig, 1999), où il identifie différentes « forces » ayant façonné l’évolution de l’Internet et du Web : des forces légales, marchandes, sociales et technologiques, des analyses notamment confirmées par Dominique Cardon (Cardon, 2019). Harsh Gupta, quant à lui, s’interroge sur le manque de représentation des continents africains, sud-américains et asiatiques lors des délibérations liées à l’implémentation de l’Encrypted Media Extensions (EME) (Gupta, 2016). Dans cet exemple précis, l’EME est un standard de communication pour des contenus protégés par une propriété intellectuelle de tradition majoritairement occidentale, et désormais établie en tant que vérité technique, plutôt qu’en tant que réglementation économico-politique. Ainsi, il semble que le protocole comporte en lui-même une capacité d’influence et de détermination du comportement de l’utilisateur.
3Les dérives de surveillance, de limitation de partage, d’automatisation du comportement et de monopole des applications issues des protocoles Internet et Web sont donc bien documentées (Lovink, 2011). Face à celles-ci s’élèvent alors plusieurs types de critiques : des critiques sémantiques, sous la forme de blogues, de livres, d’articles et de conférences ; d’autres légales, telles que les licences GNU General Public License ou Creative Commons qui garantissent une circulation non-restreinte (Elkin-Koren, 2006) ou les législations du Règlement général sur la protection des données (RGPD) ou du Digital Services Act (DSA) en Union européenne; ou encore des critiques programmatiques, telles que les bloqueurs de publicités (Gupta et Panda, 2020) ou des applications liées à des performances politiques (Critical Art Ensemble, 1996).
4Ces différentes critiques sont donc toutes des manières d’exposer autant les limitations que les alternatives à un objet donné à un moment donné, en se focalisant souvent sur un ou plusieurs points contentieux. La critique sémantique est rhétorique, et offre des stratégies discursives, quand la critique légale déploie un appareil d’arguments valides en termes législatifs. La critique programmatique promeut l’utilisation de dispositifs d’actions (dont des logiciels tels que deCSS, uBlock Origin, Consent-O-matic font partie) pour remédier aux limitations identifiées de manière pratique et computationnelle. Le type de critique sur lequel notre étude se penche est celui de la critique protocolaire.
5Un protocole est un système décrivant comment plusieurs parties peuvent échanger de l’information, en spécifiant une syntaxe, une sémantique et une synchronisation des messages échangés. Un protocole est ensuite implémenté, soit par des logiciels, ou par du matériel informatique. Partant du principe proposé par Alexander Galloway, selon lequel un protocole encode des « manières de faire » prescrites aux utilisateurs sous peine d’être exclus de la communication (Galloway, 2004), la critique protocolaire est ici envisagée comme la conception et la distribution d’infrastructures abstraites – complémentées par des implémentations concrètes – qui examinent les limitations identifiées d’une infrastructure existante.
6Une critique protocolaire est donc une proposition alternative, aussi discursive qu’opérationnelle, pour pallier les défaillances perçues des modalités existantes et prescrites de communication. Nous considérons que cette critique opère en trois temps. Premièrement, elle met au jour les limites supposées du (ou des) protocole(s) existant(s), indiquant des défauts quant à la relation entre description théorique et utilisation pratique de ces protocoles, et proposant une approche alternative. Deuxièmement, elle propose une alternative technique remédiant aux limites décrites en premier lieu, suggérant une manière de faire différente ; celle-ci est donc opérationnelle, et sa validité comme critique dépend en partie de son utilisation pratique. Troisièmement, la critique protocolaire découle de cet aspect pratique, car elle repose sur l’utilisation effective et l’existence d’applications concrètes du protocole. Une des composantes centrales de cette critique protocolaire renvoie donc à la notion de déterminisme technologique : changer une manière de faire peut changer un système socio-informationnel.
7De cette possibilité de critique protocolaire découlent plusieurs questions que nous aborderons à travers la comparaison de deux études de cas : celle du protocole IPFS (Interplanetary Filesystem) et celle du protocole SSB (Secure Scuttlebutt). Ces deux protocoles se basent tous deux sur une technique dite de « liste chaînée », qui permet d’assurer une permanence de l’information en inscrivant l’unicité d’un contenu dans une continuation de contenus existants. Ils trouvent également leur origine dans des limitations du protocole HTTP, dominant d’Internet. En revanche, nous verrons que les conceptions dominantes du genre d’information qui doit être garanti (objet ou personne) diffèrent, de même que les manières de présenter l’influence d’un protocole technique sur des postures socioculturelles.
8Pour ces deux cas, il s’agira d’examiner les capacités expressives des protocoles numériques en tant que sous-ensembles des systèmes computationnels, à l’appui notamment sur des travaux d’Ian Bogost en rhétorique procédurale. Nous étudierons également les possibilités de déterminisme technologique en comparant les usages abstraits sous-tendus par le protocole avec ses implémentations concrètes par des acteurs situés dans des contextes socio-économiques spécifiques (Bogost, 2007). Tandis que Bogost se focalise sur les discours émanant de systèmes interactifs pour l’utilisateur final, nous nous concentrons ici sur des discours suggérés par une infrastructure de communication, donc relativement invisibles à l’utilisateur final. Ces infrastructures de communication reposant sur une base massive d’utilisateurs, nous nous appuyons également sur les travaux de Francesca Musiani, et notamment son analyse des compromis apparaissant entre promesse décentralisée et réalité centralisée (Musiani, 2017).
9Cela nous amènera enfin à considérer à quel point ces protocoles amènent à proposer de nouveaux imaginaires, dans la mesure où il s’agit de considérer l’échange d’information sur des réseaux numériques, et plus spécifiquement quant aux façons de considérer techniquement l’objet, l’individu, l’espace et le temps, et comment ces imaginaires se concrétisent dans la pratique. Ainsi, cet article s’inscrit dans le champ des STS (études des sciences et techniques), et plus particulièrement dans celui des software studies, cherchant à expliciter les effets et influences socioculturelles des logiciels (Fuller, 2003).
10Comment se constitue une critique protocolaire en pratique ? Quelle est la place de la technique au sein de cette critique ? Comment les environnements, documents et actions sociales, économiques et techniques composant un protocole reflètent-ils des conceptions plus larges de manières de communiquer ? Afin d’élucider ces questions, nous procéderons à une analyse du protocole et du discours des deux écosystèmes d’IPFS et SSB, confrontant langage machine à celui de l’humain. Cette analyse consistera à identifier les éléments techniques et discursifs décrivant un protocole : le normatif (le protocole en lui-même), le prescriptif (les usages imaginés par les concepteurs), le descriptif (la représentation du projet à travers sites Web, entretiens dans la presse et promotion individuelle) ou encore l’argumentatif et le participatif (discussions entre concepteurs et utilisateurs autour des intentions et usages des protocoles). Cette analyse du protocole inclut donc la technique et l’humain.
11Le cadre d’interprétation de ces documents sera ici celui d’une analyse critique du discours, telle qu’elle est développée par Dianna Mullet, en partant de l’hypothèse que les différentes facettes du discours d’une même organisation permettent alors de mettre au jour une certaine « cosmogonie » suggérée avec pour fondement un protocole comme élément sociotechnique (Mullet, 2018). Nous considérons que le choix méthodologique est ici approprié, puisque nos objets d’étude sont des objets communicationnels multiformes, entrelaçant discours techniques, politiques et sociaux, aussi bien dirigés vers une communauté interne que vers un plus grand public. L’analyse des présupposés, des champs lexicaux et des adresses des auteurs de ces discours, considérés dans la dimension pragmatique de l’adoption de ces protocoles, nous permettra de constituer les tenants et les aboutissants de la critique protocolaire déployée par IPFS et SSB.
12Cette approche d’analyse critique du discours se combine à une analyse comparative pour deux raisons. D’une part, il s’agit de mettre en exergue les éléments communs au déploiement d’un protocole (pendant technique, communicationnel et social) et de voir comment la manifestation de ces éléments peut varier selon les présupposés des concepteurs, alors qu’ils restent très semblables au niveau technique. D’autre part, il s’agit de considérer l’implication d’un même but (communication d’une information d’un émetteur à un récepteur), avec un même principe technique (chaîne d’information cryptographiée) dans des environnements sociaux différents. Nous analyserons donc à quel point ce but et ce moyen technique résultent ou non en des conséquences pratiques différentes, notamment en matière de type et de nombres d’applications développées.
13Nous approcherons ce sujet en deux temps. Tout d’abord, nous examinerons les visions paradigmatiques des deux projets, en commençant par IPFS, suivi de SSB. Ces analyses se feront de manière identique, à travers la description du protocole, puis l’identification des discours mis en place autour de celui-ci, pour enfin conclure sur la mise en pratique et les possibles limites de la confrontation au réel que chaque protocole présente à travers ses applications. Ensuite, nous approfondirons notre comparaison en considérant la composante du déterminisme et des ontologies telles qu’elles se manifestent dans chaque protocole.
- 1 Ce content-addressing est une manière de faire référence à une entité, non pas par l’adresse de sa (...)
14L’InterPlanetary File System, ou système de fichiers interplanétaires, est un protocole de distribution d’information tenant pour primordiale la disponibilité permanente de tout objet, et offrant donc une organisation technique dans cette optique. La première version du protocole est spécifiée en 2014 par Juan Benet, sous la forme d’un white paper, document de travail décrivant un problème particulier et envisageant certaines solutions (Benet, 2014). Ce document est fondateur de l’approche d’IPFS et révèle que le projet lui-même est constitué d’un amalgame de protocoles existants, combinés afin de réguler la création et la vérification d’identité de chaque pair du réseau, la connexion et la localisation de pairs au sein du réseau et l’échange d’information entre pairs. Il s’agit également de réguler la représentation des objets hébergés par les pairs, intégrant étroitement les questions de versions et de nominations, dans ce qui est considéré comme un des piliers de l’approche IPFS, le content-addressing1. Bien que sa nature décentralisée rende difficile l’estimation de l’étendue exacte de son utilisation, le réseau IPFS était constitué d’environ 40 000 nœuds en 2020 (Henningsen et al., 2020).
15IPFS mobilise des technologies existantes, puisant dans divers domaines de la cryptographie et de la théorie des graphes, pour permettre la disponibilité à tout un chacun d’un seul ensemble globalisé de fichiers. D’après les termes de Juan Benet,
- 2 Traduction de l’auteur à partir de Benet (2014) : « IPFS is similar to the Web, but IPFS could be s (...)
IPFS est similaire au Web, mais peut être vu comme un seul essaim BitTorrent, échangeant des objets au sein d’un dépôt Git. En d’autres termes, IPFS fournit un modèle de stockage en bloc à haut débit, avec des hyperliens adressés au contenu. Cela forme un Merkle DAG généralisé, une structure de données sur laquelle on peut construire des systèmes de fichiers versionnés, des chaînes de blocs et même un Web permanent 2. (Benet, 2014)
- 3 « Un web où [...] la publication d’informations précieuses n’impose pas leur hébergement à l’éditeu (...)
16Ce que nous notons a priori, c’est donc un discours qui fait la place belle à cet enchevêtrement de technologies, se présentant comme similaire au Web actuel, mais aussi comme sa version améliorée, car permanente. Le Web est en effet considéré par Benet comme éphémère et temporel, l’antithèse d’IPFS – le Web permanent et l’accessibilité universelle de toute information3. Parmi ces technologies figurent une DHT, Distributed Hash Table, un système d’incitation de partage BitSwap et une représentation d’objets à travers un graphe acyclique de Merkle, eux-mêmes accessibles à travers une infrastructure de clés publiques. Ces innovations techniques se conjuguent pour réaliser la vision d’un protocole assurant un partage de l’information supposé global et permanent, intégré au système de fichiers « normal » de l’utilisateur.
- 4 Bien qu’également distribué, DNS présente des aspects centralisés et hiérarchiques, notamment par l (...)
17L’infrastructure de clé publique permet avant tout d’adresser les objets présents au sein du réseau par leur contenu plutôt que par leur adresse – un choix sur lequel nous reviendrons – afin de pallier la disparition du contenu à l’adresse spécifiée ; un phénomène manifesté sous la forme de la familière « erreur 404 » par le protocole HTTP. Les identifiants uniques de chaque objet sont ensuite répertoriés, de manière distributive, sur cette DHT, de sorte que chacun des membres du réseau héberge la liste des objets disponibles, au moyen d’une liste chaînée. Cette façon de faire se pose en réponse au système DNS d’Internet, qui fonctionne, lui, de manière relativement plus centralisée4. Le transfert des objets se fait ensuite par le mécanisme BitSwap, qui récompense les membres du réseau partageant le plus de contenus, et pénalisant ceux qui ne le font pas, à travers un système de dettes et de crédits. Enfin, la représentation de ces objets (qui peuvent être un fragment de texte, un fichier MP3, une section d’image, etc.) est techniquement immuable. Cela signifie que chaque objet, une fois inscrit au sein du réseau, ne peut être supprimé que par son auteur et ne disparaît qu’une fois que tous les membres du réseau ont cessé de l’héberger. Si une version subséquente de cet objet est ajoutée sur le réseau, il s’agit d’un tout nouvel objet doté d’une nouvelle adresse et ajouté en supplément de l’objet précédent.
18Benet établit donc cette permanence, c’est-à-dire la disponibilité de chaque objet auprès de tout membre du réseau, aussi longtemps que les membres décident de le conserver. Cela est rendu possible par une liaison de l’objet avec des mécanismes économiques de partage, lesquels sont basés sur des dynamiques de marché, afin de pallier ces myriades d’« erreurs 404 » du Web contemporain.
19Le premier tenant de la critique protocolaire déployée par IPFS se focalise donc sur le caractère éphémère du protocole HTTP, tel qu’il finit par impliquer une dépendance à une architecture client-serveur. Face à cette limite, une solution technique est d’abord présentée et repose notamment sur le concept d’une liste chaînée. Cette critique va ensuite être étayée par des discours des créateurs d’IPFS et des applications de leurs utilisateurs.
- 5 Présentant une vision déterministe de la technologie, notamment en considérant que la technologie d (...)
20Les raisons pour lesquelles IPFS cherche à garantir un accès universel et atemporel à tout utilisateur reposent sur une critique de l’état actuel de l’Internet, et plus particulièrement du concept d’architecture centralisée, tel que Benet l’explique lors d’une intervention publique en 2015 à Stanford (stanfordonline, 2015), puis en 2019 à IPFS Camp. Dans la manière dont IPFS se présente, une dimension téléologique indéniable transparaît : lors de la première conférence IPFS, l’IPFS s’inscrit dans la directe lignée des 10 millions d’années d’existence de l’espèce humaine5. Pour compléter cette approche d’une évolution linéaire, il pose alors le Web actuel comme inefficient en matière de coût par bande passante, du fait de son architecture client/serveur centralisée. Cette architecture centralisée est considérée par Benet et Protocol Labs comme rendant un document éphémère dès lors que ce dernier n’est plus hébergé par le serveur le fournissant. Enfin, il pose le développement économique de l’Internet et du Web aujourd’hui en tant que facteur d’une centralisation et d’un monopole de l’accès à l’information, considérés comme un obstacle à l’innovation.
21Déjà, nous voyons que certains aspects de l’argumentaire déployé par Benet sont des critiques technologiques concrètes (c’est-à-dire des questions de bande passante et de pérennité du contenu en ligne), mais les deux derniers (téléologie et innovation) sont plus flous et plus difficilement attribuables à une technologie plutôt qu’à un ensemble de décisions socio-économiques, telles qu’identifiées par Lessig (Lessig, 1999). Néanmoins, la vision du monde proposée par IPFS est celle d’un réseau de connexions perpétuel et quasi instantané. Puisque chaque utilisateur est considéré responsable à titre égal de la mise à disposition de l’information du réseau, IPFS doit permettre à chacun d’accéder à tout, en permanence, là où l’Internet établit une relation de hiérarchie entre serveur et client.
22Le discours d’IPFS établit donc une approche solidaire de la distribution d’information, faisant la part belle au contenu plutôt qu’à l’adresse de ce contenu. La réponse technologique apportée aux limites d’Internet mentionnées plus haut – lenteur et disparition des objets – est radicalement opposée. Il s’agit désormais de faire en sorte que chaque objet mis à disposition sur le réseau puisse y rester tant qu’un pair a minima décide de le fournir au réseau. Cette emphase revêt un caractère particulier lorsque Benet compare IPFS aux ambitions originelles du Web, via lequel Tim Berners-Lee imagine un réseau de pairs. Et pourtant, nulle part dans les spécifications HTTP 1.0 et 1.1 ne figure la mention de pairs ou d’échange réciproque d’information. Cela semble alors être une sorte de révisionnisme historique, peut-être influencé par le projet plus récent du créateur du Web, Solid, lequel propose un moyen de décentraliser des applications sociales en se basant sur le concept de Linked Data.
23IPFS aborde également le problème d’incitation à la distribution d’un contenu qui n’est ni celui que l’on possède, ni celui que l’on désire. Sous le régime protocolaire du Web, le serveur est toujours considéré comme ayant un intérêt à distribuer son propre contenu, tandis que le client sait qu’il s’adresse à un serveur spécifique afin de récupérer un contenu spécifique. Un réseau distribué doit, lui, reposer sur le partage constant d’information, y compris une information qui n’est pas immédiatement pertinente aux utilisateurs les hébergeant – et donc sans incitation personnelle intrinsèque. En universalisant les contenus, on court alors le risque de dépersonnaliser le rapport au contenu et sa responsabilité.
24Afin de compenser cette contrainte, IPFS propose BitSwap, une manière d’accumuler du crédit ou du débit en tant que réputation, au sein d’une logique de libre-échange (marketplace, selon les termes de la documentation – Protocol Labs, s. d.), et dont Benet lui-même reconnaît qu’elle serait particulièrement adaptée à une cryptomonnaie. Celle-ci sera développée sous la forme d’un FileCoin au même moment qu’IPFS. La composante principale du partage de contenu est donc d’inspiration financière, puisqu’un système de troc tel que BitTorrent est considéré comme inapproprié dès lors qu’il s’agit d’acquérir une multiplicité de fichiers, plutôt qu’un seul (Protocol Labs, 2014).
- 6 39 Petaoctets pour un peu plus de 818 000 objets distincts, soit un espace dédié moyen de 53 Gigao (...)
25Le protocole IPFS vise ainsi la permanence du contenu hébergé sur la plateforme indépendamment du propriétaire, et ces créateurs considèrent que cette fonctionnalité est intrinsèquement désirable, malgré les risques encourus par la permanence de contenus illégaux. Techniquement, une telle permanence peut être accomplie par le biais d’incitation financière à travers une cryptomonnaie. Ces modalités diffèrent de celles appliquées par HTTP, qui engagent la responsabilité individuelle de l’hébergeur, ou de celles de BitTorrent qui ne se focalisent que sur un seul fichier, sur un traqueur d’information centralisé et sur la réciprocité de la distribution d’information. Ce système de stockage de l’information à travers FileCoin propose alors un espace de stockage relativement démesuré6. Si le protocole d’incitation marche, dans le sens où il y a bien un vaste espace de mémoire mis à disposition, c’est alors l’utilisation de ce protocole qui va nous intéresser, soit ce qui est fait de cet espace de mémoire. En effet, comme le dit Tony Willenber dans sa présentation d’IPFS en 2018 :
- 7 Traduction de l’auteur à partir de : « The IPFS is not just a theoretical or academic experiment. I (...)
L'IPFS n'est pas une simple expérience théorique ou académique. Il s’agit d'un système logiciel fonctionnel (bien qu'encore en phase alpha) qui peut être téléchargé et mis en service dès maintenant7. (Willenberg, 2018)
26Un des aspects de la critique protocolaire est donc bien d’être opérationnelle, c’est-à-dire de pouvoir se manifester directement dans des produits et des usages. En plus des discours sociaux présentant la vision originelle du protocole et les discours techniques assurant cette opérationnalité, la cohérence ou la discordance entre théorie et pratique se révèle dans les applications et les cas d’usage.
27La documentation du site IPFS propose une liste exhaustive de cas d’usage, aussi bien potentiels qu’effectifs. On y retrouve notamment le partage de fichiers par un individu, la collaboration en temps réel sur le même fichier ou encore l’utilisation de la messagerie. Cependant, la principale raison d’être d’IPFS est bien celle d’un protocole, c’est-à-dire en tant qu’infrastructure afin d’héberger, gérer et distribuer du contenu à travers le monde ; par exemple, Netflix étudiait en 2021 la possibilité de synchroniser certains de ces systèmes à l’échelle globale via IPFS (Protocol Labs, 2020). Plus particulièrement, IPFS concentre son champ d’application de l’IPFS à celui des dApps, ou applications décentralisées traditionnellement basées sur des systèmes de chaîne de blocs, ce qui annonce une certaine contingence de l’écosystème des chaînes de blocs avec celui d’IPFS.
28Cette vision d’un monde informationnel qui serait mieux si toute information était permanente se reflète dans plusieurs cas de figure mis en avant par Protocol Labs, la structure encadrant le développement d’IPFS. Dès 2014, Juan Benet présente le travail de l’organisation Internet Archive comme étant essentiel pour la sauvegarde des connaissances humaines à l’ère informatique, et suggère donc d’utiliser IPFS afin de créer une copie des archives de l’Internet Archive. Un projet est donc ouvert sur GitHub où les développeurs et développeuses discutent de l’implémentation en 2015, avant qu’il soit abandonné en 2017, au moment où la question de qui assurera l’hébergement de cette archive se pose. Théoriquement, la communauté IPFS devait assurer l’hébergement, mais en réalité cette responsabilité est endossée par les employés de Protocol Labs, ce qui engendre un retour à un hébergement centralisé.
29En 2017, une autre application du protocole se déroule lors de la copie du site turc de Wikipedia sur IPFS, alors que la version HTTP du même site est censurée par le gouvernement Erdoğan. Dans ce cas précis, il s’agit d’une initiative de Protocol Labs. Si l’annonce sur leur blogue présente un dispositif pair au pair et décentralisé, l’organisation est en réalité la principale à héberger ce contenu, comme le montrent leurs demandes subséquentes de cohébergement par des tiers (The IPFS Team, 2017).
- 8 Traduction de l’auteur à partir de : « Every single file that could exist on IPFS has the potential (...)
30La question de la censure se pose à l’inverse pour le reste du contenu hébergé sur IPFS. En effet, le protocole se base sur l’immutabilité des contenus, ce qui suggère la suppression de contenu illégal. Un problème compliqué et pourtant intrinsèque à toute information publique résumé sur le dépôt GitHub du projet par l’utilisateur geebotron, à propos de la modification des fichiers disponibles : « Chaque fichier existant sur IPFS est susceptible d’offenser quelqu’un8 » (Geebotron, 2016).
31En effet, la conception d’un protocole sur la permanence d’une information se heurte de manière frontale à la question de la censure et de la propriété intellectuelle. Face à la législation réglementant la propriété intellectuelle, la réponse d’IPFS est donc de proposer un aspect technique additionnel (c’est-à-dire une whitelist) pour déterminer l’utilisation des fichiers. La présentation de cette décision technique est ensuite présentée comme clôturant le débat :
- 9 Traduction de l’auteur à partir de : « It is not my intention to start a political philosophy discu (...)
Je n’ai pas l’intention d’entamer une discussion de philosophie politique, mais plutôt d’articuler l’espace de conception et les raisons pour lesquelles IPFS s’inscrit dans un ensemble particulier de décisions. Si la question s’éloigne du sujet, je la fermerai ou la renommerai9. (Benet, 2017)
32Enfin, la question de l’applicabilité du protocole BitSwap se retrouve dans le développement de services d’entreprise centralisés10 :
- 11 Traduction de l’auteur à partir de : « If you don’t pin your content to IPFS, it goes bye-bye. And (...)
Si vous n’épinglez pas votre contenu sur IPFS, il disparaît. Et si le serveur qui épingle vos ressources est mis hors ligne et que personne d’autre ne l’épingle, il disparaît à jamais. C’est pourquoi un marché s’est ouvert pour des services tels que Piñata, qui visent à être des services d’épinglage permanents. Vous vous retrouvez donc toujours avec un cadre commercial centralisé même si la technologie elle-même est décentralisée, en ce sens que si vous n’avez pas les moyens de fournir votre propre infrastructure distribuée, vous devrez payer quelqu’un qui le fera11. (Sieradski, 2022)
33En fin de compte, dans ce développement, nous percevons que la présentation faite par IPFS de leur critique protocolaire –limitations de protocole existant, aspect technique d’une alternative, discours justificatifs et applications – trouve elle-même une limite, puisqu’elle est centralisée au niveau économique plus qu’au niveau technique et qu’elle repose notamment sur la responsabilité d’hébergement d’entités économiques (telles que Protocol Labs ou Piñata). L’insertion d’un facteur économique lors de l’application d’un protocole technique contrecarre donc un discours de décentralisation universelle. Il semble alors que cette pluralité des composantes de la critique déjoue la conception de déterminisme technologique de Benet et Protocol Labs.
34SSB (ou Secure Scuttlebutt) est un protocole de communication et de distribution de fichiers créé par Dominic Tarr en 2014, la même année qu’IPFS. Alors que Juan Benet est un développeur issu de la Silicon Valley, Tarr est un navigateur néo-zélandais qui considère la disponibilité hors-ligne, ainsi que la nature sémantique des objets comme messages, comme fondation du protocole sous le terme de local-first. Les membres de l’organisation autour de SSB (le Secure Scuttlebutt Consortium) estiment fin 2019 le nombre de pairs sur le réseau à 10 000 au moins (Fiscella, 2018).
- 12 Voir la section « Why don’t I see all torrents in a channel? » sur le Tribler Wiki, consultée le 2 (...)
35SSB se démarquera tout d’abord par son positionnement dans la famille des gossip protocols, des protocoles de ragots. Ceux-ci sont basés sur des modélisations de la distribution des rumeurs ou des épidémies – essentiellement une sélection plus ou moins hasardeuse des pairs à portée de communication auprès desquels l’information se propage. Par exemple, dans le cas de Tribler12, un protocole de partage de fichier sur le modèle de BitTorrent, il s’agit de diffuser de l’information en s’appuyant sur ses voisins immédiats, plutôt que sur une instance centrale. L’approche est donc posée : il s’agit de définir un protocole technique comme simulation de phénomènes naturels, partant du principe que l’information portera des schémas sociaux (Web3 Foundation, 2019).
36SSB affiche comme axiome de départ la disponibilité hors-ligne : le protocole et ses applications doivent être utilisables sans connexion à l’Internet. Ainsi, tout stockage ou accès de données se fait uniquement de manière locale, et la mise à jour, ou synchronisation, de ces données sera effectuée lorsque se réalisera une connexion à un autre membre du réseau. SSB réplique, de manière protocolaire, l’expérience d’une vie en mer, expérience locale s’il en est, en ne permettant la synchronisation entre deux pairs que si ceux-ci sont connectés au même réseau local.
- 13 Ceux-ci existent sous forme de pub, jeu de mots entre « bar » et « publiciste ».
37SSB est également un protocole décentralisé de partage de données. Il fonctionne par pairs qui s’assignent une signature cryptographique, afin de constituer leur identité – si la clé est perdue, l’accès au compte l’est aussi –, corrélat de la responsabilité de l’utilisateur sur ses propres données. En revanche, la manière dont les pairs se découvrent ne se situe que lorsque ces derniers émettent des signaux jusqu’à ce qu’ils soient reçus par un autre pair. Une fois que la connexion est établie entre deux pairs, ces derniers peuvent effectuer un échange de messages ou de fichiers. Il est également possible de se connecter à un pair à travers un portail Internet. SSB n’est donc pas directement une critique protocolaire cherchant à remplacer HTTP, mais plutôt à complémenter son aspect technique13. La critique présentée par SSB est davantage orientée vers l’injonction à être constamment « en-ligne », plutôt que considérer le « hors-ligne » comme approche par défaut.
38Enfin, les messages eux-mêmes sont basés sur une conception de la liste chaînée, elle-même similaire au versionnage des fichiers d’IPFS. Nous retrouvons ici une similarité technique qui, mise face à la différence de discours et d’application, nous permet de remettre en question le présupposé du déterminisme technologique sous-jacent tenant pour point de départ que chaque critique protocolaire est une description technologique. Pour SSB, chaque message est relié cryptographiquement au message précédent et au message suivant, formant donc ce que les développeurs n’appellent pas une chain (chaîne), mais un feed (flux). De cette manière, les objets ne sont plus uniquement considérés comme étant des entités flottantes, uniques, mais bien des entités relationnelles qui tirent leur nature sémantique de leur contexte, lequel est avant tout social. Ici, la technique sous-jacente est la même, mais leur développement et leur présentation suggèrent des manières de communiquer bien différentes.
39SSB met donc en avant combien leur protocole se base sur des phénomènes naturels et présente la décentralisation non pas comme vouée à l’étendue universelle, mais à la responsabilité locale. Cette vocation est inscrite dans le protocole même par une asynchronie de l’échange de messages, par une relation cryptographique et par un stockage local, et donc personnel, de toutes données. Il nous faut désormais étudier comment les discours autour de SSB renforcent cette préférence pour une approche sociale plutôt qu’une approche technique.
40Le discours de SSB, et notamment la manière dont est présenté le protocole, constitue un miroir intéressant d’IPFS. Plutôt qu’une démonstration technique, il s’agit plutôt de prendre un cas d’étude – une relation amoureuse – pour montrer comment SSB privilégie une conception intime de la communication, plutôt qu’une conception technique (Mandeville, 2022a). À travers une vidéo introductive montrant comment SSB peut exister en arrière-plan d’une histoire romantique se développe un discours bien différent de celui d’IPFS. Faute d’une présentation sous la forme d’un article académique publié de manière autonome sur un site de recherche scientifique, la page de documentation du site de SSB accueille le visiteur avec le message suivant :
Scuttlebutt vise à harmoniser quatre perspectives de la vie : L’environnement reflétant la technologie reflétant la communauté reflétant la société.
- 14 Traduction de l’auteur à partir de : « Scuttlebutt aims to harmonize four perspectives of life: Env (...)
Nous reconnaissons les environnements naturel, virtuel et social. Notre responsabilité est de reconnaître quelles ressources sont abondantes, lesquelles sont suffisantes, et de nous adapter en conséquence grâce à l’efficacité14.
41Si une documentation plus poussée et rigoureusement technique ainsi qu’un article publié dans les annales de la conférence Information-Centric Networking de l’ACM en 2019 (Tarr et al., 2019) présentent par ailleurs le protocole SSB, il est intéressant de s’arrêter sur ce premier message d’accueil. Au vu de la place attribuée au terme « technologie », coincé entre « environnement » et « communauté », la position se présente comme étant bien plus relationnelle que le protocole hypermédia conçu pour préserver et développer le savoir de l’humanité d’IPFS, holistique et donc autosuffisant.
42Nous pouvons identifier cette prise de parole par une emphase sur la relation entre deux agents, et non sur celle d’un réseau entier. Déjà, la première version du protocole SSB s’appuie sur un article de Tarr considérant le problème d’authentification et d’échange d’information entre deux pairs15, plutôt que sur la représentation d’une information. De cette manière, si IPFS et SSB considèrent tous deux la mise en place d’un système de communication, IPFS se focalise sur ce qui est communiqué (messages/objets comme membres d’un graphe acyclique dirigé), tandis que SSB se focalise sur les individus voulant échanger un message (signatures cryptographiques synchronisant leurs contenus).
- 16 Voir notamment le commentaire d’Ian Bogost sur le sujet, consulté le 10 février 2022 l’URL : https: (...)
43En tant que critique, c’est un double présupposé fondamental d’un internet contemporain que SSB critique, à savoir l’idée que toute information, et donc tout membre du réseau qui héberge ou demande une information, doit être disponible en permanence et à l’échelle globale. Tarr et ses collaborateurs considèrent que ce présupposé a notamment des répercussions sur l’autonomie des membres du réseau par rapport à l’influence de monopoles économiques. Ils veulent donc redonner une prépondérance à cette autonomie (ce local-first mentionné plus haut) par le biais d’une propagation par défaut sur un réseau local plutôt que par réseau global16.
- 17 Traduction de l’auteur à partir de : « Dev discussions and tutorials are an essential part of our c (...)
44Comme le développe Zach Mandeville dans son essai The Future Will be Technical financé par SSB, on note également dans l’écosystème SSB une croyance dans le développement des technologies pour améliorer le futur, mais également une prise en compte de la technique en tant qu’élément de la culture : « Les discussions sur le développement et les tutoriels sont une partie essentielle de notre communauté et ne doivent pas être occultées ou minimisées17. » (Mandeville, 2022b).
45La technique est ici un élément fortement culturel et l’adhésion à un protocole revient à partager une vision du monde et à un imaginaire collectif (Hall, 1997). Il semble alors que le champ d’application évolue aussi. De manière symétrique à la perception d’IPFS, qui veut un protocole touchant l’univers entier, SSB s’adresse au Scuttleverse. On peut considérer ce dernier comme un cosmos découlant d’un lien technique basé sur un lien social. Par exemple, la dénomination des groupes d’utilisateurs comme tribus chez SSB rappellent les travaux de Yuk Hui sur la cosmotechnique, cet aspect des systèmes techniques existant au sein de cosmos différents (dans le sens de cultures différentes) (Hui, 2016). Selon Hui, la cosmotechnique suggère qu’il y a autant de cultures que de manières de penser leur relation à la technologie. Ces diverses façons de penser impliquent de facto de nouvelles manières de faire, dont les idées et présentations de SSB et IPFS sont deux exemples. Une même technologie – ici, la liste chaînée – peut donc être pensée différemment selon les cultures au sein desquelles elle se déploie, pondérant ainsi ce qui peut être fait avec cette technologie.
- 18 Voir le visuel sur le site officiel de Secure ScuttleButt, consulté le 20 février 2022, URL : https (...)
- 19 Voir aussi le site hébergeant les informations sur le camp, consulté le 13 février 2022, URL : http (...)
- 20 La version SSB se trouve à l’adresse URL suivante : https://two.camp.scuttlebutt.nz, consultée le 1 (...)
46Cette étroite connexion entre technologie et culture, tout comme cette considération du protocole comme artefact relationnel, se manifeste dans la documentation du protocole. Celle-ci oscille entre rigueur technique et clins d’œil espiègles en proposant une présentation de la documentation sous la forme d’une carte au trésor, ou encore la représentation de l’échange de clés cryptographiées comme relation érotique18. Cette dynamique relationnelle se traduit également dans la manière dont ces protocoles font vivre leur communauté, notamment au travers d’événements visant le community-building. Pour les deux protocoles, cela se manifeste sous la forme de camps. Le IPFS Camp consiste à rencontrer des pionniers, prêts à hacker pendant cinq jours, le tout commandité par des entreprises dont IPFS est le fonds de commerce19. Quant au Scuttlebutt Camp, il s’agit d’un rassemblement sans fin déterminée ni agenda particulier20. Même si la pandémie de la COVID-19 a empêché la tenue de ces événements, nous voyons toujours la différence entre IPFS et SSB en matière de conception de ce qu’est un contenu, un individu, un but et un procédé, mais au sein d’une similarité organisationnelle.
47SSB et IPFS proposent directement une implémentation des clients, c’est-à-dire de logiciels manifestant les protocoles sous leur forme concrète et active, écrits dans des langages particuliers pour des plateformes particulières. Pour autant, les domaines d’application de SSB sont beaucoup plus concentrés que ceux d’IPFS. Tandis qu’IPFS, fidèle à sa vision d’expansion globale, privilégie la quantité relative d’applications possibles (plus de 55 listées sur le site d’IPFS21), SSB se concentre sur la qualité en ne listant qu’une application principale suggérée : un réseau social, soit un échange de messages entre personnes22.
48Cette visée de l’application est clairement établie dès les premières pages de « comment rejoindre SSB ». Sans entrer dans les détails du protocole, les différentes applications pour rejoindre le Scuttleverse sont proposées directement, avec en second plan le genre d’applications qui découlent de l’implémentation d’un protocole techniquement plus large que ses visées sociales, comme le contrôle de version de code, la maintenance et distribution de bibliothèques de code, allant même jusqu’à rejoindre le rôle d’IPFS par le biais de SSB Drive23, un système de fichiers basé sur SSB.
49Particulièrement, la fin de l’introduction à SSB consiste autant en un type différent de protocole. Une fois que l’installation et l’inscription sont réalisées, le discours de SSB mentionne non pas le protocole technique, mais un protocole social désigné par le terme « tradition », tradition impliquant notamment de se présenter sur le canal #new-people, mettant une fois de plus en avant leur volonté de prioriser l’aspect social rendu possible par un protocole, plutôt qu’existant dans une stricte isolation technique.
50Bien que IPFS et SSB soient similaires dans leur intention pratique de développer un protocole permettant la distribution décentralisée et cryptographiée d’information entre pairs d’un réseau par le biais d’un même système technique, le fondement théorique de ces deux projets se tient néanmoins en porte-à-faux. Nous explorons ici cette tension entre similarité technologique et différences culturelles, entre déterminisme et imagination.
51Dès la fin des années 1990, Manuel Castells (2009) estimait que la société connectée dont les conditions matérielles de réalisation comprennent TCP/IP et HTTP a fait entrer une grande partie du monde dans une ère d’espaces de flux et de temps atemporel (space of flows and timeless time). Par des moyens technologiques, l’espace de cette société permet de réaliser une simultanéité sans pour autant demander une contiguïté physique, accompagnée d’une temporalité qui, tendant à l’immédiateté, semble alors disparaître dans l’arrière-plan des flux d’information.
- 24 Excepté pour ce qui est des téléchargements et des caches.
52D’après Castells, au début des années 1990, même si l’espace se transforme du matériel au dématérialisé, l’interopérabilité des lieux de décision des centres d’opérations économiques ne change pour autant pas leur statut de centres, de nœuds principaux par lesquels doivent transiter les nœuds secondaires afin de communiquer. Cette situation de réseau centralisé est elle-même une conséquence tant de dynamiques économiques et de services marchands, que d’un protocole (HTTP) impliquant la limitation de la duplication de l’information hébergée24.
53C’est cette centralisation qui est le premier objet des critiques des deux protocoles étudiés ici. Ceux-ci nous montrent cependant qu’une telle situation de simultanéité peut, par ces mêmes moyens techniques, être repensée de diverses manières, et notamment en prenant en compte les communautés imaginées en tant qu’utilisatrices de ces protocoles. Les priorités discursives des mainteneurs des protocoles considèrent ainsi de manière plus holistique la conception d’un protocole, son implémentation et ses applications comme éléments indissociables d’un même discours, au-delà d’une simple spécification technique.
54D’une part, IPFS suggère que le réseau peut pousser encore plus loin cette dynamique, se basant sur une interprétation particulière de la vision originelle de Tim Berners-Lee, pour aboutir à un dispositif où le réseau est intégré directement dans chaque poste via un système de fichier. De cette manière sont contournés les aspects négatifs de la centralisation, notamment la disparition de contenus. La lenteur de téléchargement des données sera résolue par un système d’identification et d’accès à ces contenus.
55D’autre part, SSB approche le problème sous l’angle opposé. Il s’agit de présenter une critique pratique de l’impératif d’être connecté en permanence, imposé par de larges conglomérats économiques, et qui obscure alors le fait que la synchronisation « authentique » entre individus est toujours repoussée un peu plus, créant un désir d’immédiateté accru, un phénomène proche de celui décrit par Dominic Pettman sous le nom de will-to-synchronize (2015). SSB propose une vision du monde où l’espace et le temps de chacun des membres du réseau ne sont pas nécessairement identiques, et où la proximité physique est une condition suffisante à l’échange d’information.
56Dès lors, IPFS et SBB partagent des positions similaires sur la centralisation, mais opposées sur la mise à disposition. IPFS recherche une quasi-universalité (ou, selon leurs termes, une inter-planétarité), quand SSB recherche l’implémentation locale technique et culturelle, en priorité. Néanmoins, ces deux protocoles, ces deux visions divergentes se basent sur des algorithmes extrêmement similaires, nous permettant alors de nous poser la question du déterminisme technologique.
57Les deux cas étudiés ici comportent des protocoles basés sur le principe de l’append-only log, c’est-à-dire une suite d’entités qui ne peut que s’accroître, et dont les entités précédentes dans la liste sont immuables. Ces listes immuables le sont rendues par l’utilisation de techniques cryptographiques utilisant le concept de liste chaînée. Et pourtant, un protocole est un objet sociotechnique qui s’applique également à un problem domain, le domaine d’application de l’algorithme au-delà de son aspect strictement technologique et computationnel. C’est ce domaine d’application qui entraîne la critique protocolaire au-delà du strictement technique. La principale différence n’est donc pas la technologie, mais le choix du domaine d’application. D’une part, IPFS applique son protocole au contenu. Ce contenu possède une relation à d’autres contenus (fichiers ou dossiers), mais surtout une identité, établissant l’immutabilité et la pérennité du contenu en question et disséminant cette information à travers des mécanismes de marché financier, passant donc outre la responsabilité individuelle. À l’opposé, SSB utilise ces outils techniques pour définir l’individu. Associé à chaque nœud du réseau, il est propriétaire de l’information, laquelle est dès lors socialisée. En effet, l’information prend part à une chaîne d’informations basées sur un graphe social, d’individus concrets qui disséminent l’information par proximité physique, ou par proximité sociale via les pubs.
58Lorsqu’il s’agit de développer des applications pour le protocole, la communauté d’IPFS se retrouve toujours à considérer une approche globale, au risque d’être centralisée. Nous pouvons notamment localiser cette tension dans un des exemples donnés par les membres d’IPFS pour illustrer la résilience du protocole face à la censure. Lors du référendum catalan de 2017, le site dédié à l’enregistrement des électeurs a été censuré par les autorités madrilènes et a été mis en ligne sur IPFS en tant qu’alternative permanente d’un contenu victime de censure. Pourtant, comme le note l’utilisateur Akira :
- 25 Traduction de l’auteur à partir de: « Unfortunately, most users back then used the HTTP gateway gat (...)
Malheureusement, la plupart des utilisateurs de l’époque utilisaient la passerelle HTTP gateway.ipfs.io 6, qui était également censurée, mais les utilisateurs plus avisés évitaient la censure en utilisant un démon IPFS normal et en installant la simple extension de navigateur IPFS Companion. IPFS est désormais beaucoup plus facile à utiliser25.
59La technologie était donc là, mais l’usage ne semble pas avoir suivi. De manière plus générale, l’écosystème d’IPFS semble davantage se focaliser sur l’existence d’applications que sur leur usage, tel que le montre également la page Awesome IPFS, dont environ la moitié des applications sont désormais désuètes ou non maintenues sur la centaine de disponibles26.
- 27 Traduction de l’auteur à partir de : « One of its first applications was as a social network, and i (...)
60Plus qu’un déterminisme technologique, SSB présente une approche mutuellement informative entre technique et culture, imprégnée de dynamiques holistiques à travers lesquelles protocoles et humains coexistent et coagissent dans un seul et même système. Ainsi que le présente la documentation du protocole, ce dernier est efficace non pas strictement par ses vertus techniques, mais par l’environnement interpersonnel que procure la communauté utilisatrice de ce protocole : « L’une de ses premières applications a été le réseau social, et il est également devenu l’un des plus attrayants, car les personnes qui s’y retrouvent ne sont pas des imbéciles27. » (Anonymous, 2021)
61Cet enchevêtrement entre développements technologiques et interactions sociales est présent dès la genèse de SSB racontée par Dominic Tarr. L’auteur de SSB développe d’abord des concepts technologiques, les présente et intègre des contributions d’autres individus et collaborateurs, puis développe le protocole davantage, dans un mouvement de balance qui contraste avec l’aspect plus téléologique d’IPFS (Tarr, 2016).
62Cette étude comparative de deux protocoles a permis de présenter le concept de critique protocolaire : une critique tant technique que discursive et opérationnelle. Dans les deux cas d’étude choisis, nous avons pu voir que la constitution d’une critique protocolaire trouve son point de départ dans une description technique, puis se développe dans une pluralité de discours soutenant et justifiant une manière de communiquer réifiée dans la technique, et enfin confrontée à une application pratique.
63Cela a également permis de révéler la manière dont une critique protocolaire, notamment à travers le dispositif technique, présente des présupposés profonds quant à la manière dont la communication d’une information doit se dérouler. Ce constat est renforcé quand il s’agit d’un domaine en particulier, que ce soit en se focalisant sur le message (IPFS) ou sur les interlocuteurs (SSB).
64D’autre part, nous avons exploré comment cette rhétorique du protocole peut plus ou moins s’aligner à la rhétorique des utilisateurs. Cela a notamment été pertinent pour le cas de la censure sur IPFS, celui de la centralisation des données, ou encore celui de l’application à des domaines plus spécifiques. Certaines cohérences et incohérences ont pu être identifiées entre les discours autour du protocole et les applications développées par ce protocole, en touchant à la question du déterminisme technologique, que ce soit sur une trajectoire téléologique (IPFS) ou sur une trajectoire plus écologique (SSB). Dès lors, il peut être avancé qu’un protocole de communication semble impliquer un déterminisme, pas uniquement par sa technologie, mais aussi par sa culture.
Flux RSS
