# WebV — відкрита мережева архітектура та місія v0.2

**Ідентифікатор документа:** WEBV-ARCH-MISSION-0.2  
**Дата:** 2026-10-30  
**Статус:** review / proposed architecture; runtime NOT_RUN  
**Зв'язок із корпусом:** Canon 0.17.0, Foundation 0.15.0; авторська редакція для Studio 0.5.0  
**Історія:** розвиває v0.1 від 2026-09-09, збережену окремим незмінним файлом.

## 1. Призначення та точна межа цієї редакції

WebV — пропозиція відкритого протоколу, за яким незалежні учасники можуть знаходити одне одного, перевіряти походження контенту, передавати повідомлення й добровільно взаємодіяти з ресурсами. Він має бути реалізовним незалежними командами та не вимагати одного DNS-оператора, глобального каталогу, TOS-акаунта, токена, Foundation-сервера або світового адміністратора.

TOS є однією з reference implementations і може виконувати локальні задачі без WebV. WebV-контент, зі свого боку, не повинен вимагати TOS-планувальника. Civilization OS є довгостроковим добровільним застосуванням координації до громад, виробництва, знань та фізичних ресурсів. Участь у технічній мережі не означає прийняття Вільнізму або членство у його соціальній федерації.

Ця редакція задає семантичні контракти, права та спосіб майбутньої перевірки. Вона не визначає завершений wire-format, зареєстровану URI-схему, власну криптографію або перевірений runtime. Вибір кодувань, алгоритмів, транспортних адаптерів і конкретних лімітів повинен пройти окреме погодження та conformance-випробування. Слово «повинен» далі означає вимогу до заявленого профілю, а не повідомлення про вже наявну властивість.

## 2. Які рішення належать різним рівням

Конституція встановлює права, межі влади й процедури прийняття норм. Цей документ деталізує архітектурні вимоги. Профіль реалізації обирає конкретні механізми. Код їх реалізує. Звіт про випробування підтверджує лише перевірені властивості точної версії в названих умовах.

Технічний merge, публікація сайта, підпис архіву та згода користуватися програмою не є прийняттям нової Конституції (§§16–18). Наявність повністю валідного мережевого повідомлення не дає права виконувати запит: кожен домен перевіряє повноваження локально.

Символіка V, «п'ять сил» та послідовність Web 1.0 → Web V залишаються необов'язковою мовою пояснення. Умови сумісності визначаються властивостями й випробуваннями.

## 3. Семантичні сутності

Наведені назви є словником, а не готовою схемою пакетів.

| Сутність | Що означає | Чого не надає автоматично |
|---|---|---|
| Principal | Людина, організація або сервіс у заданій моделі повноважень | Глобальної цивільної ідентичності або членства |
| Node identity | Окремий пристрій чи peer із власним життєвим циклом | Окремого політичного голосу |
| SiteID | Стабільне походження публікації або сервісу | Адміністративного доступу чи гарантії безпечного коду |
| Content identity | Ідентифікатор конкретних незмінних байтів або маніфесту | Їхньої постійної доступності чи істинності |
| Catalogue namespace | Контекст людських назв, пошуку та Home | Монополії на існування незалежних сайтів |
| Authority domain | Незалежна область локальних правил, даних і дозволів | Права переписувати сусідній домен |
| Grant / мандат | Обмежений дозвіл конкретному виконавцю | Права перевищити джерело делегування |
| Offer | Опис доступної за певних умов послуги | Резервування або договору купівлі |
| Reservation / lease | Обмежене договірне виділення ресурсу | Власності на хост або його секрети |
| Receipt | Свідчення події, виконання чи приймання | Самодостатнього доказу правильності та оплати |

Людина може мати кілька контекстних ідентифікаторів. Для голосування чи іншого обмеженого права застосовується окрема процедура eligibility, без перетворення всіх її дій на один глобальний профіль (§§34.4–34.7, 39).

## 4. Архітектурні площини

