Три рабочих эксперимента с текстовым редактором, списком задач и видеочатом показали, что AT Protocol можно использовать не только как основу соцсети, но и как инфраструктуру для local-first приложений. Для разработчиков это важный сигнал: если идея взлетит, часть привычного backend-слоя можно будет вынести в общий протокол, а не держать отдельный сервер ради синхронизации, авторизации и обновлений.
Об этом на конференционной сессии рассказал разработчик Jake Lazaroff, сообщает InfoQ. Его тезис был довольно прямолинейным: у distributed-приложений слишком часто остается одна слабая точка в виде собственного сервера, и именно она ломает всю красивую архитектуру в момент, когда сервис закрывается, дорожает или меняет правила игры. В качестве примера Lazaroff привел собственное приложение для планирования поездок, которое он написал во время саббатикала. Оно работало на YJS и использовало managed sync server. Примерно через год провайдера синхронизации купили и закрыли. Локально приложение продолжило жить, но синхронизация между устройствами исчезла, а запасным вариантом остался почти музейный способ передачи файлов вручную.
Именно из этой истории выросла его аргументация в пользу AT Protocol. В модели, которую он описывает, пользователь хранит данные в персональном PDS, personal data server, и уже приложения получают к ним доступ. PDS в такой схеме берет на себя хранение, детализированную аутентификацию и push-обновления, а синхронизация идет через общую инфраструктуру протокола. Это заметно отличается от стандартной логики, где каждая команда строит свой изолированный backend, дублируя одни и те же функции у десятков приложений. Отдельно Lazaroff назвал App View, то есть кастомный сервер на приложение в типовой архитектуре atproto, необязательным компонентом и, по сути, более слабым местом всей конструкции.
Дальше он показал три эксперимента, в которых App View вообще убрали из схемы. В первом случае речь шла о коллаборативном текстовом редакторе на YJS и ProseMirror. Каждое обновление YJS записывалось как отдельная запись в собственный PDS пользователя. Информация о соавторах лежала в metadata-record, а участники подтягивали и реплицировали обновления друг друга через relay почти в реальном времени. По сути, atproto здесь работал как сервер синхронизации для YJS, только без отдельного сервиса, который целиком принадлежит одному приложению. Слабое место этого подхода Lazaroff тоже не скрывал: состояние документа оказывается размазано по множеству записей, из-за чего совместимость с другими приложениями становится сложнее. Для инженерной команды это уже не красивая абстракция, а вполне конкретный вопрос к модели данных и к тому, насколько легко ее потом читать извне.
Во втором эксперименте разработчик собрал совместный to-do list, но уже без YJS, на нативных CRDT-записях. Здесь записи были обычными JSON-объектами с понятными полями вроде $type, listId, text, done и createdAt, а CRDT-метаданные хранились отдельно. В этом и есть, пожалуй, самая практичная часть идеи: даже если другое приложение не понимает CRDT-механику, сама запись остается читаемой и самодостаточной. Для каждого поля использовались last-write-wins register, поэтому параллельные изменения разных полей не конфликтовали. Если же два клиента одновременно писали в одну и ту же запись, compare-and-swap отклонял конфликтующую операцию, после чего клиент должен был забрать актуальное состояние, локально смержить изменения и повторить попытку. То есть магии нет: конфликты никуда не делись, но их обработка вынесена в понятную, контролируемую модель, а не в набор backend-костылей на стороне конкретного сервиса.
Третий эксперимент выглядел самым необычным: AT Protocol использовали как сигнальный слой для WebRTC-видеочата. Один участник записывал в PDS ICE-candidate records с указанием адресата, второй слушал изменения через relay и отвечал, после чего между ними устанавливалось прямое WebRTC-соединение. На живой демонстрации, впрочем, конференционный Wi‑Fi быстро напомнил, что теория и сеть в отеле редко совпадают. Из-за проблем с подключением пришлось использовать TURN relay, который Lazaroff с иронией назвал "TURN server of shame". Эта деталь важна не как шутка, а как напоминание: даже если архитектура local-first и распределенная, сетевой мир по-прежнему любит NAT, нестабильный Wi‑Fi и прочие вещи, которые вынуждают возвращаться к промежуточной инфраструктуре. Сам Lazaroff при этом предложил смотреть на WebRTC data channels как на дополнительный транспорт реального времени для таких приложений, а не как на полную замену протоколу хранения и синхронизации.
Если вынести за скобки детали конкретных демо, картина получается шире. Рынок давно тянется к более устойчивым архитектурам, где пользовательские данные не замкнуты на одном вендоре, а приложение не умирает вместе с закрытием очередного облачного сервиса. На этом фоне AT Protocol выглядит как попытка собрать общий уровень инфраструктуры для distributed apps: простые и взаимозаменяемые серверы, несколько независимых PDS-хостов, публичные relay и поддерживаемые сообществом механизмы агрегации. Для разработчиков это означает не только потенциальную экономию на собственном backend, но и новый набор компромиссов: придется проектировать данные так, чтобы они были переносимы, думать о конфликтных записях, о читаемости форматов, о приватности и о том, где все-таки нужен специализированный сервер, а где он лишь привычка.
Для бизнеса и продуктовых команд вывод тоже не самый тривиальный. Убрать app-specific backend звучит как способ снизить операционные риски и зависимость от чужой инфраструктуры, но вместе с этим меняется сама логика владения платформой. Если данные живут у пользователя в PDS, а приложение лишь работает с ними через общий протокол, компания получает меньше контроля над экосистемой, зато выигрывает в устойчивости и совместимости. Вопрос теперь не в том, может ли такая схема работать технически, а в том, готовы ли разработчики и владельцы продуктов отказаться от удобной, но хрупкой модели, где вся ценность и вся точка отказа по-прежнему сидят в одном backend-сервисе.