Последний из публичных экземпляров Nitter пришёл в негодность. Проект Nitter развивал свободный фронтенд для доступа к X.com/Twitter без навязывания JavaScript, аналитики, трекеров и сторонних сервисов. 31 января была прекращена выдача токенов, используемых в Nitter для организации доступа к контенту в X.com. 26 февраля истекло время жизни последних из ранее выданных токенов, что привело к полной остановке работы Nitter.

После покупки Илоном Маском, Twitter (ныне переименован в X) начал внедрять комплекс технических и организационных мер, направленных на агрессивную монетизацию платформы, ранее считавшейся убыточной. В числе изменений была реализована тарификация полученной каждым аккаунтом информации (введены лимиты для разных видов аккаунтов - 10000 для обладателей платной "синей галочки", 1000 для обычных, 500 для новых обычных); переведены в разряд платных аккаунты "разработчиков" с лимитами, подходящими для массового извлечения данных (скрейпинга); прекращена отдача информации пользователям без аккаунтов.

В качестве оправдания публично утверждалось (2023-07-01), что это "временные экстренные меры", связанные с тем, что автоматизированная загрузка данных ботами приводит к ухудшению сервиса для обычных пользователей. До этого (2023-04-19) были инсинуации в адрес Microsoft, связанные с тем, что данная компания нелегально использует данные Twitter для обучения AI. Позднее (2023-11-17) введение лимитов обосновали обещанной Маском борьбой с ботами.

Nitter являлся проектом по разработке ПО для защиты от слежки пользователей Twitter, не отправляющих сообщения, а только читающих материалы, путём предоставления им альтернативного сайта для просмотра Twitter, не требующего ни аккаунта, ни включённого JavaScript. Такое ПО фактически является скрейпером и посредником, который вместо сохранения данных в БД отправляет их конечному пользователю (тем не менее некоторые служебные данные кешируются в Redis).

Таким образом ПО Nitter:

1. технически являлось как раз тем типом ПО, с которым руководство Twitter объявило активную борьбу;
2. являлось одним из немногих активно разрабатываемых ПО для получения доступа к данным, размещённым в Twitter, что обусловило его привлекательность для использования как модуля для скрейпинга в более узком понимании смысла этого слова — сбора данных в обход официальных интерфейсов для этого;
3. публичные экземпляры Nitter сами стали объектами скрейпинга, что привело к тому, что часть экземпляров реализовала собственный вариант капчи (1 дополнительный POST-запрос, специфичный для конкретного экземпляра).

В результате анализа обходных путей для продолжения работы в новых условиях были обнаружены RSS и некоторые точки входа на syndication.twitter.com, отдававшие информацию незарегистрированным пользователям в формате JSON, и использовавшиеся для интеграции с другими социальными сетями. Некоторое время Nitter получал информацию через эти интерфейсы, но затем и они были прикрыты. После этого был найден способ использования "гостевых аккаунтов", имевших привилегии на чтение. Один из типов "гостевых аккаунтов" был предназначен для использования на устройствах интернета вещей с урезанными браузерами.

Но Nitter использовал другой тип "гостевых аккаунтов", которые применяли OAuth вместо Cookie, регистрировались через API и по-видимому использовались приложением для Android. Этот тип аккаунтов имеет лимиты в 500 запросов к API в течение 15 минут, и его "регистрация" привязана к IP-адресу (с одного IP можно зарегистрировать один "гостевой аккаунт" в течение суток, но уже зарегистрированный "аккаунт" можно использовать с других IP адресов).

Такие "аккаунты" (токены доступа) были работоспособны в течение 30 дней. На тот момент адекватным решением проблемы массовой регистрации временных аккаунтов мог бы стать краудсорсинг их регистрации пользователями по типу того, что использовался в Bibliogram — юзерскрипт (вид браузерного расширения) забирает гостевой токен с IP пользователя и передаёт его публичному экземпляру.

В конце января X прекратил выдачу таких токенов. Устранение последнего способа доступа поставило крест на Nitter как на публичном бесплатном многопользовательском сервисе, в результате чего автор объявил Nitter мёртвым.

Часть экземпляров после этого сразу закрылись, другие модифицировали код для жёсткой экономии использования существующих токенов, в частности с преимущественным использованием их на получение списков твитов аккаунтов, с выдачей сообщений об ошибках на всё остальное. 26 февраля время жизни последних гостевых токенов истекло, в результате чего все публичные экземпляры прекратили функционирование. Тем не менее в баг-трекере обсуждаются способы, каким-то образом касающиеся гостевых аккаунтов.

Одним из кардинальных решений проблемы могло бы стать твиттерозамещение путём создания альтернативного децентрализованного сервиса на основе ActivityPub и IPFS, где основным идентификатором каждого сообщения является его IPFS CID. Можно представить следующую многоуровневую конструкцию:

1. Данные, изначально опубликованные в федеративном сервисе как на основной платформе, и отзеркалированные в IPFS.
2. Данные, опубликованные в твиттере самими пользователями, но с помощью браузерного расширения отзеркалированные в их аккаунты на федеративной платформе, а оттуда — в IPFS.
3. Данные, которые из твиттера выгрузили сами пользователи, пользуясь функцией выгрузки, и залили в Fediverse + IPFS через функцию массовой заливки.

Данные 3 пункта однако не решают проблему неучастия пользователями твиттера в программе твиттерозамещения.

Для каждого идентификатора поста на каждой централизованной платформе может быть целесообразно поддерживать отображение его в IPFS CID, которое выступает как кэш, позволяющий без знания самого текста поста, но при знании его централизованного идентификатора, узнать его децентрализованный идентификатор. При генерации URI в IPFS (что может быть сделано без фактической заливки) текст поста проходит каноникализацию, которая заключается в помещении данных в контейнер на основе HTML с машиночитаемыми метаданными, нормализацию юникода, конвертацию в UTF-8, замене пробельных символов на простые одинарные пробелы, и замене всех ссылок на посты в этой и других платформах, проходящие через аналогичную процедуру, на URI в IPFS.

Каждая из платформ имеет машиночитаемый документ, в котором описаны правила каноникализации постов, в том числе множество сервисов, чьи ссылки заменяются на IPFS URI в постах этой сети. Каждый пост в каждой сети каноникализуется в соответствии с правилами каноникализации постов в той сети, действующими на тот момент времени, которым датирован сам пост. При каноникализации если в посте присутствует ссылка на пост в одной из замещаемых платформ, реализация извлекает из ссылки централизованный идентификатор и проверяет его наличие в доверенных индексах.

При наличии в индексе, реализация использует децентрализованный идентификатор из индексов. При отсутствии реализация запрашивает пост по ссылке, каноникализует его и формирует идентификатор, который может поместить в индексы. Реализация не обязана помещать запрошенный пост в децентрализованную сеть. Реализация может проверять верность идентификатора в индексе путём локального воспроизводства процесса. Реализация индекса обязана проверить верность генерации идентификаторов путём локального воспроизводства процесса.

Такой детерминированный процесс позволят генерировать неизменяемые ссылки на контент даже для твитов, постеры которых пока что не участвуют в программе твиттерозамещения. Когда часть из них будет заливать свои твиты в IPFS, алгоритм сгенерирует для них идентификаторы, идентичные тем, что уже используются в ссылках на них, при условии, что индекс содержит верные отображения и сам контент не изменился.