| Площина | Мінімальна функція | Межа повноважень |
|---|---|---|
| Ідентичність і чинність ключів | Перевірити походження та дозволений перехід ключа | Не визначає політичної легітимності |
| Контент і зберігання | Отримати, перевірити й утримувати дозволені байти | Не надає права запускати код |
| Виявлення | Знайти можливі контакти, записи й маршрути | Не встановлює довіру до першого peer |
| Transport | Передати повідомлення через доступний канал | Не розширює доступу й не гарантує відсутнього каналу |
| Локальні сервіси | Виконати дозволений запит у власному домені | Не змінює state сусіда напряму |
| Ресурсні угоди | Узгодити пропозицію, ліміти, виконання, доказ і розрахунок | Не робить брокера власником всіх ресурсів |
| Соціальне governance | Прийняти правила, видати мандат, розглянути спір | Не є побічним ефектом технічного консенсусу |
| Прикладні середовища | TOS, інші runtimes, клієнти, інтерфейси | Не канонізують конкретного виробника |

Приватність, безпека, переносимість, облік доказів і право на вихід проходять через усі площини. Це не вимога створювати окремий процес або базу для кожної назви. Реалізатор може обрати компактну архітектуру, якщо межі зберігаються та перевіряються.

## 5. Модель довіри та відмов

Вузли можуть вимикатися, повертати застарілі або суперечливі записи, бути неправильно налаштованими чи діяти недобросовісно. Зв'язок може бути асиметричним, переривчастим або відсутнім. Годинники можуть помилятися. Оператор ресурсу може підробити самозвіт; workload може атакувати хост. Схожі ключі, кілька процесів або кілька VM не доводять незалежності операторів.

Кожен профіль називає, які відмови та зловмисні дії він витримує і за яких припущень. Не можна переносити гарантію консенсусу в довіреному кластері на анонімний публічний ринок або вважати всі домашні ноди довіреними через спільний бренд.

Повинен бути видимим мінімум фізичних залежностей: локальні дані, доступні маршрути, енергія, накопичувачі, обладнання, ремонтні навички та оплата обслуговування. Децентралізація не робить кожен окремий пристрій безвідмовним і не скасовує економіки утримання сервісу.

## 6. Ідентичність, стабільна адреса та оновлення

Профіль має розділяти стабільний ідентифікатор сервісу, чинний стан його key authority та ідентифікатор поточного контенту. Можливий напрям — незмінний початковий опис ідентичності й підписані переходи контролю; конкретні канонічні байти, алгоритми та правила переходу ще мають бути визначені й перевірені.

Зміна контенту створює нову незмінну версію та авторизований запис про її актуальність. Порядок оновлень контенту, покоління ключа, строк мандату й захист від застарілого виконавця є різними поняттями. Їх не можна підміняти одним лічильником.

Приймання оновлення перевіряє допустимий формат і розмір, потрібну ідентичність, правомірність підписанта, підпис, чинність, зв'язок із попередньою відомою історією та відповідність контенту. Суперечливі записи з однаковим положенням в історії зберігаються як конфлікт. Правило «остання отримана відповідь перемагає» не вирішує спір про повноваження.

Новий або ізольований клієнт може знати лише найновіший відомий йому перевірений запис. Вік, джерело та невизначеність показуються явно. Незалежні джерела й локально збережені контрольні точки допомагають виявляти відкат, але не дають знання про всі записи світу.

## 7. Ключі, відкликання та recovery

До використання профілю визначаються правила створення ідентичності, ротації, компрометації, втрати пристрою, відкликання й відновлення. Профіль розрізняє особистий контроль і колективні владні ключі (§34.8).

Для спільних критичних повноважень визначаються незалежні сторони, поріг, умови заміни й порядок спору. Для особистих ключів recovery є добровільною політикою людини. Довірені особи відновлення не отримують загального права читати дані або діяти від її імені. Відновлювальний матеріал відокремлюється від повсякденного використання; здатність відновити доступ перевіряється в контрольованому випробуванні.

При компрометації зберігаються історичні свідчення й окремо оцінюється нинішня чинність ключа. Зміна довіри сьогодні не переписує байти вчорашнього доказу. Конфліктні recovery-претензії не вирішуються кількістю копій одного повідомлення або рішенням першого каталогу.

