X потребовала у Nitter удалить исходный код, эссе предлагает atproto как открытую альтернативу

X (бывший Twitter) разослала сервису Nitter, лёгкому фронтенду, который показывал твиты без входа в аккаунт, письма с требованием прекратить нарушение и убрать исходный код. Nitter к этому моменту уже не пользовался официальным API X: когда доступ к нему закрыли, сервис перешёл на чтение обычных публичных страниц, а теперь, когда закрывать больше нечего, X требует убрать сам код, по словам автора эссе, программу, которая просто показывает публичные посты, приравняли к средству обхода защиты по законам о компьютерных преступлениях. Автор, по собственным словам работающий над протоколом atproto, прослеживает на примере Twitter путь от открытого API 2007 года (тогда на нём бесплатно строили клиенты, инструменты и аналитику тысячи разработчиков) до нынешнего состояния: сначала лимиты запросов, затем платные тарифы, затем обязательный вход в аккаунт, затем технические блокировки обходных путей и, наконец, письма юристов. Тем же путём, по словам автора, прошла и Meta около десяти лет назад: сегодня трудно вспомнить, что API Facebook и Instagram вообще стоило того, чтобы на них что-то строить.

Эссе связывает этот случай с эссе Тима Бернерса-Ли 2007 года «The Giant Global Graph», оттуда автор приводит цитату о том, что личные связи и дружба должны выходить за рамки отдельных документов и сайтов, чтобы ими могла пользоваться любая другая программа, и с многолетними призывами основателя Internet Archive Брюстера Кейла «запереть веб в открытом состоянии». Из этого автор выводит центральный тезис: проблема не в конкретном API, а в самой модели, где горстка компаний держит данные пользователей за «стойкой ресепшена» и выдаёт их только теми порциями и на тех условиях, какие сама сочтёт нужными.

Дальше эссе объясняет, почему даже бесплатный и щедрый по лимитам API не решает проблему в принципе. Во-первых, API, это фиксированное меню запросов: если продукту нужен нестандартный срез данных, которого не предусмотрели авторы API, такого эндпоинта нет и не будет, потому что никто в этой компании не строит продукт под чужую задачу. Во-вторых, даже подходящие запросы возвращаются неудобными порциями: автор приводит гипотетический пример аккаунта с двумя миллионами подписчиков, при выдаче по 100 подписчиков за раз это 20 000 отдельных запросов, то есть часы работы ради одного вопроса об одном пользователе. В-третьих, через отдельные API нельзя соединить данные разных сервисов, например, посты одного человека с фотографиями другого и отзывами из третьего сервиса. В-четвёртых, нельзя построить полноценный поиск, ранжирование или рекомендации над данными, которые не хранишь у себя целиком: индекс через замочную скважину не построить.

В качестве альтернативы автор описывает архитектуру протокола atproto. Вместо одной общей базы данных сеть строится из множества персональных дата-серверов (PDS): приложения не шлют в них сложные запросы, а реплицируют себе копии данных через логи и работают уже с локальной копией. Запись устроена как отдельный цикл «запись/приём» (write/ingest): приложение отправляет изменение в дата-сервер через putRecord, а затем получает его обратно через обработчик входящих событий (onPut) и сохраняет в своей базе; чтобы интерфейс не ждал этот цикл целиком, приложение может обновлять свою базу оптимистично, сразу после успешной записи, не дожидаясь обратного оповещения. Автор утверждает, что эта модель уже работает не в теории: на ней построены Bluesky, Tangled, Leaflet и другие сервисы, а всю сеть можно читать с обычного ноутбука без чьего-либо разрешения. На момент публикации, по данным автора, в atproto 46,1 млн аккаунтов и 24,5 млрд записей, из которых 3,15 млрд, посты и 17,4 млрд, лайки; сеть обрабатывает 500, 1000 записей в секунду через более чем 5000 персональных дата-серверов. Для доступа к этому потоку в реальном времени автор показывает пример на сервисе Jetstream, который по подписке на нужные типы записей, подписки, репосты, посты, отдаёт события live; тем, кто ищет именно приложение для блогов на atproto, автор указывает на сервис standard.site.

Эссе заканчивается прямым противопоставлением: вместо того чтобы получать письма юристов с требованием прекратить нарушение из-за кода, который просто показывает публичные данные, автор призывает разработчиков делать SELECT * FROM internet.blogposts, то есть строить на общей, доступной для записи базе данных вместо обращения к чужому API по одному запросу за раз.

Ключевые факты

