Ostatnia publiczna wersja Nittera przestała działać. Projekt Nitter rozwijał wolny frontend do uzyskiwania dostępu do X.com/Twitter bez nałożonych ograniczeń JavaScript, analityki, trackerów i usług zewnętrznych. 31 stycznia wstrzymano wydawanie tokenów używanych w Nitterze do organizacji dostępu do treści na X.com. 26 lutego wygasł czas działania ostatnich wcześniej wydanych tokenów, co doprowadziło do całkowitego wstrzymania pracy Nittera.
Po zakupie przez Elona Muska, Twitter (obecnie przemianowany na X) zaczął wdrażać szereg technicznych i organizacyjnych środków mających na celu agresywną monetyzację platformy, wcześniej uznawanej za deficytową. Wśród zmian wprowadzono opłatę za informacje uzyskane przez każdy konto (wprowadzono limity dla różnych typów kont — 10000 dla posiadaczy płatnej „niebieskiej ptaszka”, 1000 dla zwykłych, 500 dla nowych zwykłych); konta „deweloperów” zostały przekształcone w płatne z ograniczeniami odpowiednimi do masowego wydobywania danych (scrapingu); zaprzestano udostępniania informacji użytkownikom bez kont.
Jako uzasadnienie publicznie podawano (2023-07-01), że są to „tymczasowe środki awaryjne”, związane z tym, że automatyczne pobieranie danych przez boty prowadzi do pogorszenia usługi dla zwykłych użytkowników. Przed tym (2023-04-19) pojawiły się insynuacje pod adresem Microsoft, związane z tym, że ta firma nielegalnie wykorzystuje dane Twittera do szkolenia AI. Później (2023-11-17) wprowadzenie limitów uzasadniono zapowiedzią Muska o walce z botami.
Nitter był projektem oprogramowania do ochrony użytkowników Twittera przed inwigilacją, którzy nie wysyłają wiadomości, a jedynie czytają materiały, oferując im alternatywną stronę do przeglądania Twittera, nie wymagającą ani konta, ani włączonego JavaScriptu. Takie oprogramowanie faktycznie działa jako scraper i pośrednik, który zamiast przechowywać dane w bazie danych, przesyła je do użytkownika końcowego (niemniej jednak niektóre dane robocze są buforowane w Redis).
W ten sposób oprogramowanie Nitter:
W wyniku analizy sposobów ominięcia problemów z kontynuowaniem działania w nowych warunkach, odkryto RSS oraz kilka punktów dostępu na syndication.twitter.com, które udostępniały informacje niezarejestrowanym użytkownikom w formacie JSON i były wykorzystywane do integracji z innymi sieciami społecznościowymi. Przez pewien czas Nitter uzyskiwał informacje za pośrednictwem tych interfejsów, ale potem one również zostały zablokowane. Następnie znaleziono sposób na wykorzystanie „gościnnych kont”, które miały przywileje do czytania. Jeden z typów „gościnnych kont” był przeznaczony do użycia na urządzeniach Internetu Rzeczy z ograniczonymi przeglądarkami.
Jednak Nitter korzystał z innego typu „gościnnych kont”, które stosowały OAuth zamiast ciastka, rejestrowały się przez API i były używane przez aplikację na Androida. Ten typ kont ma limity 500 zapytań do API w ciągu 15 minut, a jego „rejestracja” jest powiązana z adresem IP (z jednego IP można zarejestrować jedno „gościnne konto” w ciągu doby, ale już zarejestrowane „konto” można używać z innych adresów IP).
Takie „konta” (tokeny dostępu) były aktywne przez 30 dni. Wówczas rozsądnym rozwiązaniem problemu masowej rejestracji tymczasowych kont mogłoby być crowdsourcing ich rejestracji przez użytkowników, wykorzystując coś podobnego do Bibliogram (skrypt użytkownika, który pobiera gościnny token od użytkownika i przekazuje go publicznej instancji).
Pod koniec stycznia X zaprzestał wydawania takich tokenów. Eliminuje to ostatni sposób dostępu, co oznacza śmierć Nitter jako publicznego, darmowego, wieloosobowego serwisu, w wyniku czego autor ogłosił Nitter za martwego.
Niektóre instancje zamknęły się natychmiast, inne zmodyfikowały kod, aby oszczędnie wykorzystywać istniejące tokeny, w szczególności preferując ich użycie do uzyskiwania list tweetów z kont, podając komunikaty o błędach dla pozostałych. 26 lutego wygasł czas działania ostatnich tokenów gościnnych, w wyniku czego wszystkie publiczne instancje przestały funkcjonować. Niemniej jednak w trackerze błędów dyskutowane są sposoby dotyczące kont gościnnych.
Jednym z kluczowych rozwiązań problemu mogłoby być stworzenie alternatywnej zdecentralizowanej usługi na bazie ActivityPub i IPFS, gdzie głównym identyfikatorem każdej wiadomości jest jej IPFS CID. Można sobie wyobrazić następującą wielowarstwową strukturę:
Jednak dane z punktu 3 nie rozwiązują problemu braku udziału użytkowników Twittera w programie zastąpienia Twittera.
Dla każdego identyfikatora posta na każdej zdecentralizowanej platformie, może być zasadnym utrzymywanie jego odzwierciedlenia w IPFS CID, który pełni rolę cache'u, pozwalającego bez znajomości samego tekstu posta, ale przy znajomości jego zcentralizowanego identyfikatora, poznać jego zdecentralizowany identyfikator. Przy generowaniu URI w IPFS (co może być zrobione bez faktycznego przesyłania) tekst posta przechodzi kanonizację, polegającą na umieszczeniu danych w kontenerze opartym na HTML z maszynowo czytelnymi metadanymi, normalizacji Unicode, konwersji do UTF-8, zamianie białych znaków na proste pojedyncze spacje, oraz zamianie wszystkich linków do postów na tej i innych platformach, przechodzących przez podobną procedurę, na URI w IPFS.
Każda z platform ma maszyny czytelny dokument, w którym opisane są zasady kanonizacji postów, w tym wiele usług, których linki są zastępowane przez URI IPFS w postach tej sieci. Każdy post w każdej sieci jest kanonizowany zgodnie z zasadami kanonizacji postów w tej sieci, obowiązującymi w momencie, do którego datowany jest sam post. Przy kanonizacji, jeśli w poście znajduje się link do posta na jednej z zastępowanych platform, realizacja wyodrębnia z linku scentralizowany identyfikator i sprawdza jego obecność w zaufanych indeksach.
W przypadku obecności w indeksie, realizacja korzysta z zdecentralizowanego identyfikatora z indeksów. W przypadku braku, realizacja żąda posta po linku, kanonizuje go i formuje identyfikator, który może umieścić w indeksach. Realizacja nie jest zobowiązana do umieszczania żądanego posta w zdecentralizowanej sieci. Realizacja może weryfikować poprawność identyfikatora w indeksie poprzez lokalne reprodukcję procesu. Realizacja indeksu jest zobowiązana do sprawdzenia poprawności generowania identyfikatorów poprzez lokalne reprodukcję procesu.
Taki deterministyczny proces pozwoli na generowanie niezmiennych linków do treści nawet dla tweetów, których plakaty do tej pory nie uczestniczą w programie zamiany Twittera. Gdy część z nich zacznie przesyłać swoje tweety do IPFS, algorytm wygeneruje dla nich identyfikatory, identyczne te, które już są używane w linkach do nich, pod warunkiem, że indeks zawiera poprawne odwzorowania i sama treść się nie zmieniła.
Źródło: opennet.ru