Ізольований вузол може не отримати відкликання одразу. Для ризикових операцій потрібні обмежені строки й бюджети, допустимий вік key-state та поведінка за невизначеності часу. Відсутність зв'язку не подовжує дозвіл. Людська допомога й оскарження залишаються доступними при втраті ключа; вона не гарантує відновлення зашифрованих байтів без recovery-матеріалу.

W3C DID Core окремо описує прив'язку до фізичної особи, відновлення та ризик кореляції. Це корисне первинне джерело вимог, а не твердження, що WebV вже реалізує конкретний DID method [W1].

## 8. Home, назви та виявлення

Home/ID 0 є початковим каталогом у названому просторі імен. home.html може бути логічною сторінкою входу. Вони не є світовим root-key, глобальним послідовним allocator або дозволом на існування будь-якого сайта.

Людські назви мають контекст: каталог, локальний простір імен, правила власника й джерело відповідності криптографічному ідентифікатору. Однакові назви в різних просторах не повинні мовчки зливатися. Власник може обирати інший каталог і відкривати відомий SiteID напряму. Відмова в розміщенні не відкликає чужий SiteID.

Контакти можуть надходити зі збережених списків, явного запрошення, QR/файла, локального виявлення, кількох незалежних bootstrap peers або DHT. Потрібний принаймні реальний контакт чи доступний канал. Дескриптор peer є кандидатом для перевірки, а не довіреним адміністративним наказом.

Ліміти на розмір, частоту, час життя й кількість запитів захищають discovery від перевантаження. Перевірка походження та різноманітність peer-доменів зменшують ризик ізоляції клієнта підконтрольними нападнику вузлами. Вони не доводять автоматичної стійкості до всіх Sybil-атак; кількість peer IDs не стає вагою голосу.

## 9. Контент, зберігання та активні застосунки

Маніфест публікації повинен зв'язувати дозволені шляхи, розміри й типи контенту з його незмінними ідентифікаторами. Отримання частинами завершується перевіркою цілого об'єкта до приймання. Небезпечні шляхи, надмірні обсяги та неоднозначні типи обробляються за визначеним профілем безпеки.

Класи зберігання оголошуються окремо: тимчасовий кеш, погоджене утримання, офлайн-знімок, критичний резерв. Для кожного вказуються строк, допустимі зони відмов, бюджет, спосіб перевірки отримання та порядок ремонту втрат. TTL запису discovery, час кешування й строк збереження контенту не є одним параметром.

Підписане твердження про копію не доводить, що вона буде доступною в майбутньому. Потрібні фактичне отримання, контроль втрат і незалежні failure domains. IPFS описує зберігання як залежне від готовності вузлів утримувати дані та від політики pinning/garbage collection [W2]; WebV не отримує гарантії збереження лише через content addressing.

Приватні дані шифруються перед передачею недовіреному сховищу. Метадані також класифікуються: публічний discovery може розкривати факт наявності чи запиту об'єкта. Публічність DHT-метаданих окремо описана в IPFS [W3]. Відкликання ключа не стирає раніше розшифровану копію; видалення з підконтрольних вузлів не гарантує видалення всіх незалежних публічних копій.

Статична сторінка може бути прочитана з локальної копії. Динамічний застосунок окремо визначає сервіс, state owner, авторизацію й офлайн-поведінку. Кешований інтерфейс не видає недоступний backend за працюючий. Перегляд, встановлення capability та надання доступу до Files/compute є різними діями. Сторонній контент не успадковує адміністративний origin або токени TOS.

## 10. Транспортні профілі

