L'última instància pública de Nitter ha caigut en mal estat. El projecte Nitter va desenvolupar una interfície gratuïta per accedir a X.com/Twitter sense imposar JavaScript, analítiques, rastrejadors i serveis de tercers. El 31 de gener, es va aturar l'emissió de fitxes utilitzades per Nitter per proporcionar accés al contingut a X.com. El 26 de febrer, va caducar l'última de les fitxes emeses anteriorment, cosa que va provocar una aturada completa de Nitter.
Després de ser comprat per Elon Musk, Twitter (ara rebatejat X) va començar a implementar un conjunt de mesures tècniques i organitzatives destinades a monetitzar de manera agressiva la plataforma, que abans es considerava no rendible. Entre els canvis, es van implantar tarifes per a la informació rebuda per cada compte (es van introduir límits per a diferents tipus de comptes: 10000 per als titulars d'una “marca blava” de pagament, 1000 per als habituals, 500 per als nous regulars); Els comptes de "desenvolupador" amb límits adequats per a l'extracció massiva de dades (scraping) s'han transferit a la categoria de pagaments; S'ha aturat la distribució d'informació als usuaris sense comptes.
Es va justificar públicament (2023-07-01) que es tracta de "mesures d'emergència temporals" a causa del fet que la càrrega automatitzada de dades per part dels robots comporta un deteriorament del servei per als usuaris corrents. Abans d'això (2023-04-19), hi va haver insinuacions contra Microsoft relacionades amb el fet que l'empresa estava utilitzant il·legalment dades de Twitter per entrenar IA. Més tard (2023-11-17) la introducció de límits es va justificar per la lluita contra els bots promesa per Musk.
Nitter va ser un projecte per desenvolupar programari per protegir els usuaris de Twitter que no envien missatges, sinó que només llegeixen contingut, de ser rastrejats proporcionant-los un lloc alternatiu per veure Twitter que no requereix un compte o JavaScript habilitat. Aquest programari és en realitat un raspador i un intermediari que, en lloc d'emmagatzemar dades a la base de dades, les envia a l'usuari final (no obstant això, algunes dades del servei s'emmagatzemen a la memòria cau a Redis).
Així, el programari Nitter:
Com a resultat de l'anàlisi de solucions alternatives per continuar treballant en les noves condicions, es van descobrir RSS i alguns punts d'entrada a syndication.twitter.com que proporcionaven informació als usuaris no registrats en format JSON i s'utilitzaven per a la integració amb altres xarxes socials. Durant un temps Nitter va rebre informació a través d'aquestes interfícies, però després es van tancar. Després d'això, es va trobar una manera d'utilitzar "comptes de convidat" que tenien privilegis de lectura. Un tipus de "compte de convidat" estava pensat per utilitzar-lo en dispositius d'Internet de les coses amb navegadors reduïts.
Però Nitter utilitzava un tipus diferent de "comptes de convidat" que utilitzaven OAuth en comptes de Cookie, registrats a través d'una API, i que aparentment l'aplicació utilitzava per a AndroidAquest tipus de compte té un límit de 500 sol·licituds API cada 15 minuts i el seu "registre" està lligat a adreça IP (des d'una IP podeu registrar un "compte convidat" per dia, però es pot utilitzar un "compte" ja registrat des d'altres adreces IP).
Aquests "comptes" (fitxers d'accés) van estar operatius durant 30 dies. Aleshores, una solució adequada al problema del registre massiu de comptes temporals seria fer-ne un crowdsource per part dels usuaris, utilitzant alguna cosa semblant a Bibliogram (un script d'usuari que pren el testimoni de convidat de l'usuari i el transfereix a una instància pública). .
A finals de gener, X va deixar d'emetre aquestes fitxes. L'eliminació d'aquest últim mètode d'accés va posar fi a Nitter com a servei públic, gratuït i multiusuari, la qual cosa va fer que l'autor declarés Nitter mort.
Alguns casos es van tancar immediatament després d'això, d'altres van modificar el codi per estalviar greument l'ús de fitxes existents, en particular amb el seu ús principal per obtenir llistes de tuits dels comptes, amb missatges d'error per a tota la resta. El 26 de febrer, les últimes fitxes de convidat van caducar, fet que va fer que totes les instàncies públiques deixin de funcionar. Tanmateix, el rastrejador d'errors analitza problemes que afecten d'alguna manera els comptes de convidats.
Una de les solucions radicals al problema podria ser la substitució de Twitter mitjançant la creació d'un servei alternatiu descentralitzat basat en ActivityPub i IPFS, on l'identificador principal de cada missatge és el seu CID IPFS. Podem imaginar la següent estructura multinivell:
Aquests 3 punts, però, no resolen el problema de la no participació dels usuaris de Twitter en el programa de substitució de Twitter.
Per a cada identificador de publicació de cada plataforma centralitzada, pot ser aconsellable mantenir el seu mapeig en el CID de l'IPFS, que actua com una memòria cau que permet conèixer el seu identificador descentralitzat sense conèixer el text de la publicació en si, però coneixent el seu identificador centralitzat. . Quan es genera una URI en IPFS (que es pot fer sense omplir realment), el text de la publicació se sotmet a una canonització, que consisteix a col·locar les dades en un contenidor basat en HTML amb metadades llegibles per màquina, normalització Unicode, conversió a UTF-8, substitució caràcters d'espai en blanc amb espais senzills i substituint tots els enllaços a publicacions d'aquesta i altres plataformes que passen per un procediment similar amb URIs a IPFS.
Cada plataforma té un document llegible per màquina que descriu les regles per a la canonització de publicacions, inclosos molts serveis els enllaços dels quals es substitueixen per URI IPFS a les publicacions d'aquesta xarxa. Cada publicació de cada xarxa està canonitzada d'acord amb les normes de canonització de publicacions d'aquesta xarxa vigents en el moment en què es data la publicació. Durant la canonització, si una publicació conté un enllaç a una publicació en una de les plataformes substituïdes, la implementació extreu un identificador centralitzat de l'enllaç i comprova la seva presència als índexs de confiança.
Quan està present en un índex, la implementació utilitza l'identificador descentralitzat dels índexs. En cas d'absència, la implementació demana el missatge per referència, el canonitza i genera un identificador que es pot col·locar en índexs. La implementació no està obligada a col·locar el lloc sol·licitat a la xarxa descentralitzada. Una implementació pot verificar la validesa de l'identificador a l'índex reproduint el procés localment. És responsabilitat de la implementació de l'índex verificar la correcta generació d'identificadors mitjançant la reproducció local del procés.
Aquest procés determinista permetrà generar enllaços de contingut immutable fins i tot per a tuits els pòsters dels quals encara no participen en el programa de substitució de Twitter. Quan alguns d'ells carreguen els seus tuits a IPFS, l'algoritme els generarà identificadors idèntics als que ja s'utilitzen en els enllaços a ells, sempre que l'índex contingui els mapes correctes i el contingut en si no hagi canviat.
Font: opennet.ru