X разослала сервису Nitter (прокси для чтения твитов без входа в аккаунт) письма с требованием прекратить нарушение и убрать исходный код, хотя Nitter к тому моменту уже не пользовался API X, а лишь читал публичные страницы.
Автор прослеживает закрытие API Twitter по шагам: открытый API 2007 года → лимиты запросов → платные тарифы → обязательный вход → технические блокировки → письма юристов; тем же путём около десяти лет назад прошла Meta с API Facebook и Instagram.
Даже бесплатный API с щедрыми лимитами недостаточен: нельзя задать нестандартный запрос, дорого выгружать данные постранично (гипотетический пример, 2 млн подписчиков это 20 000 запросов по 100 штук), нельзя соединить данные разных сервисов и нельзя построить индекс над чужими данными.
Протокол atproto предлагает архитектуру из персональных дата-серверов (PDS): приложения реплицируют данные к себе и пишут в дата-серверы напрямую через цикл «запись/приём» (write/ingest), включая оптимистичное обновление локальной базы сразу после записи.
На момент публикации в atproto, по данным автора, 46,1 млн аккаунтов, 24,5 млрд записей (3,15 млрд постов, 17,4 млрд лайков), 500, 1000 записей в секунду и более 5000 персональных дата-серверов; на нём уже работают Bluesky, Tangled и Leaflet.

Почему это важно

X разослала сервису Nitter, прокси, который показывал твиты без входа в аккаунт, письма с требованием прекратить нарушение и убрать исходный код с публичных площадок; при этом Nitter к тому моменту уже не пользовался официальным API X, а просто читал общедоступные страницы. Автор эссе рассматривает этот случай как очередной шаг в закрытии некогда открытых API соцсетей: у Twitter путь занял годы, от открытого API 2007 года через лимиты запросов, платные тарифы и обязательный вход до технических блокировок и теперь писем юристов; тем же путём, по словам автора, прошла и Meta с API Facebook и Instagram около десяти лет назад. На этом фоне эссе формулирует более широкий тезис: закрытие API, это не единичный сбой, а системная особенность соцсетей, построенных вокруг единственного центра, который контролирует доступ к данным пользователей.

Кому это важно

Разработчикам, которые строят продукты поверх сторонних социальных API, ботов, аналитику, альтернативные клиенты вроде Nitter, и рискуют в любой момент потерять доступ по решению одной компании. Сообществу вокруг протокола atproto, на котором уже работают Bluesky, Tangled, Leaflet и другие сервисы: автор прямо говорит, что работает над atproto, и описывает его архитектуру как альтернативу закрытым API. Сторонникам открытого веба и децентрализованных социальных протоколов в целом, эссе прямо продолжает идеи эссе Тима Бернерса-Ли 2007 года и многолетние призывы основателя Internet Archive Брюстера Кейла «запереть веб в открытом состоянии».

Как это применить

Практическая часть эссе, это описание паттерна, на котором строятся приложения atproto: запись сначала уходит в персональный дата-сервер пользователя (PDS) через putRecord, а затем распространяется по сети и попадает в локальную базу конкретного приложения через обработчик onPut; для мгновенного отклика интерфейса приложение может не ждать этот цикл, а обновлять свою базу оптимистично сразу после успешной записи. Для доступа к живому потоку событий сети, подпискам, репостам, постам, автор приводит пример на сервисе Jetstream, библиотеке, которая отдаёт такие события в реальном времени по подписке на нужные типы записей. Тем, кто ищет именно приложение для блогов на atproto, автор указывает на сервис standard.site.

Можно ли доверять

В тексте статьи имя автора не указано: материал написан от первого лица («я работаю над atproto») без подписи в теле, а пользователь Hacker News, разместивший ссылку на обсуждение, это не автор, а тот, кто её туда принёс. Статистика сети atproto (46,1 млн аккаунтов, 24,5 млрд записей и так далее) приведена без конкретной даты, только пометка «на момент написания», и без ссылки на внешний источник или методику подсчёта; разбор по типам записей неполный, расшифрованы только посты и лайки. Материал по сути, эссе-манифест человека, вовлечённого в разработку atproto, а не независимая проверка фактов; исторические утверждения о развитии API Twitter и Meta в целом совпадают с широко известной судьбой этих платформ, но детали конкретных писем X к Nitter, дата, точная формулировка, юрисдикция, в тексте не приведены.

Риски и подводные камни

Эссе, позиция стороны, заинтересованной в успехе atproto, а не взвешенный разбор: в тексте не рассматриваются причины, по которым платформы вообще закрывают API, защита от спама и злоупотреблений, требования приватности и регулирования, стоимость инфраструктуры, и не обсуждаются проблемы самой модели общей открытой базы, например совместимость принципа «всё реплицируется всем» с приватностью и модерацией контента. Юридическая сторона конфликта X и Nitter описана только глазами Nitter: нет ни даты писем, ни их точного текста, ни независимого подтверждения формулировки о том, что программу для показа публичных постов сочли средством обхода по законам о компьютерных преступлениях, это пересказ автора, а не цитата документа. Пример с аккаунтом на 2 млн подписчиков и 20 000 запросов, гипотетическая иллюстрация автора, а не измеренный реальный случай.

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

— Тим Бернерс-Ли, эссе «The Giant Global Graph» (2007)

Компания Meta Platforms признана экстремистской организацией, её деятельность на территории РФ запрещена.