| Профіль | Призначення | Обов'язкова чесна межа |
|---|---|---|
| Native LAN/IP | Локальний запуск і доступні Internet-маршрути | Реальні канали, доступні порти й фактичний мережевий стек |
| Browser light node | Обмежений клієнт або дозволене обчислення | Фонові режими, пам'ять і transports перевіряються на конкретному браузері |
| HTTPS bridge | Доступ із conventional web | Залежність від DNS/CA/хостингу шлюзу не приховується |
| Mesh / relay | Альтернативні шляхи між доступними учасниками | Окремі вимоги до радіо, драйверів, ретрансляторів і бюджету |
| Додатковий radio | Короткі повідомлення й спеціальні маршрути | Обладнання, дозволені режими, затримка й низька пропускна здатність |
| Store-carry-forward | Відкладена передача через носій або непостійний контакт | Немає обіцянки одночасної присутності, малої затримки чи актуального глобального стану |

Адаптер оголошує фактичний support; назва стандарту не доводить працездатності на iPhone, Android або іншій платформі. Спільна ідентичність не означає спільної фізичної мережі. Зміна маршруту не обходить локальних дозволів.

Для відкладеної передачі потрібні обмежений spool, строк придатності, ідентифікатор повідомлення, придушення дублів, контроль кількості переходів, пріоритети та перевірка відправника. RFC 9171 є первинним прикладом store-carry-forward архітектури [W4]. Сумісність пакетів із BPv7 не заявляється без окремого адаптера й тестів.

Жоден профіль не передає інформацію без каналу та енергії. Перехід на повільний зв'язок означає зменшення функцій, пріоритет коротких критичних повідомлень і відкладення великих обсягів; він не зберігає необмежену відеопередачу або інтерактивні хмарні обчислення.

## 11. Partition: автономні острови та пізніше узгодження

Федерація складається з незалежних authority domains. Регіональний домен продовжує власну дозволену роботу при ізоляції; worker одного домену не отримує його повноважень лише через втрату керівного процесу. Внутрішня відмовостійкість deployment і міждоменна федерація мають різні контракти.

| Вид стану або дії | Під час розриву | Після з'єднання |
|---|---|---|
| Незмінний публічний контент | Читання наявних копій | Перевірка ідентичності й усунення дублів |
| Актуальний запис сайта | Останній локально перевірений стан із віком | Перевірка переходів, відкликань і конфліктів |
| Локальне спостереження | Фіксація джерела й початкового часу | Додавання з походженням; давній запис не стає новим вимірюванням |
| Pure job | Лише надані inputs, ресурс, строк і бюджет | Перевірка спроби та приймання без подвійного ефекту |
| Спільне редагування | Лише дозволені доменні зміни | Merge/CRDT там, де це відповідає семантиці |
| Локальний ресурс | Власник керує своєю часткою | Узгодження чинних зобов'язань |
| Спільний дефіцитний ресурс | Немає повторного незалежного виділення однієї частки | Перевірка резервів і збереження спорів |
| Платіж, ордер або зовнішня закупівля | Немає нового offline submit у початковому профілі | Перевірка authoritative receipt до повтору |
| Політика й відкликання | Лише строкові раніше видані повноваження | Оновлення стану, обмеження або карантин за політикою |
| Життєзабезпечення | Погоджений безпечний локальний режим | Людський перегляд і відновлення обліку без вигадування минулого |

Окремі майбутні профілі можуть передбачати наперед відділені квоти для автономних витрат. Це потребує доказу неможливості дублювати одну частку; ця редакція не активує такі фінансові операції.

Сильна консистентність, fencing та CRDT вирішують різні задачі. Наприклад, etcd описує зупинку записів у частині кластера без кворуму [W5], а Chubby — перевірку покоління повноваження самим одержувачем команди [W6]. Жоден із цих механізмів не дає ізольованим сторонам одночасного знання про всі світові зміни. Конституційна вимога — не канонізація алгоритму, а збереження меж повноважень, дефіцитних прав і явних конфліктів (§31).

## 12. Ресурси та дата-центри

Технічна мережа об'єднує дозволені пропозиції незалежних інфраструктур, а не перетворює всі комп'ютери на один чужий ресурс. Оператор перевіряє запит локально. Право оренди, доступ до даних, можливість запускати сторонній код і право фінансового підписання є окремими дозволами.

