Цей текст є перекладом оригінальної статті, опублікованої у блозі Bluesky.
Ця стаття висвітлює поточний план розвитку протоколу AT Protocol (atproto) до виходу "першої версії". Цей документ призначений для розробників, які вже ознайомлені з поняттями та термінологією atproto. Сфера застосування тут - це функції основного протоколу самого по собі, а не будь-які функції продукту, специфічні для мікроблогінгового додатка Bluesky (app.bsky.* Lexicons).
На високому рівні:
Плануємо досягти федерації на виробничій мережі наступного року (2024), якщо розвиток продовжиться згідно з планом.
Вже ведуться роботи з інфраструктурою та операційними змінами в сервісах Bluesky для забезпечення можливості ефективно обробляти великий потік контенту від федеративних екземплярів у ресурсо- та витрато-ефективний спосіб.
Плануємо подати майбутнє управління та формалізацію основного протоколу до незалежного органу стандартизації. Це процеси консенсусу, які базуються на інтересах та підтримці спільноти добровольців. Ми вже провели певну початкову роботу в цьому напрямку, але очікуємо розпочати розмови щодо цього приблизно в той же час, коли розпочнемо федерацію.
Не соромтеся ділитися своїми думками через обговорення на GitHub тут.
Досягнення федерації
Протокол AT розроблений як федеративний соціальний веб-протокол. Незважаючи на наявність відкритої федеративної пісочниці для розробників, головні сервіси Bluesky наразі ще не є федеративними. Нашим поточним пріоритетом є вирішення всіх остаточних питань або рішень щодо протоколу, які можуть ускладнити федерацію з незалежними екземплярами PDS. Деякі з цих питань перераховані нижче.
Переміщення облікових записів:
Однією з відмінних особливостей atproto є безперешкодна міграція як ідентифікації, так і відкритого контенту з одного екземпляра PDS на інший. Основи для цієї функції були закладені з самого початку, але є деякі деталі та поведінка, які потрібно вирішити та задокументувати.
Автентифікаційний рефакторинг:
Ми б хотіли покращити як потоки автентифікації сторонніх осіб (наприклад, OAuth2), так і підтримку перевірки міжсервісних запитів (наприклад, з UCAN). Це включає в себе як аутентифікацію ("хто це"), так і авторизацію ("що дозволено"). Ця робота, сподіваємося, буде питанням інтеграції та адаптації існуючих стандартів. Є шанс, що це буде готово вчасно для федерації, але це не є жорсткою вимогою.
Ітерація потоку подій репозиторію (Firehose):
Здорова екосистема проектів підписала на повний потік комітів репозиторію, який надає firehose. У нас є кілька покращень та варіантів, які можуть допомогти з ефективністю та досвідом розробника, не змінюючи основної семантики та силової динаміки (тобто можливості реплікації усього відкритого контенту). Серед них "епохи" послідовних номерів; шардування; можливість вилучення вузлів MST ("proof" chain) для зменшення пропускної спроможності; та зміни в подіях життєвого циклу облікового запису.
Розповсюдження міток сторонніх осіб:
Це можливість на рівні протоколу розповсюджувати та підписуватися на мітки з багатьох джерел, включаючи криптографічні підписи для перевірки. Лексикони в основному розроблені, але вони не включені в відповідну реалізацію додатка AppView, і потрібна документація.
Поширення статусу облікового запису:
Дії, такі як закриття облікового запису та (само) видалення, наразі не ретранслюються іншим сторонам в мережі, хоча їх можна публічно спостерігати (тобто контент стає недоступним). Ймовірно, деякий вид явного сигналу буде корисним. Крім того, ми хотіли б дозволити тимчасове вимкнення облікового запису як опцію, а не лише видалення облікового запису. Тимчасове вимкнення матиме подібну поведінку до закриття облікового запису, з ефектами, що поширюються через мережу.
Рефакторинг дій модерації:
Лексикони com.atproto.admin.* мають концепцію "дій", які "вирішують" конкретні "звіти", що сталося не дуже зручним для роботи. Рефакторинг буде більш гнучким в "подіях" (включаючи як звіти, так і приватні прапори чи анотації), які оновлюють "суб'єкти". Процес подання звіту про модерацію не повинен бути позначений, але інші адміністративні Лексикони можуть мати руйнівні зміни.
Прибирання залишків старих записів:
У нас є короткий залишений вік перед федерацією, під час якого, в теорії, ми могли б переписати будь-які записи, щоб видалити залишкові або недійсні дані. Зокрема, ми могли б спробувати видалити всі випадки старої схеми "blob" і виправити багато недійсних дат. Це призвело б до руйнування великої кількості сильних посилань між записами таким чином, що важко виправити, і це було б агресивним втручанням в існуючий контент репозиторію, так що є велика ймовірність, що це все ж не станеться, і ці залишкові записи залишаться в мережі назавжди.
Операційні зміни для федерації
Декілька інфраструктурних змін заплановані на наступні тижні та місяці, і вони вплинуть на інших учасників екосистеми. Ми намагатимемося повідомити про це заздалегідь, але балансуємо між порушенням існуючої розробницької та сервісної екосистеми та федералізацією мережі.
Декілька екземплярів PDS:
PDS Bluesky (bsky.social) наразі є монолітною базою даних PostgreSQL з понад мільйоном репозитаріїв. Ми будемо розподіляти облікові записи на кілька екземплярів, використовуючи сам протокол для масштабування. Залежно від деталей, це, ймовірно, мало бути малопомітним для кінцевих користувачів або розробників клієнтів, але вплине на споживачів firehose та деяких розробників.
BGS Firehose:
Більшість людей наразі підписані на firehose від PDS bsky.social. У нас є BGS-екземпляр, який вже працює. З переходом до кількох PDS все ще буде технічно можливо підписатися на окремі PDS-подачі, але більшість людей захоче перейти на єдиний BGS-потік. Це включатиме зміну хостнейму та інші послідовні номери.
Можливе масове оновлення did:plc:
Ми ще не впевнені, коли це станеться, але є велика ймовірність того, що для всіх (або великої частини) облікових записів bsky.social потрібно буде оновити DID-документи. Цей оберт з ідентичністю буде згідно з протоколом, але може викликати розлади в інших службах, якщо вони не готові до цього.
Оновлення пошуку:
Службу search.bsky.social, яка ніколи не була офіційною частиною API Bluesky (Lexicons), скоро буде призначено для застаріння, і обидва пошуки акторів (профілів) та повідомлень будуть можливими через app.bsky.* Lexicons, обслуговувані AppView (та проксійвані PDS).
Системи боротьби зі спамом:
Зусилля по боротьбі зі спамом будуть важливою частиною відкриття федерації. Це не зміна на рівні протоколу, але плануємо розгортання автоматизованих систем для боротьби зі спамом шляхом маркування повідомлень та облікових записів на широку масштабу.
Контроль росту мережі:
У нас поки що немає конкретної пропозиції щодо отримання зворотного зв'язку від екосистеми, але ми очікуємо наявність якихось обмежень використання ресурсів, коли відкриємо федерацію, щоб запобігти перевантаженню соціальних графів, споживачів firehose, а також людей і технічних систем.
Розробка нових додатків
Atproto має явну систему для розробки сторонніх додатків і розширення протоколу на рівні застосування, яка була вбудована вже з початку: систему схеми Лексикону. Поточна реалізація посилання PDS обмежує створення записів для невідомих схем, навіть коли встановлений параметр запиту "пропустити перевірку", але ми сподіваємося полегшити це обмеження протягом наступних місяців.
Щоб зробити atproto дружнім для розробника фундаментом для розробки застосунків, потрібно багато супровідного фреймворку та документації, а також деякі елементи протоколу ще потрібно вдосконалити:
Реєстр схем Лексикону:
Повинен бути чіткий автоматизований метод для вирішення нових та невідомих NSID (назв схем) на об'єкт JSON Лексикону через мережу.
Уточнення поведінки несправностей валідації:
Повинно бути детально вказано, що кожний елемент інфраструктури повинен робити, коли записи не проходять валідацію за схемою Лексикону, і надати тестові приклади.
Розвиток і розширення схеми Лексикону:
Правила сумісності з попередніми версіями для змін у схемах Лексикону схем застосунків які вже існують, але вони погано задокументовані. Є також можливість для сторонніх осіб вводити розширення в записи сторонніх сторінок, і потрібна документація щодо норм та кращих практик для цього типу розширень.
Далі в майбутнє
Слід зазначити кілька частин протоколу, над якими ми не плануємо працювати в найближчому майбутньому. Ми вважаємо, що ці частини досить важливі (саме тому ми їх згадуємо!), але нашим поточним пріоритетом є федерація.
Приватний контент і повідомлення (DM):
Плануємо включити груповий приватний контент з кінця до кінця в протокол, а також надійне рішення для миттєвих повідомлень з кінця до кінця. Це важливі та очікувані функції. Ми вважаємо, що це буде великим додатковим компонентом atproto, а не просто "приварками" до поточної структури репозитарію для відкритого контенту, навіть якщо ми приймемо існуючий стандарт, такий як MLS, Matrix чи протокол Signal. Внаслідок цього це буде великою роботою з інтеграції, і це не буде актуальним до федерації.
Версіювання записів:
Протокол низького рівня дозволяє оновлення існуючих записів. Повинна бути можливість зберігати "старі" версії записів в репозиторії, дозволяючи (необов'язково) отримувати доступ до історії та редагувань. Це може включати додавання шляхів репозиторію, AT URIs та основних точок читання та оновлення репозиторію.
Дійсні числа з плаваючою комою:
Теперішня модель даних наразі підтримує лише цілі числа, а не числа з плаваючою комою. Сутність чисел із плаваючою комою в системах, що використовують адресовані до вмісту системи, добре документовані, і є альтернативи та рішення (наприклад, кодування у рядок). Але якщо з'явиться елегантне рішення, було б добре підтримувати числа з плаваючою комою як типи даних першого класу.
Сприятливе сховище файлів статичного репозиторію CAR:
Для багатьох випадків використання було б зручно, якщо репозиторії atproto могли б обслуговуватися як статичні файли (мабуть, файли CAR), а не потребувати повноцінного екземпляра PDS.
Управління протоколом
До цього моменту розробка atproto керувалася однією компанією, Bluesky PBC. Якщо мережа відкривається на федерацію, зміни та вдосконалення протоколу все ще будуть потрібні, але вони будуть впливати на кілька організацій, спільнот та окремих осіб, кожен зі своїми власними пріоритетами та інтересами в розробці. Якщо протокол буде успішним, безумовно, будуть розбіжності та конкурентні напруги. Контроль над протоколом однією компанією не працюватиме в довгостроковому плані.
План полягає в тому, щоб принести розробку та управління самим протоколом до визначеного органу стандартів в той час, коли мережа відкриється для федерації. Наша поточна надія полягає в тому, щоб перенести цю роботу до IETF, імовірно, як нову робочу групу, процес, що, швидше за все, займе кілька років. Якщо IETF не підійде як платформа, ми спробуємо знову з іншими органами. Хоча існуючу роботу можна буде запропонувати в точно такому вигляді, як вона є зараз, зазвичай в процесах стандартизації виникає якась еволюція та руйнівні зміни.
Які частини протоколу будуть в рамках незалежної стандартизації? Як і багато інших мережевих протоколів, atproto абстраговано на різні рівні, з відмінностями між "специфічними для застосувань" бітами та основним протоколом. Ідентичність, автентифікація, модель даних, репозиторії, потоки та мова схеми Лексикону - це все частина основного протоколу та підпадає під стандартизацію. Деякі API-точки завершення під простором імен com.atproto.* також є відносно основними, і цей простір імен конкретно може підпадати під незалежне управління.
Інші API та простори імен, специфічні для застосувань, включаючи мікроблогінговий додаток app.bsky.*, не будуть підпадати під стандартизацію як частина основного протоколу. Влада над цими API та Лексиконами закодована в самому імені, і Bluesky PBC намагається залишити контроль за майбутнім розвитком додатка bsky.app. Схеми API (Лексикони) будуть відкритими, і очікування та правила для міжоператорної сумісності та розширень будь-якого Лексикону будуть частиною специфікації основного протоколу.
Для тих, хто цікавиться Bluesky, існує спеціальний Телеграм-чат, який сприяє зближенню спільноти та обміну інформацією між учасниками.
Приєднатися до чату
