La disparition de Nitter, une alternative libre au frontend de Twitter

À la suite de l'analyse des solutions de contournement pour continuer à fonctionner dans de nouvelles conditions, des flux RSS et certains points d'entrée sur syndication.twitter.com ont été découverts, fournissant des informations à des utilisateurs non enregistrés au format JSON, et utilisés pour l'intégration avec d'autres réseaux sociaux. Pendant un certain temps, Nitter a obtenu des informations via ces interfaces, mais elles ont ensuite été fermées. Après cela, un moyen d'utiliser des « comptes invités », ayant des privilèges de lecture, a été trouvé. L'un des types de « comptes invités » était destiné à être utilisé sur des appareils Internet des objets avec des navigateurs simplifiés.

Mais Nitter a utilisé un autre type de « comptes invités », qui appliquaient OAuth au lieu des cookies, s'enregistraient via l'API et étaient apparemment utilisés par l'application Android. Ce type de compte a des limites de 500 requêtes API toutes les 15 minutes, et son « enregistrement » est lié à une adresse IP (d'une même IP, un « compte invité » peut être enregistré en une journée, mais un « compte » déjà enregistré peut être utilisé avec d'autres adresses IP).

Ces « comptes » (tokens d'accès) étaient opérationnels pendant 30 jours. À ce moment-là, une solution adéquate au problème de l'enregistrement massif de comptes temporaires aurait pu être le crowdsourcing de leur inscription par les utilisateurs, utilisant quelque chose de similaire à Bibliogram (un userscript qui prend le token invité d'un utilisateur et le transmet à une instance publique).

Fin janvier, X a cessé de délivrer de tels tokens. L'élimination du dernier moyen d'accès a mis un terme à Nitter en tant que service public gratuit multi-utilisateurs, conduisant l'auteur à déclarer Nitter mort.

Une partie des instances s'est immédiatement arrêtée après cela, d'autres ont modifié leur code pour économiser strictement l'utilisation des tokens existants, en particulier en les utilisant principalement pour récupérer des listes de tweets des comptes, avec des messages d'erreur pour tout le reste. Le 26 février, la durée de vie des derniers tokens invités a expiré, ce qui a entraîné l'arrêt de toutes les instances publiques. Cependant, des discussions sur la façon de traiter les comptes invités se poursuivent dans le tracker de bugs.

Une des solutions radicales au problème pourrait être le remplacement de Twitter par la création d'un service alternatif décentralisé basé sur ActivityPub et IPFS, où l'identifiant principal de chaque message serait son CID IPFS. On peut imaginer la structure multi-niveaux suivante :

Cependant, les données du point 3 ne résolvent pas le problème de l'absence de participation des utilisateurs de Twitter au programme de remplacement de Twitter.

Pour chaque identifiant de post sur chaque plateforme centralisée, il pourrait être judicieux de maintenir son affichage dans le CID IPFS, qui fonctionne comme un cache, permettant sans connaître le texte même du post, mais en connaissant son identifiant centralisé, de connaître son identifiant décentralisé. Lors de la génération d'URI dans IPFS (ce qui peut être fait sans téléchargement réel), le texte du post subit une canonicalisation, qui consiste à placer les données dans un conteneur basé sur HTML avec des métadonnées lisibles par machine, normalisation de l'unicode, conversion en UTF-8, remplacement des espaces par des espaces simples, et remplacement de tous les liens vers des posts sur cette et d'autres plateformes, passant par une procédure similaire, par des URI dans IPFS.

Chaque plateforme possède un document lisible par machine qui décrit les règles de canonicalisation des publications, y compris de nombreux services dont les liens sont remplacés par des URI IPFS dans les publications de ce réseau. Chaque publication dans chaque réseau est canonique en fonction des règles de canonicalisation des publications de ce réseau en vigueur au moment où la publication a été datée. Lors de la canonicalisation, si un lien vers une publication dans l'une des plateformes remplacées est présent, l'implémentation extrait l'identifiant centralisé du lien et vérifie sa présence dans les index de confiance.

En cas de présence dans l'index, l'implémentation utilise l'identifiant décentralisé des index. En l'absence, l'implémentation demande la publication via le lien, la canonise et génère un identifiant pouvant être inclus dans les index. L'implémentation n'est pas tenue d'inclure la publication demandée dans le réseau décentralisé. L'implémentation peut vérifier la validité de l'identifiant dans l'index par une reproduction locale du processus. L'implémentation de l'index est tenue de vérifier la validité de la génération des identifiants par une reproduction locale du processus.

Ce processus déterministe permet de générer des liens immuables vers le contenu même pour les tweets dont les publications ne participent pas encore au programme de remplacement de Twitter. Lorsque certaines d'entre elles commenceront à télécharger leurs tweets dans IPFS, l'algorithme générera pour elles des identifiants identiques à ceux déjà utilisés dans les liens, à condition que l'index contienne des représentations correctes et que le contenu lui-même n'ait pas changé.

Source : opennet.ru