Профіль угоди визначає сторони, ресурси, місце виконання, клас даних, ціну, ліміти, строк, умови припинення, метод перевірки, відповідальність, рахунок та апеляцію. Видимі різниці між оцінкою ціни, гарантованою пропозицією, резервом, фактичним рахунком і прийнятим корисним результатом.

Бюджет резервується в його визначеному доменному owner до платного ефекту. Невідома відповідь на створення чи завершення ресурсу зберігає невизначене зобов'язання до reconciliation. Зникнення heartbeat не доводить завершення оплачуваного процесу. Повтор закупівлі без перевірки попереднього результату не є допустимим способом «відновлення».

Приватний source, персональні дані та секрети допускаються лише до відповідного профілю виконавця. Шифрування каналу й диска не захищає plaintext від адміністратора хоста, який його обробляє. Особисті wallet keys, інституційне підписання й security-admin не передаються випадковому виконавцю заради дешевшого compute.

Необхідність оплачувати реальний storage, енергію, зв'язок і support не створює обов'язкового токена або права продавати політичні голоси. Credits та енергетичні індекси потребують окремої методики; тестова одиниця не є автоматично валютою, погашуваним активом чи фізичним забезпеченням.

## 13. Агенти, Genesis та дозволене самовдосконалення

Агент діє в межах мандату з метою, scope, строком, сукупним бюджетом і правилами відкликання (§20). Підлеглі агенти разом не можуть витратити більше початкового дозволу. Публічний capability descriptor не є grant.

Контролер допуску й лімітів відокремлюється від моделі, що планує. AI не редагує власні заборони або еталон, за яким незалежно оцінюється його робота. Повідомлення про успішне виконання перевіряється за відповідним методом, а не приймається лише тому, що його склав агент.

Genesis означає дозволене розгортання копій і оновлень у власному або делегованому середовищі. Discovery нової машини не дозволяє встановлюватися на ній. Пілот, promotion і відкат мають визначені межі; зміна правил чи новий фізичний ефект потребують окремого чинного мандату. Автоматизація всередині дозволеної політики не потребує ручного підтвердження кожної дрібної дії.

## 14. Governance, модерація та протидія зловживанням

Публічна специфікація має версії, історію аргументів, пропозиції, процедуру прийняття й оскарження. Зміна специфікації не надає її редакторам адміністративного доступу до установок. Сумісна незалежна реалізація не повинна потребувати дозволу автора TOS на кожен реліз.

Каталоги можуть мати різні правила, а оператори — захищати свої ресурси від перевантаження чи небезпечних запитів. Автоматичне відхилення запиту застосовується в межах видимої локальної політики. Політична санкція, виключення з каталогу та мережева недоступність є різними діями з різними підставами й процедурами перегляду.

Технічна свобода публікації не примушує інших зберігати контент. Водночас локальне рішення каталогу не відкликає незалежну ідентичність і не замінює світовий арбітраж. Спори про назви, ключі, оплату й соціальне членство не зливаються в один рейтинг людини.

Мережа не обіцяє, що будь-який сторонній учасник дотримуватиметься Конституції. Вона повинна дозволяти локальні безпечні межі, докази й оскарження без створення прихованого світового адміністратора.

## 15. Шлях від bootstrap до самостійної мережі

| Етап | Що має бути продемонстровано | Що ще не можна стверджувати |
|---|---|---|
| S0 — документований початок | Межі протоколу, доступні вихідні матеріали, власники й залежності | Наявність готового runtime |
| S1 — контрольована лабораторія | Окремі домени, відомі peers, перевірка запитів і конфліктів | Незалежність реальних операторів або фізичних каналів |
| S2 — незалежний локальний острів | Локальні дані, енергія, запуск і відновлення без початкового сервера | Постійний глобальний доступ |
| S3 — федерація незалежних островів | Міждоменні угоди, реальна різноманітність операторів, partition/rejoin | Право змінювати чужі правила чи shared balance |
| S4 — перевірене зняття центральної залежності | Exit-gates для оголошеного набору функцій і план безперервності | Безвідмовність за будь-якої катастрофи |

