A última instância pública do Nitter tornou-se obsoleta. O projeto Nitter desenvolveu um frontend livre para acessar o X.com/Twitter sem a imposição de JavaScript, análises, rastreadores e serviços de terceiros. Em 31 de janeiro, foi interrompida a emissão de tokens usados no Nitter para facilitar o acesso ao conteúdo no X.com. Em 26 de fevereiro, expirou o tempo de vida dos últimos tokens emitidos, resultando na paralisação total do Nitter.
Após a compra por Elon Musk, o Twitter (agora rebatizado de X) começou a implementar um conjunto de medidas técnicas e organizacionais voltadas para a monetização agressiva da plataforma, antes considerada deficitária. Entre as mudanças, foi implementada a tarifação das informações recebidas por cada conta (limites estabelecidos para diferentes tipos de contas — 10.000 para detentores do ‘selo azul’ pago, 1.000 para normais, 500 para novas normais); contas de ‘desenvolvedores’ foram convertidas em contas pagas com limites adequados para extração massiva de dados (scraping); a entrega de informações aos usuários sem conta foi interrompida.
Como justificativa, foi afirmado publicamente (2023-07-01) que isso eram 'medidas emergenciais temporárias', pois o carregamento automatizado de dados por bots estava prejudicando o serviço para usuários normais. Antes disso (2023-04-19), houve insinuações contra a Microsoft, relacionadas ao suposto uso ilegal de dados do Twitter para treinar IA. Mais tarde (2023-11-17), a introdução dos limites foi justificada pela prometida luta de Musk contra os bots.
O Nitter era um projeto de desenvolvimento de software voltado para proteger os usuários do Twitter da vigilância, permitindo que aqueles que apenas leem o conteúdo, mas não enviam mensagens, tenham um site alternativo para visualizar o Twitter, sem a necessidade de conta ou JavaScript ativado. Esse software funciona na verdade como um scraper e intermediário, que, em vez de armazenar dados em um banco de dados, os envia diretamente ao usuário final (embora alguns dados operacionais sejam armazenados em cache no Redis).
Assim, o software Nitter:
Após a análise de alternativas para continuar funcionando em novas condições, foram encontrados RSS e alguns pontos de entrada em syndication.twitter.com, que forneciam informações a usuários não registrados em formato JSON, e que eram utilizados para integração com outras redes sociais. Por algum tempo, o Nitter obteve informações por meio dessas interfaces, mas elas também foram desativadas. Depois disso, foi encontrado um método de utilização de 'contas de convidado', que tinham privilégios de leitura. Um dos tipos de 'contas de convidado' era destinado ao uso em dispositivos de internet das coisas com navegadores limitados.
Mas o Nitter utilizou um outro tipo de 'contas de convidado', que aplicavam OAuth em vez de Cookies, registravam-se através da API e eram aparentemente utilizadas pelo aplicativo para Android. Esse tipo de conta possui limites de 500 requisições à API em 15 minutos, e sua 'registro' está vinculado a endereço IP (de um único IP, pode-se registrar uma 'conta de convidado' por dia, mas uma 'conta' já registrada pode ser utilizada de outros endereços IP).
Essas 'contas' (tokens de acesso) funcionaram por um período de 30 dias. Naquele momento, uma solução razoável para o problema de registro em massa de contas temporárias poderia ser o crowdsource do registro pelos usuários, usando algo semelhante ao Bibliogram (um userscript que coleta o token de convidado do usuário e o transmite para uma instância pública).
No final de janeiro, o X cessou a emissão desses tokens. A eliminação do último método de acesso selou o destino do Nitter como um serviço público gratuito e multiplo, resultando na declaração do autor de que o Nitter estava morto.
Parte das instâncias se fecharam imediatamente após isso, enquanto outras modificaram o código para uma economia rigorosa no uso dos tokens existentes, particularmente privilegiando seu uso na obtenção de listas de tweets das contas, resultando em mensagens de erro para todo o resto. No dia 26 de fevereiro, o tempo de vida dos últimos tokens de convidado expirou, fazendo com que todas as instâncias públicas deixassem de funcionar. No entanto, maneiras relacionadas a contas de convidados estão sendo discutidas no rastreador de bugs.
Uma das soluções radicais para o problema poderia ser a substituição do Twitter pela criação de um serviço descentralizado alternativo baseado em ActivityPub e IPFS, onde o identificador principal de cada mensagem é seu CID IPFS. Podemos imaginar a seguinte estrutura em múltiplos níveis:
No entanto, os dados do ponto 3 não resolvem o problema da não participação dos usuários do Twitter no programa de substituição do Twitter.
Para cada identificador de postagem em cada plataforma centralizada, pode ser apropriado manter a exibição de seu CID IPFS, que atua como um cache, permitindo sem o conhecimento do texto da postagem, mas conhecendo seu identificador centralizado, descobrir seu identificador descentralizado. Ao gerar um URI no IPFS (o que pode ser feito sem o upload real), o texto da postagem passa por canonicização, que envolve colocar os dados em um contêiner baseado em HTML com metadados legíveis por máquina, normalização de Unicode, conversão para UTF-8, substituição de caracteres em branco por espaços simples e a troca de todos os links para postagens nesta e em outras plataformas, que passam por procedimento semelhante, para URI no IPFS.
Cada uma das plataformas possui um documento legível por máquina que descreve as regras de canonização de postagens, incluindo vários serviços cujos links são substituídos por URI IPFS nas postagens dessa rede. Cada postagem em cada rede é canonizada de acordo com as regras de canonização de postagens daquela rede, em vigor no momento em que a postagem é datada. Durante a canonização, se houver um link para uma postagem em uma das plataformas substituídas, a implementação extrai o identificador centralizado do link e verifica sua presença em índices confiáveis.
Quando presente no índice, a implementação utiliza o identificador descentralizado dos índices. Na ausência, a implementação solicita a postagem por meio do link, canoniza-a e forma um identificador que pode ser colocado nos índices. A implementação não é obrigada a colocar a postagem solicitada na rede descentralizada. A implementação pode verificar a validade do identificador no índice por meio da reprodução local do processo. A implementação do índice é obrigada a verificar a validade da geração dos identificadores por meio da reprodução local do processo.
Esse processo determinístico permite gerar links imutáveis para o conteúdo, mesmo para tweets cujos pôsteres ainda não participam do programa de substituição do Twitter. Quando parte deles começar a carregar seus tweets no IPFS, o algoritmo gerará para eles identificadores idênticos àqueles que já estão sendo usados em links para eles, contanto que o índice contenha representações corretas e o próprio conteúdo não tenha mudado.
Fonte: opennet.ru
