Die letzte öffentliche Instanz von Nitter ist ausgefallen. Das Nitter-Projekt entwickelte ein freies Frontend, um auf X.com/Twitter zuzugreifen, ohne JavaScript, Analytik, Tracker und Drittanbieterdienste aufzuzwingen. Am 31. Januar wurde die Ausgabe von Tokens eingestellt, die in Nitter zur Organisation des Zugriffs auf Inhalte in X.com verwendet wurden. Am 26. Februar lief die Lebensdauer der letzten zuvor ausgegebenen Tokens ab, was zu einem vollständigen Stillstand von Nitter führte.
Nach dem Kauf durch Elon Musk begann Twitter (nun in X umbenannt), eine Reihe technischer und organisatorischer Maßnahmen zur aggressiven Monetarisierung der zuvor als defizitär geltenden Plattform umzusetzen. Zu den Änderungen gehörte die Einführung einer Entgeltstruktur für die von jedem Konto erhaltenen Informationen (es wurden Limits für verschiedene Kontotypen eingeführt – 10.000 für Inhaber eines kostenpflichtigen 'Blauen Häkchens', 1.000 für normale Konten, 500 für neue normale Konten); Entwicklerkonten wurden in die kostenpflichtige Kategorie überführt, mit Limits, die für das massenhafte Scraping geeignet sind; die Bereitstellung von Informationen an Nutzer ohne Konten wurde eingestellt.
Öffentlich wurde am 01.07.2023 behauptet, dass dies „vorübergehende Notmaßnahmen“ seien, die darauf abzielen, dass die automatisierte Datenerfassung durch Bots die Servicequalität für gewöhnliche Nutzer beeinträchtigt. Zuvor, am 19.04.2023, gab es Andeutungen gegen Microsoft, dass das Unternehmen unerlaubt Twitter-Daten zur Schulung von KI verwendet. Später, am 17.11.2023, wurden die Einführung von Limits mit Musks Ankündigung zur Bekämpfung von Bots begründet.
Nitter war ein Projekt zur Entwicklung von Software zum Schutz vor der Überwachung von Twitter-Nutzern, die keine Nachrichten senden, sondern nur Inhalte lesen, indem es ihnen eine alternative Website für den Zugriff auf Twitter bereitstellt, die weder ein Konto noch aktiviertes JavaScript erfordert. Diese Software fungiert tatsächlich als Scraper und Vermittler, der die Daten nicht in einer Datenbank speichert, sondern sie direkt an den Endbenutzer überträgt (obwohl einige Systemdaten in Redis zwischengespeichert werden).
So war die Nitter-Software:
Im Rahmen der Analyse von Alternativen zur Fortführung der Aktivitäten unter den neuen Bedingungen wurden RSS und einige Einstiegspunkte auf syndication.twitter.com entdeckt, die Informationen im JSON-Format an nicht registrierte Benutzer zurückgaben und zur Integration mit anderen sozialen Netzwerken genutzt wurden. Eine Zeit lang erhielt Nitter Informationen über diese Schnittstellen, bis auch diese schließlich abgeschaltet wurden. Danach wurde eine Methode gefunden, um „Gastkonten“ zu nutzen, die Leserechte hatten. Eine der Arten von „Gastkonten“ war für den Einsatz auf Internet-of-Things-Geräten mit eingeschränkten Browsern konzipiert.
Nitter verwendete jedoch eine andere Art von „Gastkonten“, die OAuth anstelle von Cookies nutzten, über die API registriert wurden und offenbar von der Android-App verwendet wurden. Diese Art von Konten hat eine Limitierung von 500 API-Anfragen innerhalb von 15 Minuten, und ihre „Registrierung“ ist gebunden an die IP-Adresse gebunden sind (von einer IP kann innerhalb von 24 Stunden ein „Gastkonto“ registriert werden, aber ein bereits registriertes „Konto“ kann von anderen IP-Adressen verwendet werden).
Solche "Accounts" (Zugriffstoken) waren 30 Tage lang funktionsfähig. Zu diesem Zeitpunkt hätte eine angemessene Lösung für das Problem der massenhaften Registrierung temporärer Accounts Crowdsourcing sein können, wobei Nutzer etwas Ähnliches wie Bibliogram verwenden (ein Userskript, das das Gästetoken des Benutzers abruft und an eine öffentliche Instanz überträgt).
Ende Januar stellte X die Ausgabe solcher Tokens ein. Die Beseitigung der letzten Zugangsweise besiegelte das Schicksal von Nitter als öffentlichen, kostenlosen Mehrbenutzerservice, weshalb der Autor Nitter für tot erklärte.
Einige Instanzen schlossen daraufhin sofort, andere modifizierten den Code, um die Nutzung der bestehenden Tokens stark zu reduzieren, insbesondere durch vorrangige Verwendung zum Abruf von Tweet-Listen der Accounts, bei denen Fehlermeldungen für alles andere ausgegeben wurden. Am 26. Februar lief die Lebensdauer der letzten Gästetoken ab, wodurch alle öffentlichen Instanzen ihren Betrieb einstellten. Dennoch werden im Bugtracker Möglichkeiten diskutiert, die in irgendeiner Weise die Gästekonten betreffen.
Eine grundlegende Lösung für das Problem könnte die Schaffung eines alternativen dezentralen Dienstes auf Basis von ActivityPub und IPFS sein, bei dem die Hauptkennung jeder Nachricht ihr IPFS CID ist. Man kann sich folgende mehrstufige Struktur vorstellen:
Die Daten aus Punkt 3 lösen jedoch nicht das Problem, dass die Nutzer von Twitter nicht am Programm des Twitter-Ersatzes teilnehmen.
Für jeden Post-Identifikator auf jeder zentralisierten Plattform kann es sinnvoll sein, die Darstellung in IPFS CID zu unterstützen, die als Cache fungiert. Damit lässt sich der dezentralisierte Identifikator ohne Kenntnis des eigentlichen Textes, sondern nur mit dem zentralisierten Identifikator herausfinden. Bei der Generierung einer URI in IPFS (was ohne tatsächliches Hochladen erfolgen kann) wird der Text des Posts kanonikalisiert. Dies geschieht durch das Platzieren der Daten in einem Container basierend auf HTML mit maschinenlesbaren Metadaten, Unicode-Normalisierung, Umwandlung in UTF-8, Ersetzung von Leerzeichen durch einfache Leerzeichen und der Ersetzung aller Links zu Posts auf dieser und anderen Plattformen, die durch ein ähnliches Verfahren gehen, auf URI in IPFS.
Jede Plattform verfügt über ein maschinenlesbares Dokument, das die Regeln für die Kanonisierung von Beiträgen beschreibt, einschließlich mehrerer Dienste, deren Links in diesem Netzwerk durch IPFS-URIs ersetzt werden. Jeder Beitrag in jedem Netzwerk wird gemäß den zum Zeitpunkt der Veröffentlichung geltenden Kanonisierungsregeln für Beiträge dieses Netzwerks kanonisiert. Bei der Kanonisierung, wenn ein Beitrag auf einen Beitrag in einer der ersetzten Plattformen verweist, extrahiert die Implementierung die zentralisierte ID aus dem Link und prüft deren Vorhandensein in den vertrauenswürdigen Indizes.
Wenn die ID im Index vorhanden ist, verwendet die Implementierung die dezentralisierte ID aus den Indizes. Ist sie nicht vorhanden, wird der Beitrag über den Link angefragt, kanonisiert und ein ID erstellt, die in die Indizes eingefügt werden kann. Die Implementierung ist nicht verpflichtet, den angeforderten Beitrag in das dezentrale Netzwerk einzufügen. Sie kann die Richtigkeit der ID im Index durch lokale Reproduktion des Prozesses überprüfen. Die Implementierung des Indizes ist verpflichtet, die Richtigkeit der Generierung der IDs durch lokale Reproduktion des Prozesses zu überprüfen.
Ein solcher deterministischer Prozess ermöglicht die Generierung unveränderlicher Links zu Inhalten, selbst für Tweets, deren Poster noch nicht am Twitter-Austauschprogramm teilnehmen. Wenn einige von ihnen ihre Tweets in IPFS hochladen, wird der Algorithmus für sie Identifikatoren generieren, die identisch mit denen sind, die bereits in Links zu ihnen verwendet werden, vorausgesetzt, der Index enthält die richtigen Darstellungen und der Inhalt hat sich nicht verändert.
Quelle: opennet.ru