Етапи є рівнями доказів, а не примусовою схемою централізації. Локальна громада може використовувати доступний рівень без очікування світового масштабу. Bootstrap-сервер може залишитися добровільним корисним сервісом після того, як перестав бути незамінним.

Критична маса визначається профілем спроможності: незалежність контролю й ключів, копії в різних зонах відмов, різні маршрути, локально доступні assets, енергетична безперервність, бюджет обслуговування, заміна операторів та перевірене відновлення. Немає універсальної кількості людей, після якої всі ці властивості виникають автоматично.

Для кожної критичної функції задаються мінімум доступних копій/операторів, допустимі спільні відмови, максимальний вік стану, час відновлення й резерви. Параметри приймаються до тесту та пояснюються його сценарієм. Зміна умов означає нову оцінку, а не довічний сертифікат.

## 16. Відключення центрального сервера як необхідної залежності

Перевірка проводиться спочатку на ізольованому полігоні, без руйнування чужих активних послуг. Блокується доступ до початкових Home, домену, API, bootstrap, update і recovery endpoints у межах заявленої моделі. Потрібно перевірити також приховані залежності, а не тільки вимкнути головну HTML-сторінку.

Незалежні учасники повинні показати новий запуск із локальними перевіреними матеріалами та дозволеним альтернативним контактом; відкриття відомого SiteID; отримання копій; власні локальні дії; key lifecycle; переживання оголошених втрат; відновлення; експорт і повторне з'єднання без подвійних ефектів. Методика й негативні випадки визначені в [протоколі перевірки v0.2](WEBV_CONFORMANCE_AND_EXIT_PROTOCOL_v0.2_uk.md).

Вимкнення залежності дозволене лише для функцій, чиї умови підтверджені. Неперевірені функції залишаються явно залежними або недоступними. Реальний перехід враховує договори, резерви даних, строки попередження, відповідальних за підтримку та план відновлення. PASS тесту не є самостійним мандатом припинити чужу послугу.

## 17. Рівні відновлення та людська безперервність

Ці позначення описують сценарії перевірки WebV і не замінюють технологічні рівні VSS/VCRP.

| Рівень | Втрата | Очікувана межа відновлення |
|---|---|---|
| R0 | Один процес або пристрій | Відновлення локального сервісу з чинними даними та правами |
| R1 | Початковий сервер або один оператор | Альтернативне виявлення, копії й заміна провайдера |
| R2 | Міжрегіональні канали | Локальні острови, відкладені повідомлення, обмежені чинні мандати |
| R3 | Ключ, частина trustees або актуальний key-state | Погоджене recovery, позначення спорів і невизначеності |
| R4 | Тривале живлення чи частина обладнання | Пріоритет критичних даних, носії, паперові процедури, локальні резерви |
| R5 | Значна частина цифрової інфраструктури | Відновлення знань, навичок і базових функцій за VSS/VCRP без обіцянки миттєвої глобальної мережі |

Люди без доступного цифрового запису зберігають базові права та можливість незалежного розгляду. Відновлена паперова заява має своє походження й рівень впевненості; її не перетворюють на вигаданий старий цифровий підпис. Пізніше узгодження зберігає спори, а не стирає життєві події людей, що перебували офлайн.

## 18. Права, вимоги, пропозиції та стан доказів

Нижче статус документації відокремлений від доказу виконання. Усі runtime-рядки цієї редакції є NOT_RUN.

