- Ce site mesure à quel point les données utilisateurs sont concentrées dans le Fediverse (Mastodon, Pixelfed, etc.) et l’Atmosphere (Bluesky, WhiteWind, etc.)
- Il analyse le degré de répartition des utilisateurs entre les serveurs à l’aide de l’indice de Herfindahl-Hirschman (HHI) et de l’indice de Shannon
- Le HHI est un indicateur utilisé en économie pour mesurer le niveau de concurrence : plus sa valeur est faible, plus la répartition est dispersée ; plus elle est élevée, plus elle indique une concentration monopolistique
- L’indice de Shannon est un indicateur de diversité fondé sur l’entropie : plus sa valeur est élevée, plus cela signifie que la population est répartie uniformément entre les serveurs
- En plus de la concentration des données, ce projet prend en compte divers facteurs de mesure de la décentralisation, comme la structure du réseau, la juridiction légale et la concentration du pouvoir social, et publie ses données et son code sur GitHub
Présentation et concepts clés
- Mesure à quel point les données utilisateurs sont concentrées sur les plateformes du Fediverse et de l’Atmosphere à l’aide de l’indice de Herfindahl-Hirschman (HHI)
- Le HHI est un indicateur de référence en économie pour évaluer le niveau de concurrence ; il est calculé en additionnant les carrés de la part d’utilisateurs de chaque serveur (ou PDS)
- Plus la valeur du HHI est proche de 0, plus cela signifie que les utilisateurs sont répartis uniformément entre plusieurs serveurs ; plus elle est proche de 10
000, plus elle suggère un état de monopole où la majorité des utilisateurs est concentrée sur un seul serveur
- En général, un HHI inférieur à 100 est considéré comme « très concurrentiel », inférieur à 1
500 comme « non concentré », et supérieur ou égal à 2
500 comme « fortement concentré »
Méthode de mesure et définition des données
- Les éléments mesurés sont les serveurs (instances) du Fediverse et les PDS (serveurs de données personnels) de l’Atmosphere
- Pour des plateformes comme Mastodon, où les utilisateurs sont répartis entre plusieurs instances, les instances appartenant à un même opérateur sont regroupées
- Exemple :
mastodon.social et mastodon.online sont exploités par la même entreprise, donc regroupés dans les statistiques
- Tous les PDS gérés par Bluesky Social PBC sont également comptabilisés comme une seule entité
- Cela permet de refléter avec précision la taille de la base d’utilisateurs contrôlée par une même entité
Les différentes approches de la mesure de la centralisation
- Au-delà de la répartition physique des données utilisateurs, la décentralisation peut être analysée sous plusieurs angles
- Aspects liés à la structure du réseau (ex. : P2P, relais, etc.)
- Méthodes de gestion de l’identité
- Propriété et localisation de l’infrastructure réelle (région, juridiction, etc.)
- Concentration du pouvoir social et organisationnel (par ex. concentration de l’influence au sein de la plateforme)
- Il faut s’intéresser non seulement à la répartition des données dans la plateforme, mais aussi à la distribution des pouvoirs et de l’influence
Participation au projet et open source
- L’ensemble du code et des jeux de données utilisés pour la mesure est publié dans le dépôt GitHub
- Les contributions, commentaires, propositions de nouveaux indicateurs de mesure et l’ajout d’indicateurs de resiliency sont les bienvenus
2 commentaires
Dire « Sommes-nous déjà décentralisés ? » n’est pas complètement faux, mais c’est peu naturel et un peu maladroit.
Comme « déjà » s’emploie surtout avec des phrases négatives...
Je me dis qu’une traduction comme « La décentralisation, ce n’est pas encore pour maintenant ? » serait un titre plus naturel.
Discussion Hacker News
J’ai découvert pour la première fois aujourd’hui le Herfindahl–Hirschman Index, et j’ai voulu le tester sur un cas inhabituel et mémorable.
À la fin des années 1980, Microsoft a, pendant un temps, dépassé les 100 % de part de marché sur le marché des tableurs pour Macintosh.
Cela s’explique par la manière dont la part de marché était calculée : on divisait les ventes de chaque acteur sur une période donnée par les ventes totales du marché sur cette même période. Or, à l’époque, le tableur Lotus Jazz de Lotus a été un tel échec que les retours ont dépassé les ventes.
Lotus s’est donc retrouvé avec une part de marché négative, et comme les ventes de Microsoft Excel étaient supérieures au total des ventes du marché, sa part a dépassé les 100 %.
Je ne me souviens plus des chiffres exacts, mais c’était en gros Microsoft 102 % et Lotus -2 %.
Dans ce cas, le Herfindahl–Hirschman Index devient 1022 + (-2)2 = 10404 + 4 = 10408.
Dans un cas aussi extrême, le HHI peut donc dépasser 10 000.
(J’ai ajouté la condition « sur une période donnée » pour l’explication.)
J’ai cherché très sérieusement des articles en ligne à ce sujet, sans rien trouver (peut-être que c’est quelque part sur microfiche...).
À la place, j’ai trouvé une anecdote amusante.
Un dirigeant de Lotus aurait plaisanté : « Le premier mois, on en a expédié 62 000, et le mois suivant, 64 000 ont été retournés. On nous a même rendu des copies piratées. »
Article Forbes lié
Le HHI est vraiment un indicateur utile.
L’idée de sommer les carrés des parts normalisées s’applique bien à beaucoup d’autres situations que les seules parts de marché.
Il existe aussi d’excellents exemples d’utilisation dans le vote.
Le résultat est intéressant, donc ce n’est pas surprenant.
BlueSky est, du point de vue de l’utilisateur ordinaire, un service qui remplace quasiment Twitter.
Le nombre total d’utilisateurs de Mastadon est plus faible, mais il est agréable de voir que l’écosystème Mastadon évite la concentration comme le fait l’écosystème AT-Proto.
Personnellement, j’imagine que le coût d’exploitation des serveurs/relais AT proto est assez lourd pour les petits opérateurs, mais ce n’est qu’une supposition de ma part sans connaissance approfondie de la structure interne des deux écosystèmes.
Héberger un serveur PDS pour soi-même et quelques amis n’est pas très coûteux.
Mais cela n’apporte pas non plus un grand avantage en soi ; le but du PDS est de séparer proprement ses données des données de l’ensemble du réseau.
Dans ATProto, ce qui coûte cher, ce sont le Relay (qui collecte/diffuse l’ensemble des données) et l’AppView (qui conserve en base de données tous les posts, likes, etc. et répond aux requêtes des utilisateurs).
Bien sûr, pour un petit réseau, par exemple pour publier de longs textes comme WhiteWind, cela reste faisable sans problème car le volume d’événements est faible.
L’architecture est surtout pensée pour qu’on n’ait pas besoin d’auto-héberger quoi que ce soit.
On peut créer son propre flux algorithmique ou son propre frontend en récupérant les données depuis le Relay ou l’AppView opérés par Bluesky.
Je pense que l’une des raisons du succès de BlueSky est qu’il ne met pas en avant la « décentralisation » auprès des utilisateurs comme le fait Mastodon.
La plupart des utilisateurs ne savent pas ce qu’est la décentralisation et ne veulent pas le savoir.
À mon avis, il faut consacrer plus d’efforts à une bonne exploitation du service et aux fonctions d’administration qu’à la décentralisation.
ATProto est soutenu par des entreprises et des investisseurs de profils variés.
Un jour ou l’autre, eux aussi voudront un retour sur investissement, et il est difficile de prévoir comment cela se concrétisera.
Concernant le débat sur les coûts d’exploitation, ATProto a une structure très différente.
Mastodon fonctionne comme plusieurs serveurs individuels de type Twitter qui échangent des informations entre eux comme le fait l’email, donc un petit serveur pour quelques connaissances coûte peu cher.
Mais avec cette structure, la connectivité avec le réseau global est plus faible, et mon serveur devient en quelque sorte mon identité.
Si je suis des utilisateurs d’un autre serveur, mon serveur va y demander les informations, mais par nature la vue de l’ensemble du réseau reste fragmentée.
ATProto a été conçu dès le départ avec un autre type de « découpage » pour pouvoir rivaliser avec des services centralisés, en séparant l’origine des données et l’agrégation au niveau de l’application.
C’est un peu comme si chaque utilisateur publiait du JSON sur son propre site web (URL), et qu’une application agrégeait ces données.
Au final, tout le monde obtient la même vue d’ensemble (avec tous les commentaires, likes et réponses reflétés).
Là où Mastodon a une « instance » qui est une webapp Twitter autonome, ATProto fournit plusieurs primitives distribuées.
Un AppView qui ne voit qu’une partie du réseau, comme dans le modèle Mastodon, coûte bien moins cher, mais comme c’est moins attractif, presque personne ne l’utilise.
En résumé, exploiter un PDS et un Relay coûte peu, mais faire tourner un AppView complet coûte cher, et Mastodon n’a tout simplement pas d’équivalent à ce concept.
Comparer simplement les prix entre l’expérience fragmentée de Mastodon et l’expérience cohérente d’ATProto est donc discutable.
Faire tourner un AppView partiel à la manière de Mastodon est peu coûteux, mais a peu d’intérêt réel.
Par ailleurs, Mastodon essaie d’atténuer cela avec du on-demand fetching, mais un système distribué fondé sur du pull a ses limites.
Question liée
Même dans les systèmes distribués, on observe au final une tendance naturelle à la centralisation.
Git était aussi une tentative de décentralisation, mais dans la pratique, cela se concentre sur certaines plateformes comme GitHub ou GitLab.
BitTorrent est distribué lui aussi, mais les sites de trackers jouent naturellement un rôle central.
Bitcoin aussi finit par voir certains services comme Coinbase occuper une position centrale.
Même l’email (SMTP) connaît dans les faits une forme de centralisation à cause du spam.
Dans le cas de l’email (SMTP), dire que « seuls les grands acteurs savent filtrer le spam » n’est pas vrai.
Il existe depuis longtemps des listes distribuées de filtrage anti-spam, et les grands acteurs n’ont pas d’avantage particulier sur ce point.
En revanche, les grands acteurs ont tendance à considérer les petits serveurs mail comme du spam, et il se peut même qu’il y ait parfois une volonté d’écraser la concurrence.
Cela dit, avoir correctement configuré le reverse DNS et DKIM sur un serveur mail ne signifie pas qu’il sera forcément classé comme spam, et même de grands services peuvent se marquer mutuellement comme spam, donc rien n’est absolu.
Il existe de nombreux sites de trackers, et quand l’un disparaît, un autre apparaît rapidement.
On peut donc toujours parler de décentralisation, puisqu’il n’y a pas un acteur unique qui contrôle l’écosystème.
Des services comme Coinbase, tout le monde peut en créer.
Il existe d’ailleurs beaucoup de sites comparables, et désormais on peut aussi utiliser PayPal.
Il n’y a pas non plus besoin de dépendre d’un seul service : on peut par exemple acheter du bitcoin sur PayPal et le revendre sur Coinbase.
Je trouve étrange de définir une telle situation comme centralisée.
Git lui-même n’a pas été conçu comme un outil visant la décentralisation ; c’est aussi un point à noter.
Tous les exemples mentionnés comportent malgré tout, au final, un élément de centralisation.
C’est plus décentralisé dans le fedi (l’écosystème social distribué), mais cela manque de cohérence.
C’est ce qui suscite le plus de plaintes chez les utilisateurs qui arrivent dans le fedi.
Personnellement, je pense que c’est un grand progrès et que c’est acceptable, mais il est plus important d’avoir des attentes réalistes.
Je me demande comment on pourrait mesurer des anciens systèmes fédérés comme IRC ou NNTP avec une approche de type HHI.
Je serais curieux de voir ce que donneraient ces anciens systèmes avec ce type d’indicateur.
Il y a eu ce cas où, quand freenode a changé de propriétaire, presque tout le monde a migré en moins d’une semaine.
C’est intéressant de voir à quel point cette mobilité était simple et réelle.
Dans un environnement réduit et semi-privé, IRC reste excellent, surtout avec un frontend web qui permet le scroll-back.
Mais quand l’échelle devient trop grande, cela commence à se dégrader à cause des différences politiques et culturelles.
Quand les gens ont des affinités, cela fonctionne très bien, mais dès que l’on passe à un espace entièrement public, apparaissent des désaccords, des trolls, des bots IA, etc.
On peut garder l’interface web semi-privée et prévenir les menaces de sécurité, les conflits et les bots tiers grâce à une authentification simple, au blocage du referer, etc.
NNTP est aussi correct, mais il n’est pas simple de faire du mirroring individuel de l’ensemble des groupes binaires, et comme les FAI ne le prennent plus en charge, la plupart des gens utilisent des newsfeeds commerciaux ou des fournisseurs Usenet gratuits.
Il est bon de faire du peering avec certains fournisseurs gratuits afin de réduire les risques de censure.
Avec IRC comme avec NNTP, des particuliers peuvent créer leurs propres serveurs liés privés ou semi-privés.
Informations liées
Le calcul mathématique est simple, et les statistiques réseau correspondantes sont disponibles sur netsplit.de.
Ce serait intéressant d’ajouter Nostr à cette distribution HHI.
Dans Nostr, la concentration de la base d’utilisateurs est souvent citée comme une faiblesse majeure du modèle fedi, mais ici cela donnerait quelque chose d’un peu étrange, puisque l’identité utilisateur n’est pas rattachée à un seul relais.
Je me demande si ces questions de centralisation/décentralisation ne relèvent pas toujours, au fond, du marketing et de l’UX.
Ce serait intéressant de voir quels changements se produiraient si Threads était inclus dans le Fediverse.
Il est important de garder un bon équilibre.
Trop de décentralisation, et plus personne ne trouve rien ; trop de centralisation, et la censure fait disparaître la liberté.
Personnellement, je me demande si la découvrabilité (discoverability) est réellement impossible dans un environnement distribué.
Si l’on investit suffisamment de ressources (argent, personnel, etc.) dans l’indexation, il se pourrait que le juste milieu soit maintenu de façon instable, comme un pendule tenu en équilibre inversé.
À l’époque dorée des blogs, on a bien vu une forme d’harmonie entre les moteurs de recherche (centralisés) et les blogs/forums (individuels), mais avec le temps cela s’est affaibli à cause du spam et de l’intégration dans les grandes plateformes.
Je voudrais souligner qu’on part de l’hypothèse selon laquelle la fonction de « découverte » nécessite forcément un élément centralisé.
En économie, on considère généralement qu’un HHI inférieur à 100 indique une « forte concurrence », inférieur à 1500 un marché « non concentré », et supérieur à 2500 un marché « fortement concentré ».
Le Fediverse est déjà à 690 tout en étant presque à l’extrême gauche.
Une centralisation totale (tout en haut) correspond à 5000.
On visualise en fait une échelle non linéaire de manière linéaire.
Je veux un vrai choix artificiel.
J’aimerais que l’utilisateur puisse lui-même choisir entre centralisation, décentralisation, hybride, etc.
S’il existe une critique selon laquelle c’est « trop décentralisé », une organisation à but non lucratif pourrait créer un index où les hôtes publics s’enregistreraient volontairement afin de rendre trouvable tout le contenu distribué.
De cette façon, le problème de recherche pourrait aussi être résolu.
Au fond, Facebook essaiera peut-être justement d’agréger ce type de données via Threads.
L’indicateur HHI lui-même est nouveau et facile à comprendre.
Si on le ramenait à une échelle de 0 à 100 (en divisant par 100), le chiffre semblerait peut-être plus intuitif.
On pourrait aussi envisager d’inverser l’échelle pour que 0 signifie centralisé et 100 totalement distribué.
Comme le titre de la page d’accueil donne l’impression de mesurer l’« avancement » vers la décentralisation, ce serait probablement plus intuitif ainsi.
Quand on voit un score de 2500, on se demande ce que cela signifie, alors que si l’on affichait 25/100, on ressentirait moins l’idée de « forte concentration ».