L'ultimo dei funzionari pubblici di Nitter è venuto meno. Il progetto Nitter ha sviluppato un frontend libero per accedere a X.com/Twitter senza l'imposizione di JavaScript, analytics, tracker e servizi di terze parti. Il 31 gennaio è stata interrotta l'emissione di token utilizzati in Nitter per regolare l'accesso ai contenuti su X.com. Il 26 febbraio è scaduto il termine di vita degli ultimi token precedentemente emessi, portando a una totale fermata del funzionamento di Nitter.
Dopo l'acquisto da parte di Elon Musk, Twitter (ora ribattezzato X) ha iniziato a implementare un insieme di misure tecniche e organizzative intese a monetizzare aggressivamente una piattaforma precedentemente considerata non redditizia. Tra le modifiche è stata introdotta una tariffazione per le informazioni ricevute da ciascun account (sono stati stabiliti limiti per diversi tipi di account — 10.000 per gli detentori della «spunta blu» a pagamento, 1.000 per i normali, 500 per i nuovi normali); gli account degli «sviluppatori» sono stati spostati nella categoria a pagamento con limiti adatti per l'estrazione massiva di dati (scraping); è stata interrotta la fornitura di informazioni agli utenti senza account.
A scopo giustificativo è stato affermato pubblicamente (2023-07-01) che si tratta di 'misure d'emergenza temporanee', legate al fatto che il caricamento automatizzato dei dati da parte dei bot porta a un deterioramento del servizio per gli utenti normali. In precedenza (2023-04-19) c'erano insinuazioni nei confronti di Microsoft, relative al fatto che questa azienda utilizzasse illegalmente i dati di Twitter per addestrare l'IA. Successivamente (2023-11-17) l'introduzione dei limiti è stata giustificata dalla promessa di Musk di combattere i bot.
Nitter era un progetto per sviluppare software volto a proteggere gli utenti di Twitter da sorveglianza, permettendo a coloro che leggono contenuti senza inviare messaggi di accedere a un sito alternativo per visualizzare Twitter, senza necessità di un account o JavaScript attivo. Tale software fungeva essenzialmente da scraper e intermediario, che invece di salvare i dati in un database, li inviava direttamente all'utente finale (tuttavia, alcuni dati di servizio vengono memorizzati nella cache in Redis).
Pertanto, il software Nitter:
A seguito dell'analisi delle vie alternative per proseguire l'attività in nuove condizioni, sono stati individuati alcuni punti di accesso su syndication.twitter.com che consegnavano informazioni a utenti non registrati in formato JSON e venivano utilizzati per l'integrazione con altri social media. Per un certo periodo Nitter ha ricevuto informazioni tramite queste interfacce, ma anche queste sono state chiuse. Successivamente, è stato trovato un modo per utilizzare "account ospiti", aventi privilegi di lettura. Uno dei tipi di "account ospiti" era destinato all'uso su dispositivi IoT con browser ridotti.
Tuttavia, Nitter utilizzava un altro tipo di "account ospiti" che impiegava OAuth invece dei cookie, si registrava tramite API e sembrava essere utilizzato dall'app per Android. Questo tipo di account ha dei limiti di 500 richieste API in 15 minuti, e la sua "registrazione" è legata a indirizzo IP (da un singolo IP si può registrare un "account ospite" in un giorno, ma un account già registrato può essere utilizzato da altri indirizzi IP).
Questi "account" (token di accesso) sono stati attivi per 30 giorni. In quel momento, una soluzione adeguata al problema della registrazione di massa di account temporanei avrebbe potuto essere il crowdsourcing della loro registrazione da parte degli utenti, utilizzando qualcosa di simile a Bibliogram (uno user script che acquisisce il token guest dall'utente e lo trasferisce a un'istanza pubblica).
Alla fine di gennaio X ha interrotto l'emissione di tali token. L'eliminazione dell'ultima forma di accesso ha segnato la fine di Nitter come servizio pubblico gratuito multiutente, portando l'autore a dichiarare Nitter morto.
Parte delle istanze si sono chiuse immediatamente dopo, altre hanno modificato il codice per ridurre al minimo l'utilizzo dei token esistenti, in particolare privilegiando il loro uso per ottenere elenchi di tweet degli account, con messaggi di errore per tutto il resto. Il 26 febbraio, la vita utile degli ultimi token guest è scaduta, portando alla cessazione del funzionamento di tutte le istanze pubbliche. Tuttavia, nel bug tracker si discutono modi che riguardano in qualche modo gli account guest.
Una delle soluzioni fondamentali al problema potrebbe essere la creazione di un servizio alternativo decentralizzato basato su ActivityPub e IPFS, dove l'identificatore principale di ogni messaggio è il suo CID IPFS. Si può immaginare la seguente struttura multilivello:
Tuttavia, i dati dei punti 3 non risolvono il problema della mancata partecipazione degli utenti di Twitter al programma di Twitter replacement.
Per ogni identificatore di post su ogni piattaforma centralizzata, può essere utile mantenere la visualizzazione del suo IPFS CID, che funge da cache e consente di risalire al suo identificatore decentralizzato senza conoscere il testo del post, ma solo il suo identificatore centralizzato. Durante la generazione dell'URI in IPFS (che può essere effettuata senza un effettivo caricamento), il testo del post viene sottoposto a canonicalizzazione, che consiste nel posizionare i dati in un contenitore basato su HTML con metadati leggibili dalle macchine, normalizzazione Unicode, conversione in UTF-8, sostituzione dei caratteri di spazio con singoli spazi e sostituzione di tutti i collegamenti ai post su questa e altre piattaforme, che seguono una procedura analoga, con URI in IPFS.
Ogni piattaforma ha un documento leggibile dalla macchina che descrive le regole di canonicalizzazione dei post, inclusi numerosi servizi i cui link vengono sostituiti con URI IPFS nei post di questa rete. Ogni post in ogni rete viene canonicalizzato secondo le regole di canonicalizzazione delle pubblicazioni in quella rete, valide al momento della data del post stesso. Durante la canonicalizzazione, se un post contiene un link a un post in una delle piattaforme sostituite, l'implementazione estrae un identificatore centralizzato dal link e verifica la sua esistenza negli indici di fiducia.
In caso di presenza nell'indice, l'implementazione utilizza l'identificatore decentralizzato degli indici. In mancanza, l'implementazione richiede il post tramite il link, lo canonicalizza e genera un identificatore che può essere inserito negli indici. L'implementazione non è obbligata a inserire il post richiesto in una rete decentralizzata. L'implementazione può verificare la correttezza dell'identificatore nell'indice tramite la riproduzione locale del processo. L'implementazione dell'indice è tenuta a verificare la correttezza della generazione degli identificatori tramite la riproduzione locale del processo.
Questo processo deterministico consente di generare link immutabili ai contenuti anche per i tweet dei quali i poster non partecipano ancora al programma di sostituzione di Twitter. Quando parte di essi inizierà a caricare i propri tweet su IPFS, l'algoritmo genererà per loro identificativi identici a quelli già utilizzati nei link, a condizione che l'indice contenga le corrette corrispondenze e il contenuto stesso non sia cambiato.
Fonte: opennet.ru
