La última instancia pública de Nitter ha dejado de funcionar. El proyecto Nitter desarrollaba un frontend libre para acceder a X.com/Twitter sin la imposición de JavaScript, analytics, rastreadores y servicios de terceros. El 31 de enero se interrumpió la emisión de tokens utilizados en Nitter para facilitar el acceso al contenido en X.com. El 26 de febrero expiró el tiempo de vida de los últimos tokens emitidos anteriormente, lo que llevó a la completa detención del funcionamiento de Nitter.
Después de la compra por parte de Elon Musk, Twitter (ahora renombrado como X) comenzó a implementar un conjunto de medidas técnicas y organizativas dirigidas a la monetización agresiva de la plataforma, que anteriormente se consideraba deficitaria. Entre los cambios, se implementó la tarifación de la información recibida por cada cuenta (se introdujeron límites para diferentes tipos de cuentas: 10,000 para los poseedores de la 'marca azul' de pago, 1,000 para las cuentas normales, 500 para las nuevas cuentas normales); las cuentas de 'desarrolladores' fueron trasladadas a la categoría de cuentas de pago con límites adecuados para la extracción masiva de datos (scraping); se detuvo la entrega de información a los usuarios sin cuentas.
En calidad de justificación se afirmó públicamente (2023-07-01) que esto son 'medidas emergentes temporales', relacionadas con el hecho de que la carga automatizada de datos por bots está deteriorando el servicio para los usuarios comunes. Antes de esto (2023-04-19) había insinuaciones hacia Microsoft, relacionadas con que esta empresa estaba utilizando ilegalmente los datos de Twitter para entrenar AI. Posteriormente (2023-11-17) se justificó la implementación de límites con la prometida lucha de Musk contra los bots.
Nitter era un proyecto de desarrollo de software para proteger a los usuarios de Twitter de ser monitoreados, que no envían mensajes, sino que solo leen contenido, proporcionando un sitio alternativo para ver Twitter, que no requiere ni cuenta ni JavaScript habilitado. Este tipo de software es, de hecho, un scraper y un intermediario, que en lugar de almacenar datos en una base de datos, los envía al usuario final (sin embargo, algunos datos de servicio se almacenan en Redis).
Así, el software Nitter:
Como resultado del análisis de las vías alternativas para continuar funcionando en nuevas condiciones, se descubrieron RSS y algunos puntos de entrada en syndication.twitter.com, que proporcionaban información a usuarios no registrados en formato JSON, y se utilizaban para integración con otras redes sociales. Durante un tiempo, Nitter obtuvo información a través de estas interfaces, pero luego también fueron cerradas. Después de eso, se encontró una forma de usar "cuentas de invitado" que tenían privilegios de lectura. Uno de los tipos de "cuentas de invitado" estaba destinado a su uso en dispositivos de Internet de las Cosas con navegadores recortados.
Pero Nitter utilizó otro tipo de "cuentas de invitado" que empleaban OAuth en lugar de cookies, se registraban a través de API y aparentemente eran utilizadas por una aplicación para Android. Este tipo de cuentas tiene límites de 500 solicitudes a la API en 15 minutos, y su "registro" está vinculado a IP (de una IP se puede registrar una "cuenta de invitado" en un día, pero una "cuenta" ya registrada se puede usar desde otras direcciones IP).
Tales "cuentas" (tokens de acceso) funcionaron durante 30 días. En ese momento, una solución adecuada al problema de registro masivo de cuentas temporales podría haber sido el crowdfunding de su registro por usuarios, usando algo similar a Bibliogram (un userscript que toma el token de invitado del usuario y lo transfiere a una instancia pública).
A finales de enero, X dejó de emitir tales tokens. La eliminación del último método de acceso selló el destino de Nitter como un servicio público gratuito y multipropietario, lo que llevó al autor a declarar a Nitter muerto.
Algunas instancias se cerraron de inmediato, mientras que otras modificaron el código para reducir drásticamente el uso de los tokens existentes, utilizando principalmente estos para obtener listas de tweets de cuentas, con mensajes de error para todo lo demás. El 26 de febrero, la vida útil de los últimos tokens de invitado expiró, lo que resultó en que todas las instancias públicas dejaron de funcionar. Sin embargo, en el tracker de errores se están discutiendo formas relacionadas de alguna manera con las cuentas de invitado.
Una de las soluciones más radicales al problema podría ser el reemplazo de Twitter mediante la creación de un servicio alternativo descentralizado basado en ActivityPub e IPFS, donde el identificador principal de cada mensaje es su CID de IPFS. Se puede imaginar la siguiente estructura multinivel:
Sin embargo, los datos del punto 3 no resuelven el problema de la falta de participación de los usuarios de Twitter en el programa de reemplazo de Twitter.
Para cada identificador de publicación en cada plataforma centralizada, puede ser conveniente mantener su visualización en CID de IPFS, que actúa como un caché, permitiendo sin conocer el texto de la publicación, pero conociendo su identificador centralizado, conocer su identificador descentralizado. Al generar URI en IPFS (lo que se puede hacer sin la carga real), el texto de la publicación pasa por una canonicalización, que implica colocar datos en un contenedor basado en HTML con metadatos legibles por máquina, normalización de Unicode, conversión a UTF-8, reemplazo de caracteres de espacio en blanco por espacios simples y reemplazo de todos los enlaces a publicaciones en esta y otras plataformas, que pasan por un procedimiento similar, por URI en IPFS.
Cada plataforma tiene un documento legible por máquina que describe las reglas de canonicidad de las publicaciones, incluidas múltiples servicios cuyos enlaces se reemplazan por URI IPFS en las publicaciones de esta red. Cada publicación en cada red se canoniza de acuerdo con las reglas de canonicidad de publicaciones de esa red, vigentes en el momento en que se fecha la propia publicación. Al canonizar, si hay un enlace a una publicación en una de las plataformas reemplazadas, la implementación extrae un identificador centralizado del enlace y verifica su existencia en los índices de confianza.
Si se encuentra en el índice, la implementación utiliza el identificador descentralizado de los índices. Si no está presente, la implementación solicita la publicación mediante el enlace, la canoniza y genera un identificador que puede colocar en los índices. La implementación no está obligada a colocar la publicación solicitada en la red descentralizada. La implementación puede verificar la validez del identificador en el índice mediante la reproducción local del proceso. La implementación del índice está obligada a verificar la validez de la generación de identificadores mediante la reproducción local del proceso.
Este proceso determinista permitirá generar enlaces invariables al contenido, incluso para tweets cuyos pósters aún no participan en el programa de reemplazo de Twitter. Cuando algunos de ellos comiencen a cargar sus tweets en IPFS, el algoritmo generará identificadores para ellos, idénticos a los que ya se utilizan en los enlaces hacia ellos, siempre que el índice contenga representaciones válidas y el contenido mismo no haya cambiado.
Fuente: opennet.ru
