Разработка на базе ATProto

Люк Канис (Luke Kanies), создатель Puppet, провёл часть июля 2026 года на Local First Conference в Берлине, расспрашивая создателей и пользователей ATProto о том, стоит ли строить приложения на его основе. Его ответ - сдержанное "нет", и сам пост устроен скорее как обратная связь разработчикам протокола, чем как вердикт: вот что я хочу сделать, а вот где ваши текущие и предложенные решения этому мешают.

Приложение

То, что он хочет сделать, - это набор приложений для отзывов, достаточный, чтобы вытеснить Yelp, GoodReads и Letterboxd. Причина кроется в бизнес-модели, а не в наборе возможностей. У него с женой в Yelp заперто больше тысячи закладок: их нельзя опубликовать, ими нельзя поделиться, их не автоматизировать скриптами и не версионировать. Общая публичная модель данных позволила бы одному инструменту хорошо писать отзывы, другому - публиковать списки лучшего, третьему - встраивать их на личный сайт, и ни один из них не владел бы данными единолично.

Более меткое наблюдение касается того, для кого эти приложения вообще создаются. Канис делит пользователей на три группы: те, кто пишет отзывы, только если их прочтут другие; те, кто, как и он сам, хочет сочетать оба варианта в зависимости от темы; и те, кто, как его жена, вообще ничего не публикует в сети и записывает отзывы только для семьи. Все существующие продукты обслуживают первую группу, потому что первая группа - это инфлюенсеры, а инфлюенсеры служат двигателем роста. Он предполагает, что две другие группы заметно больше. От протокола ему нужна возможность дать пользователю выбор - полностью публично, полностью приватно или выборочно для конкретной группы, - и чтобы приложение не считало это разными возможностями.

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

Что в ATProto сделано правильно

Идентичность, и тут Канис не скупится на похвалу. Он называет ATProto первым протоколом, спроектированным для решения проблемы идентичности в масштабе: приложение может взять идентификаторы ATProto для аутентификации, подписок и поиска друзей, вместо того чтобы строить социальный граф с нуля. Единственная его претензия - идентификаторы недостаточно легко читаются человеком. В качестве доказательства он приводит то, что почти каждый докладчик на Local First упоминал этот протокол, что на конференции его самого и удивило.

Где протокол даёт сбой

Сегодня ATProto работает только с публичными данными, и это допущение зашито в системы хранения и сервисы публикации, а не наложено поверх них. Ответ сообщества - находящийся в разработке дизайн под названием "permissioned data" (данные с разграничением доступа). Против этого термина Канис возражает дважды: и потому, что существует нормальное слово "private", и потому, что это название детали реализации вместо поведения пользователя.

Его содержательное несогласие касается предпосылки, процитированной из поста о дизайне: "the through-line on all of this is that public broadcast data is substantially different from permissioned data." Он считает ровно наоборот. Отзыв о ресторане остаётся тем же самым объектом независимо от того, читает его один человек или миллион. Публичные данные - это частный случай, когда права на чтение открыты всему миру, а полностью приватные данные - частный случай, когда читателем выступает только автор. В предложенном дизайне разница в управлении доступом трактуется как принципиальная разница в природе данных.

Для разработчика последствия вполне конкретны. Permissioned data повторно использует идентичность ATProto и его lexicon'ы для определения типов, но добавляет новые структуры данных и новые методы для управления ими и валидации. В итоге приходится писать два приложения - одно для публичных данных, другое для приватных, - а затем маскировать шов между ними, потому что пользователи не поймут: "это же отзывы о ресторанах, почему они лежат в двух разных местах". Публикация приватного отзыва превращается в удаление и создание заново в другой подсистеме; сохранит ли он при этом лайки, репосты и входящие ссылки - по словам Каниса, неизвестно, но, скорее всего, нет. И поскольку Personal Data Server отдаёт данные любому запросившему приложению, каждому из таких приложений придётся реализовать обе системы и прятать тот же самый шов.

PDS - это не git-репозиторий

Раздел, который он выделяет как собственную работу над ошибками, самый ценный. Он предполагал, что фраза "вы владеете своими данными" означает то же самое, что и в git: вы держите копию у себя, меняете её и отправляете (push) для распространения. Но это не так. PDS - это сервер, с которым общаются по протоколу. Вы владеете своими данными в том смысле, что хранилище и протоколы доступа публичны, и вы можете перенести место их размещения. Криптографические гарантии целостности действительно есть (отчасти поэтому аналогия с git и напрашивалась), но они применяются на сервере, а не в протоколах, через которые идёт запись.

Если сопоставить ATProto с принципами local-first от Ink & Switch, протокол закрывает примерно половину. Он проигрывает в том, чтобы данные всегда были под рукой, и в том, чтобы сеть была необязательной, со всеми вытекающими последствиями. Чтобы сохранить отзыв в офлайне, придётся строить собственное локальное хранилище и свой слой синхронизации для сброса данных, - и если permissioned data выйдет в задуманном виде, этому слою синхронизации понадобятся два протокола, а онлайновому пути чтения и записи - ещё два, скорее всего, снова отличных от первых.

К чему всё сводится

Энтузиазм у него не угас, и он подчёркивает: дизайн ещё на ранней стадии и может измениться, к тому же он не единственный, кто возражает. Даже при текущем предложении он мог бы опереться только на системы идентичности и lexicon'ов. Однако главное опасение в конце носит не технический характер: если он убеждён, что публичные и приватные данные - это одно и то же с разными правами доступа, а сообщество считает, что они различаются и должны быть разными, значит, ему придётся бороться с протоколом, системой хранения и людьми, которые всё это поддерживают. Он уже проходил через такое раньше и говорит, что это паршиво.

За всем этим стоит поколенческий контекст. Канис сформировался в 90-е, когда интернет работал на поддерживаемых сообществом стандартах, созданных для расширения возможностей пользователей, а не для защиты коммерческих рвов, и он хочет вернуть то время. ATProto - первый подходящий кандидат за многие десятилетия.

Связанные страницы

tangled - ещё одна страница в хранилище по теме atproto, и она демонстрирует обратный пример: платформу для совместной работы с git, где вся суть в том, что репозитории и CI являются публичными артефактами, поэтому ориентация исключительно на публичность ей ничего не стоит. Это хорошая проверка аргумента Каниса: протокол подходит приложениям, чьи данные и так изначально предполагалось публиковать, а трение возникает ровно там, где у приложения есть пользователи, не желающие ничего выкладывать в открытый доступ.

Buzz от Block отвечает на смежный вопрос на базе другого протокола: там подписанные события Nostr дают людям и агентам единую идентичность для чата, кода и согласований - та же интуиция, что идентичность заслуживает стандартизации, но другая ставка на то, откуда её брать. А build-a-new-internet приходит к похожему диагнозу с другого конца: открытое общественное пространство оказалось легко засорить, и ответом становится уход в небольшие закрытые пространства с высоким барьером входа, а не создание лучшего протокола. Канис отстаивает позицию, что попытаться сделать протокол всё ещё стоит, и это более оптимистичный взгляд на то же самое угасание платформ.