| Право або вимога | Канон | Архітектурний механізм | Статус пропозиції | Runtime / практичний доказ |
|---|---|---|---|---|
| Незалежна реалізація | §49.6, §36.3 | Опубліковані контракти й interoperability-профіль | PROPOSED | NOT_RUN — потрібні незалежні реалізатори |
| Незалежність від Home | §49.10 | Прямий SiteID, альтернативні каталоги | PROPOSED | NOT_RUN — E01–E03 |
| Переносимість | §49.11 | Експорт, повторне імпортування, збереження походження | PROPOSED | NOT_RUN — E09 |
| Особистий контроль ключів | §34.8, §34.16 | Добровільний recovery та розділення інституційних ключів | PROPOSED | NOT_RUN — E05 |
| Приватність контекстів | §34.15, §34.18 | Мінімальне розкриття, розділення метаданих і контенту | PROPOSED | NOT_RUN — E11 |
| Локальна автономія | §§31.9–31.11, §49.14 | Незалежні authority domains | PROPOSED | NOT_RUN — E06–E07 |
| Відсутність подвійних ефектів | §19.8, §31 | Доменні резерви, ідентичність спроб, reconciliation | PROPOSED | NOT_RUN — E07, E10 |
| Добровільний ресурсний внесок | §19.7 | Окремі consent для опису та виконання, ліміти | PROPOSED | NOT_RUN — E10–E12 |
| Обмежена автоматизація | §20 | Scope, строк, бюджет, незалежний admission | PROPOSED | NOT_RUN — E12 |
| Змінний transport | §49.13 | Профілі й перевірені адаптери | PROPOSED | NOT_RUN — E06, E14 |
| Доступність конкретної копії | §34.18 | Утримання, retrieval, repair, failure domains | PROPOSED | NOT_RUN — E04, E14 |
| Відсутність купленої політичної влади | §32.7, §49.15 | Governance окремо від compute/node count | НОРМАТИВНА ВИМОГА | Потребує процедурного пілота; NOT_RUN |
| Зняття центральної залежності | §§49.16–49.18 | Оголошені exit-gates та план безперервності | PROPOSED | NOT_RUN — E01–E16 у застосовному профілі |
| Безперервність прав при деградації | §49.19 | Людський канал, локальні записи, незалежний перегляд | НОРМАТИВНА ВИМОГА | NOT_RUN — E15 |

## 19. Відкриті рішення перед заявою про сумісність

Потрібно окремо обрати й перевірити: криптографічний профіль та canonical encoding; identity anchor і key-transition; правила часу та freshness; alias namespaces; anti-Sybil eligibility й governance каталогів; приватні overlays; retention і storage economics; sandbox для кожного класу workload; transport на конкретних пристроях; міждоменні accounting і dispute-контракти; ліцензійні умови незалежної реалізації.

Без рішення допустимий стан — чітко названий локальний експеримент із відомими peers та обмеженими синтетичними даними. Невизначене питання не дозволяє автору реалізації вигадувати глобальну владу, фінансове право або гарантію сумісності. Усунення одного blocker не підтверджує всі інші.

## 20. Походження рішень і первинні технічні орієнтири

Нормативна основа: Canon 0.17.0, особливо §§16–20, 31–34, 36, 39–40, 49. Архітектурне узгодження виконано з пакетом TOS WebV Resource Router Roadmap Addendum 2026-10-30 v1.0.0, документами 03, 04, 05, 08, 09, 16. Їхній статус proposed не підвищено до реалізованого.

Зовнішні джерела підтримують конкретні технічні обмеження, а не проголошують WebV сумісним із ними:

- **[W1]** [W3C DID Core](https://www.w3.org/TR/did/) — §9.2, §9.9, §10.2: контроль ключа, binding, recovery та контекстна приватність.
- **[W2]** [IPFS: Persistence, permanence, and pinning](https://docs.ipfs.tech/concepts/persistence/) — утримання копій і роль політики зберігання.
- **[W3]** [IPFS: Privacy and encryption](https://docs.ipfs.tech/concepts/privacy-and-encryption/) — публічні мережеві метадані.
- **[W4]** [RFC 9171, Bundle Protocol Version 7](https://www.rfc-editor.org/rfc/rfc9171.html) — store-carry-forward у середовищі з розривами й затримками.
- **[W5]** [etcd: Failure modes](https://etcd.io/docs/v3.5/op-guide/failures/) — кворум та недоступність запису в меншості під час partition.
- **[W6]** [The Chubby lock service](https://storage.googleapis.com/gweb-research2023-media/pubtools/4444.pdf) — §2.4: перевірка покоління повноваження одержувачем операції.

Ця редакція не замінює специфікацій названих систем і не вимагає їх використовувати. Незалежна реалізація повинна документувати обрані профілі та власні результати перевірки.