# User_Onboarding_And_Identity_Layer_v1.md ## DAARION.city — User Onboarding & Identity Layer (DAIS) **Version:** 1.0 **Status:** Core Spec (Foundation Update) **Scope:** Реєстрація користувача, створення агентів, DAIS, wallet-логін, Orchestrator, MicroDAO --- # 0. Мета документа Цей документ описує **повний процес онбордингу користувача** в DAARION.city: * реєстрацію → DAIS-профіль → Agent → Orchestrator → MicroDAO; * Email-OTP та Magic Link; * Web3 Wallet login та SIWE; * правила доступу, ролі та підвищення; * зберігання та синхронізацію ідентичностей; * формування кабінету агента; * перевірку токенів та прав на створення MicroDAO. Документ створено як **неламке оновлення архітектури (non-breaking)**. --- # 1. Загальний огляд онбордингу Онбординг DAARION.city складається з трьох рівнів: 1. **DAIS Identity Layer** — email, wallet, DID, keys → єдиний цифровий профіль. 2. **Agent Creation Layer** — автоматичне створення агента + кабінету при першій реєстрації. 3. **Orchestrator → MicroDAO Layer** — підвищення агента + створення MicroDAO за умовами доступу. Це забезпечує інтуїтивний UX та жорстку архітектурну дисципліну. --- # 2. DAIS Identity Layer DAIS = **DAARION Autonomous Identity System**. Це єдиний простір ідентифікації для людей, агентів і MicroDAO. ## 2.1. Структура DAIS-ідентичності DAIS-ідентичність містить: * **email-identities** (1..N) * **wallet-identities** (EVM / SIWE) * **telegram / TON identities** (майбутнє) * **DID / Matrix identity** * **public keys** (Ed25519 / secp256k1 / X25519) * **signature domains** (підписи для сервісів) * **recovery options** ## 2.2. Інваріанти DAIS 1. Один користувач = одна DAIS-ідентичність. 2. DAIS-профіль може мати багато email'ів і багато wallet'ів. 3. DAIS-профіль створюється **до** створення агента. 4. DAIS-профіль не може бути видалений, тільки ротується/оновлюється. --- # 3. Реєстрація та автентифікація DAARION.city підтримує два базові методи входу: ## 3.1. Email-OTP (One-Time Password) Флоу: 1. Користувач вводить email. 2. Отримує одноразовий код (OTP). 3. Підтверджує код. 4. Створюється/активується DAIS-profile. 5. Створюється Agent + кабінет. Переваги: * Zero-password. * Найменший бар'єр входу. * Підходить для всіх типів користувачів. ## 3.2. Magic Link Флоу: 1. Користувач вводить email. 2. Отримує магічне посилання. 3. Перехід → автоматичний вхід. 4. Створюється DAIS-profile → Agent. ## 3.3. Web3 Wallet Login (SIWE) Підтримка: MetaMask, Rabby, WalletConnect. Флоу: 1. Користувач підключає EVM-гаманець. 2. Підписує SIWE-повідомлення. 3. Створюється/активується DAIS-profile. 4. Гаманець стає частиною DAIS-ідентичності. 5. Створюється Agent. ## 3.4. Синхронізація Email + Wallet Будь-який окремий метод додає ідентичність у DAIS. При об'єднанні email і wallet → DAIS залишається єдиною сутністю. --- # 4. Створення Агентів (Agent Creation Layer) ## 4.1. Коли створюється Agent Agent створюється автоматично при: * першому вході через email OTP, * або першій верифікованій SIWE-сесії, * або при Telegram/TON-верифікації в майбутньому. ## 4.2. Агент отримує: * `agent_id` * `home_microdao_id = DAARION (root)` * `home_node_id = DAARION-root-node` * DAIS-прив'язку * Кабінет агента * Роль: `regular` ## 4.3. Кабінет агента включає: * Wallet overview * Email overview * Agent avatar / profile * Список підключених нод * Доступні сервіси * Статус до MicroDAO * Кнопку «Стати Оркестратором» --- # 5. Перехід у Orchestrator (Orchestrator Promotion) Це ключовий момент. Користувач **не може** створити MicroDAO, поки: * не має агента, * не має оркестраторської ролі, * не виконав умови допуску. ## 5.1. Флоу переходу 1. Користувач натискає «Стати Оркестратором». 2. Система перевіряє **умови доступу**. 3. Якщо всі умови виконано → підвищення агента. 4. Генерується подія `agent.promoted_to_orchestrator`. 5. Роль агента = `orchestrator`. 6. Відкривається Wizard створення MicroDAO. ## 5.2. Умови допуску Умови встановлюються governance DAARION і можуть включати: * прив'язаний Web3-гаманець; * наявність основного токена (DAAR / DAARION); * спеціальний NFT (Founder / Builder / Citizen); * підтверджений email (обов'язково); * мінімальний рівень довіри DAIS; * проста верифікація через Matrix/Telegram. ## 5.3. Інваріанти Orchestrator 1. Кожен Orchestrator — це Agent, але не кожен Agent є Orchestrator. 2. Підвищення — це **одна подія** на агент (необоротна, але можна «заморозити» вручну). 3. Orchestrator може створити багато MicroDAO. --- # 6. Створення MicroDAO Коли агент стає Orchestrator → доступний Wizard створення MicroDAO. ## 6.1. Флоу 1. Старт Wizard: назва, опис, цілі, аватар. 2. Прив'язка DAIS-гаманця MicroDAO. 3. Створення запису `microdao_id`. 4. `primary_orchestrator_agent_id = цей агент`. 5. Ініціалізація governance. 6. Створення простору MicroDAO (канали, кімнати). 7. Генерується подія `microdao.created`. 8. Користувач переходить у кабінет MicroDAO. ## 6.2. Інваріанти MicroDAO в онбордингу 1. Немає MicroDAO без Orchestrator-Agent. 2. MicroDAO створюється саме в момент запуску Wizard, а не раніше. 3. Доступ до створення MicroDAO має лише Orchestrator. --- # 7. Після створення MicroDAO: реєстрація нод MicroDAO одразу отримує можливість: * реєструвати ноди, * прив'язувати пристрої, * запускати сервісних агентів. Флоу: 1. Orchestrator заходить у MicroDAO → Nodes. 2. Обирає «Зареєструвати Ноду». 3. Тип ноди: смартфон, ноут, сервер, IoT, GPU-кластер. 4. Автентифікація через DAIS-ключ. 5. Створюється запис `node_id`. 6. Генерується подія `node.registered`. --- # 8. Значення онбордингу для онтології Оновлений онбординг: * **повністю відповідає онтології** Agent → MicroDAO → Node → District * не ламає поточний UI (кнопка «Створити MicroDAO» зберігається) * додає строгий порядок: 1. DAIS Identity 2. Agent 3. Orchestrator 4. MicroDAO 5. Node 6. District (опційно) --- # 9. Події Stream (NATS) Під час онбордингу фіксуються ключові події: 1. `dais.identity_created` 2. `agent.created` 3. `agent.promoted_to_orchestrator` 4. `microdao.created` 5. `node.registered` 6. (опційно) `microdao.promoted_to_district` --- # 10. Резюме Оновлений онбординг DAARION забезпечує: * єдину ідентичність DAIS * автоматичне створення агента * чіткі умови доступу для Orchestrator * чисту модель MicroDAO * логічний шлях до реєстрації нод * сумісність з майбутнім District Layer * UX, що не ламає існуючих сценаріїв --- Документ №2 завершено.