La última instancia pública de Nitter ha caído en mal estado. El proyecto Nitter desarrolló una interfaz gratuita para acceder a X.com/Twitter sin imponer JavaScript, análisis, rastreadores ni servicios de terceros. El 31 de enero, se detuvo la emisión de tokens utilizados por Nitter para brindar acceso al contenido de X.com. El 26 de febrero, el último de los tokens emitidos anteriormente expiró, lo que provocó el cese total de Nitter.
Después de ser comprada por Elon Musk, Twitter (ahora rebautizada como X) comenzó a implementar una serie de medidas técnicas y organizativas destinadas a monetizar agresivamente la plataforma, que anteriormente se consideraba no rentable. Entre los cambios, se implementaron tarifas para la información recibida por cada cuenta (se introdujeron límites para diferentes tipos de cuentas: 10000 para los titulares de una "marca de verificación azul" pagada, 1000 para las regulares, 500 para las nuevas regulares); las cuentas de “desarrollador” con límites adecuados para la extracción masiva de datos (scraping) se han transferido a la categoría de cuentas pagas; Se ha detenido la distribución de información a usuarios sin cuentas.
La justificación se hizo públicamente (2023/07/01) de que se trata de “medidas de emergencia temporales” debido a que la carga automatizada de datos por parte de bots conduce al deterioro del servicio para los usuarios comunes. Antes de esto (2023/04/19), hubo insinuaciones contra Microsoft relacionadas con el hecho de que la empresa estaba utilizando ilegalmente datos de Twitter para entrenar IA. Posteriormente (2023/11/17) la introducción de límites se justificó por la lucha contra los bots prometida por Musk.
Nitter fue un proyecto para desarrollar software antivigilancia para usuarios de Twitter que no envían mensajes, solo leen contenido, proporcionándoles un sitio alternativo para ver Twitter que no requiere una cuenta ni JavaScript habilitado. Dicho software es en realidad un raspador e intermediario que, en lugar de almacenar datos en la base de datos, los envía al usuario final (sin embargo, algunos datos del servicio se almacenan en caché en Redis).
Así, el software Nitter:
Como resultado del análisis de soluciones para continuar trabajando en las 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 la integración con otras redes sociales. Durante algún tiempo Nitter recibió información a través de estas interfaces, pero luego fueron cerradas. Después de esto, se encontró una manera de utilizar “cuentas de invitados” que tenían privilegios de lectura. Un tipo de “cuenta de invitado” estaba diseñado para su uso en dispositivos de Internet de las cosas con navegadores simplificados.
Pero Nitter usaba un tipo diferente de "cuenta de invitado" que usaba OAuth en lugar de cookies, se registraba a través de la API y, al parecer, era utilizada por una aplicación de Android. Este tipo de cuenta está limitada a 500 solicitudes de API cada 15 minutos y su "registro" está vinculado a... dirección IP (desde una IP se puede registrar una “cuenta de invitado” por día, pero una “cuenta” ya registrada se puede utilizar desde otras direcciones IP).
Estas “cuentas” (tokens de acceso) estuvieron operativas durante 30 días. En ese momento, una solución adecuada al problema del registro masivo de cuentas temporales sería hacer que los usuarios realicen su registro mediante crowdsourcing, utilizando algo similar a Bibliogram (un script de usuario que toma el token de invitado del usuario y lo transfiere a una instancia pública). .
A finales de enero, X dejó de emitir dichos tokens. La eliminación de este último método de acceso puso fin a Nitter como servicio público, gratuito y multiusuario, lo que provocó que el autor declarara a Nitter muerto.
Algunas instancias se cerraron inmediatamente después de esto, otras modificaron el código para ahorrar en gran medida el uso de tokens existentes, en particular con su uso principal para obtener listas de tweets de cuentas, y se emitieron mensajes de error para todo lo demás. El 26 de febrero, los últimos tokens de invitado expiraron, lo que provocó que todas las instancias públicas dejaran de funcionar. Sin embargo, el rastreador de errores analiza problemas que de alguna manera afectan las cuentas de invitados.
Una de las soluciones radicales al problema podría ser reemplazar Twitter mediante la creación de un servicio descentralizado alternativo basado en ActivityPub e IPFS, donde el identificador principal de cada mensaje sea su CID IPFS. Podemos imaginar la siguiente estructura multinivel:
Estos tres puntos, sin embargo, no solucionan el problema de la no participación de los usuarios de Twitter en el programa de sustitución de Twitter.
Para cada identificador de publicación en cada plataforma centralizada, puede ser recomendable mantener su mapeo en el CID de IPFS, que actúa como un caché que le permite conocer su identificador descentralizado sin conocer el texto de la publicación en sí, pero conociendo su identificador centralizado. . Al generar un URI en IPFS (que se puede hacer sin necesidad de completarlo), el texto de la publicación se somete a una canonicalización, que consiste en colocar los datos en un contenedor basado en HTML con metadatos legibles por máquina, normalización Unicode, conversión a UTF-8, reemplazo caracteres de espacio en blanco con espacios simples simples y reemplazando todos los enlaces a publicaciones en esta y otras plataformas que pasan por un procedimiento similar con URI en IPFS.
Cada plataforma tiene un documento legible por máquina que describe las reglas para canonicalizar publicaciones, incluidos muchos servicios cuyos enlaces se reemplazan con URI IPFS en publicaciones en esa red. Cada cargo en cada red se canonicaliza de acuerdo con las reglas para la canonicalización de cargos en esa red vigentes en el momento en que está fechado el cargo en sí. Durante la canonicalización, si una publicación contiene un enlace a una publicación en una de las plataformas reemplazadas, la implementación extrae un identificador centralizado del enlace y verifica su presencia en índices confiables.
Cuando está presente en un índice, la implementación utiliza el identificador descentralizado de los índices. Si está ausente, la implementación solicita la publicación por referencia, la canonicaliza y genera un identificador que se puede colocar en índices. La implementación no está obligada a colocar el puesto solicitado en la red descentralizada. Una implementación puede verificar la validez del identificador en el índice reproduciendo el proceso localmente. Es responsabilidad de la implementación del índice verificar la correcta generación de identificadores reproduciendo localmente el proceso.
Este proceso determinista permitirá la generación de enlaces de contenido inmutables incluso para tweets cuyos carteles aún no participan en el programa de reemplazo de Twitter. Cuando algunos de ellos suben sus tweets a IPFS, el algoritmo generará identificadores idénticos a los que ya se utilizan en los enlaces a ellos, siempre que el índice contenga las asignaciones correctas y el contenido en sí no haya cambiado.
Fuente: opennet.ru
