Einstellung der Existenz von Nitter, einer freien alternativen Frontend-Lösung für Twitter

Das letzte öffentliche Exemplar von Nitter ist unbrauchbar geworden. Das Nitter-Projekt entwickelte ein freies Frontend für den Zugang zu X.com/Twitter ohne die Auferlegung von JavaScript, Analytik, Trackern und Drittanbieterdiensten. Am 31. Januar wurde die Ausgabe von Token eingestellt, die in Nitter zur Organisation des Zugangs zu Inhalten auf X.com verwendet wurden. Am 26. Februar lief die Lebensdauer der letzten zuvor ausgegebenen Token ab, was zu einem vollständigen Stillstand des Nitter-Betriebs führte.

Nach dem Kauf durch Elon Musk begann Twitter (jetzt in X umbenannt) mit der Umsetzung eines Maßnahmenpakets von technischen und organisatorischen Maßnahmen zur aggressiven Monetarisierung der zuvor als defizitär geltenden Plattform. Zu den Änderungen gehörte die Einführung einer Preisgestaltung für die Informationen, die jedes Konto erhält (es wurden Limits für verschiedene Arten von Konten eingeführt — 10.000 für Inhaber einer kostenpflichtigen „blauen Häkchen“, 1.000 für gewöhnliche und 500 für neue gewöhnliche Konten); Konten von „Entwicklern“ wurden in die Kategorie der kostenpflichtigen Konten mit Limits eingestuft, die für die massenhafte Datenerfassung (Scraping) geeignet sind; die Bereitstellung von Informationen an Benutzer ohne Konten wurde eingestellt.

Als Rechtfertigung wurde öffentlich behauptet (01.07.2023), dass dies „temporäre Notmaßnahmen“ seien, da die automatisierte Datenladung durch Bots zu einer Verschlechterung des Services für gewöhnliche Benutzer führe. Zuvor (19.04.2023) gab es Anspielungen auf Microsoft, in Bezug darauf, dass dieses Unternehmen die Daten von Twitter illegal zur Ausbildung von KI verwendet. Später (17.11.2023) wurde die Einführung von Limits mit dem von Musk versprochenen Kampf gegen Bots gerechtfertigt.

Nitter war ein Softwareprojekt zum Schutz der Twitter-Nutzer vor Überwachung, die keine Nachrichten senden, sondern nur Materialien lesen, indem es ihnen eine alternative Website für die Anzeige von Twitter zur Verfügung stellt, die weder ein Konto noch aktiviertes JavaScript benötigt. Diese Software fungiert faktisch als Scraper und Vermittler, der anstelle der Speicherung von Daten in einer Datenbank diese an den Endbenutzer überträgt (dennoch werden einige Dienstdaten in Redis zwischengespeichert).

