L'ultimo degli esemplari pubblici di Nitter è andato in malora. Il progetto Nitter sviluppava un front-end gratuito per accedere a X.com/Twitter senza l'imposizione di JavaScript, analisi, tracker e servizi di terze parti. Il 31 gennaio è stata interrotta l'emissione dei token utilizzati in Nitter per facilitare l'accesso ai contenuti su X.com. Il 26 febbraio è scaduto il tempo di vita degli ultimi token precedentemente emessi, portando a un arresto completo del funzionamento di Nitter.
Dopo l'acquisto da parte di Elon Musk, Twitter (ora ribattezzato X) ha iniziato a implementare una serie di misure tecniche e organizzative volte a una monetizzazione aggressiva della piattaforma, precedentemente considerata in perdita. Tra le modifiche ci sono stati nuovi costi per le informazioni ricevute da ciascun account (introdotti limiti per diversi tipi di account — 10000 per i possessori del «marchio blu» a pagamento, 1000 per gli account normali, 500 per i nuovi normali); gli account di «sviluppatori» sono stati spostati nella categoria a pagamento con limiti adatti all'estrazione di dati di massa (scraping); è stata interrotta la fornitura di informazioni agli utenti senza account.
A giustificazione si è pubblicamente affermato (2023-07-01) che si trattava di «misure straordinarie temporanee», legate al fatto che il caricamento automatico dei dati tramite bot comporta un deterioramento del servizio per gli utenti normali. In precedenza (2023-04-19) erano emerse insinuazioni nei confronti di Microsoft, legate al fatto che tale azienda utilizzasse illegalmente i dati di Twitter per l'addestramento dell'AI. Successivamente (2023-11-17) l'introduzione dei limiti è stata giustificata dalla promessa di Musk di combattere i bot.
Nitter era un progetto per lo sviluppo di software destinato a proteggere gli utenti di Twitter dalla sorveglianza, che non inviano messaggi, ma leggono solo contenuti, fornendo loro un sito alternativo per visualizzare Twitter senza necessità di un account o di JavaScript attivato. Tale software è di fatto un scraper e un intermediario, che invece di salvare i dati in un database li invia all'utente finale (tuttavia alcuni dati di servizio vengono memorizzati in cache in Redis).
Pertanto, il software Nitter:
Come risultato dell'analisi dei modi per continuare a funzionare in nuove condizioni, sono stati scoperti i feed RSS e alcuni punti di ingresso su syndication.twitter.com, che restituivano informazioni a utenti non registrati in formato JSON e venivano utilizzati per l'integrazione con altri social network. Per un certo periodo, Nitter ha ricevuto informazioni tramite queste interfacce, ma poi anche esse sono state chiuse. Successivamente, è stato trovato un modo per utilizzare "account ospiti", che avevano privilegi di lettura. Uno dei tipi di "account ospiti" era previsto per l'uso su dispositivi IoT con browser ridotti.
Ma Nitter utilizza un altro tipo di "account ospiti", che impiega OAuth invece dei cookie, si registra tramite API e viene apparentemente utilizzato da un'applicazione Android. Questo tipo di account ha limiti di 500 richieste all'API in 15 minuti e la sua "registrazione" è legata a indirizzo IP (da un IP si può registrare un "account ospite" in un giorno, ma un "account" già registrato può essere utilizzato da altri indirizzi IP).
Tali "account" (token di accesso) erano operativi per 30 giorni. A quel tempo, una soluzione adeguata al problema della registrazione massiva di account temporanei sarebbe stata il crowdsourcing della loro registrazione da parte degli utenti, utilizzando qualcosa di simile a Bibliogram (user script che prende il token ospite dall'utente e lo passa a un esemplare pubblico).
Alla fine di gennaio, X ha smesso di emettere tali token. L'eliminazione dell'ultima modalità di accesso ha segnato la fine di Nitter come servizio pubblico gratuito multi-utente, a seguito della quale l'autore ha dichiarato Nitter morto.
Alcuni esempi si sono subito chiusi dopo questo, altri hanno modificato il codice per un uso severo dei token esistenti, in particolare con un uso prevalente per la ricezione di elenchi di tweet degli account, mentre per il resto venivano emessi messaggi di errore. Il 26 febbraio, la vita utile degli ultimi token ospiti è scaduta, portando alla cessazione del funzionamento di tutti gli esempi pubblici. Tuttavia, nel bug tracker si discutono modi che riguardano in qualche modo gli account ospiti.
Una delle soluzioni radicali al problema potrebbe essere il twittersostituto tramite la creazione di un servizio alternativo decentralizzato basato su ActivityPub e IPFS, dove l'identificatore principale di ogni messaggio è il suo IPFS CID. Si può immaginare la seguente struttura multilivello:
Tuttavia, i dati del punto 3 non risolvono il problema della non partecipazione degli utenti di Twitter al programma di twittersostituzione.
Per ogni identificatore del post su ciascuna piattaforma centralizzata, può essere opportuno mantenere una mappatura al suo IPFS CID, che funge da cache, consentendo di conoscere il suo identificatore decentralizzato senza conoscere il testo stesso del post, ma conoscendo il suo identificatore centralizzato. Durante la generazione dell'URI in IPFS (cosa che può essere fatta senza un reale caricamento), il testo del post subisce una canonizzazione, che consiste nel collocare i dati in un contenitore basato su HTML con metadati leggibili da macchina, normalizzazione del Unicode, conversione in UTF-8, sostituzione dei caratteri di spaziatura con singoli spazi normali e sostituzione di tutti i link ai post di questa e di altre piattaforme, che seguono una procedura simile, con URI in IPFS.
Ogni piattaforma dispone di un documento leggibile dalle macchine, in cui sono descritte le regole di canonicalizzazione dei post, incluse molteplici servizi, i cui link vengono sostituiti con URI IPFS nei post di questa rete. Ogni post in ogni rete viene canonicalizzato in base alle regole di canonicalizzazione dei post di quella rete, vigenti al momento in cui è datato il post stesso. In fase di canonicalizzazione, se il post contiene un link a un post di una delle piattaforme sostituite, l'implementazione estrae dall'URL un identificatore centralizzato e verifica la sua presenza negli indici fidati.
In caso di presenza nell'indice, l'implementazione utilizza l'identificatore decentralizzato dagli indici. In assenza di questo, l'implementazione richiede il post tramite il link, lo canonicalizza e genera un identificatore da inserire negli indici. L'implementazione non è obbligata a inserire il post richiesto nella rete decentralizzata. L'implementazione può verificare l'affidabilità dell'identificatore nell'indice, riproducendo localmente il processo. L'implementazione dell'indice è obbligata a verificare l'accuratezza della generazione degli identificatori riproducendo localmente il processo.
Questo processo deterministico permette di generare link immutabili ai contenuti anche per i tweet i cui poster non partecipano ancora al programma di sostituzione di Twitter. Quando alcuni di essi inizieranno a caricare i propri tweet su IPFS, l'algoritmo genererà per loro identificatori identici a quelli già utilizzati nei link a essi, a condizione che l'indice contenga le corrette corrispondenze e che il contenuto stesso non sia cambiato.
Fonte: opennet.ru
