Ultimul exemplare publice de Nitter a devenit inoperabil. Proiectul Nitter dezvolta un frontend liber pentru accesul la X.com/Twitter fără impunerea JavaScript-ului, analizei, trackere și servicii externe. Pe 31 ianuarie a fost întreruptă emiterea de token-uri, folosite în Nitter pentru a organiza accesul la conținutul de pe X.com. Pe 26 februarie a expirat perioada de valabilitate a ultimelor token-uri emise anterior, ceea ce a dus la o oprire completă a activității Nitter.
După achiziția de către Elon Musk, Twitter (acum redenumit în X) a început să implementeze un set de măsuri tehnice și organizaționale menite să monetizeze agresiv platforma, considerată anterior deficitară. Printre schimbările implementate s-a numărat tarifarea informațiilor obținute de fiecare cont (au fost stabilite limite pentru diferite tipuri de conturi - 10000 pentru deținătorii de „bife albastre” plătite, 1000 pentru conturile obișnuite, 500 pentru conturile noi); conturile „dezvoltatorilor” au fost mutate în categoria celor plătite cu limite potrivite pentru extragerea datelor în masă (scraping); s-a oprit furnizarea de informații utilizatorilor fără conturi.
Ca justificare, s-a afirmat public (2023-07-01) că acestea sunt „măsuri excepționale temporare”, având în vedere că descărcarea automatizată a datelor de către boți duce la deteriorarea serviciului pentru utilizatorii obișnuiți. Înainte de aceasta (2023-04-19) au existat insinuări la adresa Microsoft, legate de faptul că această companie folosește ilegal datele Twitter pentru a antrena AI. Ulterior (2023-11-17), introducerea limitelor a fost justificată prin promisa luptă a lui Musk împotriva boților.
Nitter a fost un proiect de dezvoltare a unui software pentru protejarea utilizatorilor Twitter de supraveghere, care nu trimit mesaje, ci doar citesc materiale, oferindu-le un site alternativ pentru vizualizarea Twitter-ului, care nu necesită cont și JavaScript activat. Acest software funcționează practic ca un scraper și un intermediar, care în loc să salveze datele într-o bază de date, le trimite utilizatorului final (cu toate acestea, unele date administrative sunt stocate în Redis).
Astfel, software-ul Nitter:
În urma analizei modalităților de a continua activitatea în noile condiții, au fost descoperite RSS și câteva puncte de intrare pe syndication.twitter.com, care ofereau informații utilizatorilor neînregistrați în format JSON, fiind folosite pentru integrarea cu alte rețele sociale. O vreme, Nitter a obținut informații prin aceste interfețe, dar apoi și acestea au fost închise. După aceasta, a fost găsită o modalitate de a utiliza "conturi oaspete" care aveau privilegii de citire. Unul dintre tipurile de "conturi oaspete" era destinat utilizării pe dispozitivele de Internet of Things cu browsere reduse.
Însă Nitter a folosit un alt tip de "conturi oaspete", care aplicau OAuth în loc de Cookie, se înregistrau prin API și, aparent, erau folosite de aplicația pentru Android. Acest tip de conturi are limite de 500 de cereri către API în decurs de 15 minute, iar "înregistrarea" sa este legată de adresa IP (de pe o adresă IP se poate înregistra un "cont oaspete" pe zi, dar un "cont" deja înregistrat poate fi folosit de pe alte adrese IP).
Aceste "conturi" (tokenuri de acces) au funcționat timp de 30 de zile. La acel moment, o soluție adecvată pentru problema înregistrării în masă a conturilor temporare ar fi putut fi crowd-sourcing-ul înregistrării lor de către utilizatori, folosind ceva similar cu Bibliogram (un user script care preia tokenul oaspeților de la utilizator și îl transmite instanței publice).
La sfârșitul lunii ianuarie, X a oprit emiterea acestor tokenuri. Eliminarea ultimei modalități de acces a pus capăt lui Nitter ca serviciu public gratuit multi-utilizator, ceea ce a dus autorul să declare Nitter mort.
Unele instanțe s-au închis imediat după aceasta, altele au modificat codul pentru a economisi drastic utilizarea token-urilor existente, în special prin utilizarea acestora pentru obținerea listelor de tweet-uri ale conturilor, emitând mesaje de eroare pentru tot restul. La 26 februarie, durata de viață a celor mai recente token-uri de vizitatori a expirat, ceea ce a dus la oprirea funcționării tuturor instanțelor publice. Cu toate acestea, în sistemul de urmărire a erorilor se discută modalități care se referă, într-un fel sau altul, la conturile de vizitatori.
Una dintre soluțiile radicale ale problemei ar putea fi înlocuirea Twitter-ului prin crearea unui serviciu alternativ descentralizat pe baza ActivityPub și IPFS, unde identificatorul principal pentru fiecare mesaj este CID-ul său IPFS. Se poate imagina următoarea construcție multi-nivel.
Datele punctului 3 însă nu rezolvă problema neimplicării utilizatorilor Twitter în programul de înlocuire a Twitter-ului.
Pentru fiecare identificator de postare pe fiecare platformă centralizată, poate fi util să se mențină o afișare a acestuia în CID-ul IPFS, care acționează ca un cache, permițând fără a cunoaște textul propriu-zis al postului, dar cu cunoașterea identificatorului său centralizat, să se afle identificatorul său descentralizat. Atunci când se generează URI în IPFS (ceea ce poate fi realizat fără a încărca efectiv), textul postului trece printr-o procesare de canonizare care constă în plasarea datelor într-un container bazat pe HTML cu metadate ușor de citit de mașină, normalizarea unicode-ului, conversia în UTF-8, înlocuirea caracterelor de spațiu cu simple spații simple și înlocuirea tuturor link-urilor către posturi pe această și alte platforme care trec printr-o procedură similară cu URI în IPFS.
Fiecare dintre platforme are un document care poate fi citit de mașini, în care sunt descrise regulile de canonizare a postărilor, inclusiv numeroase servicii, al căror link este înlocuit cu un URI IPFS în postările acestei rețele. Fiecare postare din fiecare rețea este canonizată conform regulilor de canonizare a postărilor din acea rețea, valabile la momentul la care este datată postarea. În procesul de canonizare, dacă în postare există un link către o postare din una dintre platformele înlocuite, implementarea extrage un identificator centralizat din link și verifică existența acestuia în indexurile de încredere.
În cazul în care identificatorul există în index, implementarea folosește identificatorul descentralizat din indexuri. Dacă nu există, implementarea solicită postarea prin link, o canonizează și formează un identificator care poate fi inclus în indexuri. Implementarea nu este obligată să plaseze postarea solicitată în rețeaua descentralizată. Implementarea poate verifica corectitudinea identificatorului în index prin reproducerea locală a procesului. Implementarea indexului este obligată să verifice corectitudinea generării identificatorilor prin reproducerea locală a procesului.
Acest proces determinist permite generarea de linkuri nemodificabile către conținut, chiar și pentru tweeturi, ale căror postere încă nu participă în programul de înlocuire Twitter. Când o parte dintre acestea va încărca tweeturile lor în IPFS, algoritmul va genera pentru ele identificatori identici cu cei deja utilizați în linkurile către ele, cu condiția ca indexul să conțină corespondențe corecte și conținutul să nu fi fost modificat.
Sursa: opennet.ro