Somit war die Software Nitter:

  • technisch genau die Art von Software, gegen die die Geschäftsführung von Twitter aktiv ankämpfte;
  • war eines der wenigen aktiv entwickelten Softwareprodukte für den Zugriff auf Daten, die in Twitter gehostet sind, was seine Attraktivität als Modul zum Scraping im engeren Sinne des Begriffs — der Datenerfassung außerhalb offizieller Schnittstellen — bedingte;
  • Öffentliche Instanzen von Nitter wurden selbst zu Objekten des Scrapings, was dazu führte, dass einige Instanzen eine eigene Art von Captcha implementierten (1 zusätzlicher POST-Request, spezifisch für die jeweilige Instanz).

    Als Ergebnis der Analyse von Ausweichmöglichkeiten zur Fortsetzung des Betriebs unter neuen Bedingungen wurden RSS und einige Einstiegspunkte auf syndication.twitter.com entdeckt, die Informationen in JSON-Format an nicht registrierte Benutzer zurückgaben und zur Integration mit anderen sozialen Netzwerken verwendet wurden. Einige Zeit lang erhielt Nitter Informationen über diese Schnittstellen, aber dann wurden auch diese geschlossen. Danach wurde eine Möglichkeit gefunden, „Gastkonten“ zu verwenden, die Leseprivilegien hatten. Eine der Typen von „Gastkonten“ war für die Verwendung auf Internet-of-Things-Geräten mit eingeschränkten Browsern vorgesehen.

    Aber Nitter verwendete eine andere Art von „Gastkonten“, die OAuth anstelle von Cookies verwendeten, über die API registriert wurden und offenbar von einer Android-Anwendung verwendet wurden. Dieser Kontotyp hat Einschränkungen von 500 API-Requests in 15 Minuten, und seine „Registrierung“ ist gebunden an IP-Adresse (von einer IP-Adresse kann innerhalb von 24 Stunden ein „Gastkonto“ registriert werden, aber ein bereits registriertes „Konto“ kann von anderen IP-Adressen verwendet werden).

    Solche „Konten“ (Zugangstokens) waren 30 Tage lang funktionsfähig. Zu diesem Zeitpunkt hätte eine angemessene Lösung für das Problem der massenhaften Registrierung temporärer Konten darin bestehen können, das Crowdsourcing ihrer Registrierung durch Benutzer unter Verwendung von etwas Ähnlichem wie Bibliogram (ein Userscript, das das Gasttoken vom Benutzer abruft und an die öffentliche Instanz weitergibt) zu ermöglichen.

    Ende Januar stellte X die Ausgabe solcher Token ein. Die Abschaffung des letzten Zugangswegs setzte Nitter als öffentlichen kostenlosen Mehrbenutzerdienst außer Gefecht, woraufhin der Autor Nitter als tot erklärte.

    Einige Instanzen schlossen sich sofort danach, andere modifizierten den Code zur strengen Einsparung der Verwendung vorhandener Tokens, insbesondere durch die überwiegende Nutzung dieser für das Abrufen von Listen von Tweets von Konten, während für alles andere Fehlermeldungen ausgegeben wurden. Am 26. Februar lief die Lebensdauer der letzten Gast-Tokens ab, was dazu führte, dass alle öffentlichen Instanzen den Betrieb einstellten. Dennoch werden im Bug-Tracker Möglichkeiten diskutiert, die irgendwie mit Gastkonten zu tun haben.

    Eine der grundlegenden Lösungen des Problems könnte ein Twitter-Ersatz durch die Schaffung eines alternativen dezentralen Dienstes basierend auf ActivityPub und IPFS sein, bei dem die Hauptkennung jeder Nachricht ihre IPFS CID ist. Man könnte sich die folgende mehrstufige Konstruktion vorstellen:

  • Daten, die ursprünglich im föderierten Dienst wie auf der Hauptplattform veröffentlicht und in IPFS gespiegelt wurden.
  • Daten, die von den Nutzern selbst in Twitter veröffentlicht, aber mit einem Browser-Erweiterung in ihren Konten auf der föderierten Plattform gespiegelt wurden, und von dort aus — in IPFS.
  • Daten, die von den Nutzern selbst aus Twitter heruntergeladen wurden, wobei die Exportfunktion genutzt und in das Fediverse + IPFS über die Funktion zum Massen-Upload hochgeladen wurden.

    Die Daten des Punktes 3 lösen jedoch nicht das Problem der Nichtteilnahme der Twitter-Nutzer am Twitter-Ersatzprogramm.

    Für jede Identifizierung der Posts auf jeder zentralisierten Plattform kann es sinnvoll sein, deren Anzeige in IPFS CID zu unterstützen, das als Cache fungiert und es ermöglicht, ohne Kenntnis des tatsächlichen Textes des Beitrags, aber mit Wissen um dessen zentralisierte Identifikation, die dezentralisierte Identifikation zu erfahren. Bei der Generierung von URIs in IPFS (was ohne tatsächlichen Upload erfolgen kann) wird der Text des Beitrags kanonisiert, was bedeutet, dass die Daten in einen Container auf HTML-Basis mit maschinenlesbaren Metadaten, Normalisierung von Unicode, Konvertierung in UTF-8, Ersetzung von Leerzeichen durch einfache Leerzeichen, und Ersetzung aller Links zu Beiträgen auf dieser und anderen Plattformen, die ein ähnliches Verfahren durchlaufen, in URIs in IPFS umgewandelt werden.

    Jede der Plattformen verfügt über ein maschinenlesbares Dokument, in dem die Regeln zur Kanonisierung von Beiträgen beschrieben sind, einschließlich zahlreicher Dienste, deren Links in dieser Netzwerkkette durch IPFS-URIs ersetzt werden. Jeder Beitrag in jedem Netzwerk wird gemäß den zum Zeitpunkt der Erstellung des Beitrags geltenden Kanonarisierungsregeln für Beiträge in diesem Netzwerk kanonikalisiert. Bei der Kanonisierung, falls im Beitrag ein Link zu einem Beitrag auf einer der ersetzten Plattformen vorhanden ist, extrahiert die Implementierung die zentralisierte ID aus dem Link und prüft deren Vorhandensein in den vertrauenswürdigen Indizes.

    Liegt der indexierte Beitrag vor, verwendet die Implementierung die dezentrale ID aus den Indizes. Ist dies nicht der Fall, ruft die Implementierung den Beitrag über den Link ab, kanonikalisiert ihn und erstellt eine ID, die in die Indizes aufgenommen werden kann. Die Implementierung ist nicht verpflichtet, den angeforderten Beitrag in das dezentrale Netzwerk einzufügen. Die Implementierung kann die Gültigkeit der ID im Index durch die lokale Wiederholung des Prozesses überprüfen. Die Indeximplementierung ist verpflichtet, die Gültigkeit der Generierung der IDs durch die lokale Wiederholung des Prozesses zu überprüfen.

    Ein solcher deterministischer Prozess ermöglicht es, unveränderliche Links zu Inhalten zu erstellen, selbst für Tweets, deren Verfasser momentan nicht an dem Programm zur Twitter-Ersatzlösung teilnehmen. Wenn ein Teil von ihnen beginnt, ihre Tweets in IPFS hochzuladen, generiert der Algorithmus für sie IDs, die identisch sind mit denjenigen, die bereits in Links zu ihnen verwendet werden, vorausgesetzt, der Index enthält die korrekten Zuordnungen und der Inhalt selbst hat sich nicht geändert.

    Quelle: opennet.ru

  • 60GB SSD 8Gb DDR4