A última instancia pública de Nitter caeu en mal estado. O proxecto Nitter desenvolveu un frontend gratuíto para acceder a X.com/Twitter sen impoñer JavaScript, análises, rastreadores e servizos de terceiros. O 31 de xaneiro detívose a emisión de tokens utilizados por Nitter para proporcionar acceso ao contido en X.com. O 26 de febreiro caducou o último dos tokens emitidos anteriormente, o que provocou unha parada completa de Nitter.
Despois de ser comprado por Elon Musk, Twitter (agora renomeado X) comezou a implementar un conxunto de medidas técnicas e organizativas destinadas a monetizar de forma agresiva a plataforma, que antes se consideraba non rendible. Entre os cambios, implantáronse tarifas para a información recibida por cada conta (introducíronse límites para diferentes tipos de contas: 10000 para os titulares dunha "marca azul" de pago, 1000 para as habituais, 500 para as novas regulares); As contas de "desenvolvedores" con límites axeitados para a extracción masiva de datos (scraping) foron transferidas á categoría de pagos; Detívose a distribución de información aos usuarios sen contas.
A xustificación expúxose publicamente (2023-07-01) que se trata de "medidas de emerxencia temporais" debido a que a carga automatizada de datos por parte de bots leva a un deterioro do servizo para os usuarios comúns. Antes disto (2023-04-19), houbo insinuacións contra Microsoft relacionadas co feito de que a compañía estaba a usar ilegalmente os datos de Twitter para adestrar a IA. Máis tarde (2023-11-17), a introdución de límites foi xustificada pola loita contra os bots prometida por Musk.
Nitter foi un proxecto para desenvolver software para protexer aos usuarios de Twitter que non envían mensaxes, senón que só len contido, de ser rastreados, proporcionándolles un sitio alternativo para ver Twitter que non require unha conta nin JavaScript activado. Este software é en realidade un raspador e intermediario que, en lugar de almacenar datos na base de datos, envíaos ao usuario final (non obstante, algúns datos do servizo están almacenados na caché en Redis).
Así o software Nitter:
Como resultado da análise de solucións alternativas para continuar o traballo nas novas condicións, descubriuse RSS e algúns puntos de entrada en syndication.twitter.com que proporcionaban información aos usuarios non rexistrados en formato JSON e que se utilizaron para a integración con outras redes sociais. Durante algún tempo Nitter recibiu información a través destas interfaces, pero despois pecháronse. Despois disto, atopouse un xeito de usar "contas de convidados" que tiñan privilexios de lectura. Un tipo de tipo de "conta de convidado" estaba pensado para o seu uso en dispositivos de Internet das cousas con navegadores reducidos.
Pero Nitter empregou un tipo diferente de "contas de convidado" que usaban OAuth en lugar de Cookie, rexistradas a través dunha API e que aparentemente a aplicación usaba para AndroidEste tipo de conta ten un límite de 500 solicitudes API cada 15 minutos e o seu "rexistro" está vinculado a enderezo IP (desde un IP podes rexistrar unha "conta de convidado" por día, pero unha "conta" xa rexistrada pódese usar desde outros enderezos IP).
Tales "contas" (fichas de acceso) estiveron operativas durante 30 días. Nese momento, unha solución axeitada ao problema do rexistro masivo de contas temporais sería o crowdsourcing do seu rexistro por parte dos usuarios, utilizando algo semellante a Bibliogram (un script de usuario que toma o token de convidado do usuario e o transfire a unha instancia pública). .
A finais de xaneiro, X deixou de emitir tales fichas. A eliminación deste último método de acceso puxo fin a Nitter como servizo público, gratuíto e multiusuario, o que provocou que o autor declarase a morte de Nitter.
Algúns casos pecháronse inmediatamente despois disto, outros modificaron o código para salvar severamente o uso dos tokens existentes, en particular co seu uso principal para obter listas de chíos das contas, emitindo mensaxes de erro para todo o demais. O 26 de febreiro caducaron as últimas fichas de convidado, o que provocou que todas as instancias públicas deixasen de funcionar. Non obstante, o rastreador de erros analiza problemas que afectan dalgún xeito ás contas de convidados.
Unha das solucións radicais ao problema podería ser a substitución de Twitter mediante a creación dun servizo descentralizado alternativo baseado en ActivityPub e IPFS, onde o principal identificador de cada mensaxe é o seu CID IPFS. Podemos imaxinar a seguinte estrutura multinivel:
Estes 3 puntos, porén, non solucionan o problema da non participación dos usuarios de Twitter no programa de substitución de Twitter.
Para cada identificador de publicación en cada plataforma centralizada, pode ser recomendable manter o seu mapeo no CID de IPFS, que actúa como caché que permite coñecer o seu identificador descentralizado sen coñecer o propio texto da publicación, pero coñecendo o seu identificador centralizado. . Cando se xera un URI en IPFS (que se pode facer sen encher realmente), o texto da publicación sofre unha canonización, que consiste en colocar os datos nun contedor baseado en HTML con metadatos lexibles por máquina, normalización Unicode, conversión a UTF-8, substituíndo caracteres de espazo en branco con espazos sinxelos e substituíndo todas as ligazóns a publicacións nesta e noutras plataformas que pasan por un procedemento similar con URIs en IPFS.
Cada plataforma ten un documento lexible por máquina que describe as regras para canonizar publicacións, incluíndo moitos servizos cuxas ligazóns son substituídas por URI IPFS nas publicacións desa rede. Cada posto de cada rede está canonizado de acordo coas regras de canonización de postos desa rede vixentes no momento no que estea datada a propia publicación. Durante a canonización, se unha publicación contén unha ligazón a unha publicación nunha das plataformas substituídas, a implementación extrae un identificador centralizado da ligazón e verifica a súa presenza en índices de confianza.
Cando está presente nun índice, a implementación usa o identificador descentralizado dos índices. En caso de faltar, a implementación solicita a publicación por referencia, canoniza e xera un identificador que se pode colocar en índices. A implantación non está obrigada a colocar o posto solicitado na rede descentralizada. Unha implementación pode verificar a validez do identificador no índice reproducindo o proceso localmente. É responsabilidade da implementación do índice verificar a correcta xeración de identificadores reproducindo localmente o proceso.
Este proceso determinista permitirá a xeración de ligazóns de contido inmutable mesmo para chíos cuxos carteis aínda non estean participando no programa de substitución de Twitter. Cando algúns deles suban os seus chíos a IPFS, o algoritmo xerará para eles identificadores idénticos aos que xa se usan nas ligazóns a eles, sempre que o índice conteña as asignacións correctas e o contido en si non se modifique.
Fonte: opennet.ru
