Bluesky предлагает протокол приватных данных для ATProto

Разработчики Bluesky представили черновик расширения AT Protocol под номером 0016 — так называемые permissioned data, то есть данные с периметром доступа. Сегодня atproto устроен как протокол «публичного вещания»: пользователь публикует подписанные записи в свой репозиторий на PDS, а приложения обходят эти репозитории и строят представления. Новый протокол сохраняет ту же общую форму — авторитет на основе DID, репозитории на каждого пользователя, записи, типизированные через лексиконы, — но обслуживает совсем иные сценарии: личные закладки и черновики, платные рассылки, приватные посты и «истории», закрытые форумы и групповые чаты.

Что предлагается

В основе лежит понятие space — граница авторизации и синхронизации, идентифицируемая тройкой «авторитет, тип, ключ». Каждый участник хранит свои записи для данного space в отдельном приватном репозитории на собственном хосте; сам space существует лишь как совокупность этих репозиториев, разбросанных по сети. Чтобы прочитать или синхронизировать space, приложение должно получить space credential, который выдаёт авторитет space, опираясь на два независимых фактора: делегирующий токен от PDS пользователя и, при необходимости, аттестацию самого клиентского приложения.

Авторы честно оговаривают границы: протокол обеспечивает контроль доступа, но не конфиденциальность. Это не сквозное шифрование — серверы и авторизованные приложения читают данные, что необходимо для поиска, индексации, уведомлений и модерации. E2EE, если оно кому-то нужно, предлагается надстраивать сверху отдельно.

Технические решения

Вместо дерева Merkle Search Tree, как в публичном протоколе, приватный репозиторий описывается коммитом на базе LtHash — гомоморфного хеша, построенного на решёточной задаче (а потому, как отмечают авторы, устойчивого к квантовым атакам). Добавление или удаление записи — это одно дешёвое сложение или вычитание, не требующее пересчёта всего репозитория, а итог не зависит от порядка операций.

Отдельного внимания заслуживает подпись коммита. Пользователь не подписывает дайджест содержимого напрямую: иначе получилась бы «пересылаемая» криптографическая улика того, что человек написал в приватном пространстве. Вместо этого подпись покрывает лишь случайные байты, а дайджест привязывается к ним симметричным MAC. Читатель получает полную аутентичность, но утёкший коммит остаётся «отрицаемым» и ничего не доказывает третьей стороне.

Синхронизация похожа на публичную, но обходится без релея: приложение тянет репозитории напрямую с хостов и само поддерживает свою копию, сверяя её через сравнение множественных хешей — механизм самовосстанавливающийся, пропущенная операция обнаруживается при следующей синхронизации.

Доступ и модерация

Права пользователь выдаёт через OAuth-скоупы вида space:, а базовую реализацию управления пространствами (simplespace) обязан поддерживать каждый PDS — со списком участников или политиками «публичный» и «управляется приложением». Модерация сохраняет прежнюю модель с оговоркой: сервис-модератор не видит пространство, куда его не допустили, и вынужден работать как обычный читатель, публикуя метки не в общий поток, а записями внутри той же приватной границы.

Авторы подчёркивают: это черновик, терминология и поведение ещё будут меняться, а сама реализация — работа в процессе.

Источник: Lobsters