📃 docs(application): add application's
This commit is contained in:
李东云
@@ -1,6 +1,6 @@
|
||||
# 核心架构
|
||||
|
||||
大道 (Dao OS) 的架构，旨在如一个活的、协同的数字生命体般运作。它由我们用户主权、体验至上和系统韧性的核心原则所指引。本文档将概述其基本组件及它们之间的相互作用。
|
||||
大道 (Dao OS) 的架构，旨在如一个活的、协同的数字生命体般运作。它由我们用户主权、体验至上和系统韧性的核心原则所指引。本文档将概述其基本组件、相互作用，以及我们独特的应用模型。
|
||||
|
||||
## 核心二元性：化身 (Avatar) 与元 (Meta Unit)
|
||||
|
||||
@@ -9,81 +9,33 @@
|
||||
* **化身 (Avatar)**：是“身体”。它们是你的“大道”在你各种设备上的有形存在。
|
||||
* **元 (Meta Unit)**：是“灵魂”。它是内嵌于每个`化身`中的、通用的核心逻辑，赋予其生命与智能。
|
||||
|
||||
## 身体：`化身` (Avatar) —— 用户的临在
|
||||
## “大道”应用模型
|
||||
|
||||
`化身`是你的“大道”在特定平台上的具体显现。你所有的`化身`共同构成了你完整的“大道”。主要有两种类型：**Client 化身**（拥有UI）和 **Agent 化身**（无界面）。用户还可以指定一个强大的`化身`来扮演**主化身/归档节点**的角色。
|
||||
“大道”中的应用，不是一个单一的程序，而是一个去中心化的、解耦的实体，由一个“灵魂”和一个或多个“皮囊”组成。
|
||||
|
||||
## 灵魂：`元` (Meta Unit) —— 通用的内核
|
||||
### 1. 后端灵魂：流体复制与可钉选的服务
|
||||
|
||||
`元`是“大道”的核心逻辑，被编译成一个可移植的 WebAssembly (`.wasm`) 模块。`元`的一个关键特性是其**可进化性**，通过**“化身-元兼容层 (AMCL)”**来实现，它将内核与宿主`化身`进行了解耦。
|
||||
应用的核心逻辑是一个运行在`元`沙箱中的 **WASM 模块**。其部署遵循一种我们称之为 **“服务可钉选的流体复制”** 的混合模型：
|
||||
|
||||
## 核心服务及其架构定位
|
||||
* **流体复制（默认）**: 默认情况下，应用的 WASM 模块会被复制到用户所有有能力的`化身`上。`元`的调度器会智能地决定，在任意时刻，哪个`化身`最适合运行给定的后台任务（例如，一个永不关机的`Agent化身`用来做后台抓取）。这提供了极致的韧性和离线能力。
|
||||
* **服务钉选（高级）**: 对于高级用户，“主权仪表盘”允许他们将某个特定应用的后端服务，“钉选”到一个指定的`化身`上（例如，一台家用服务器）。这提供了对资源分配的明确控制。
|
||||
|
||||
`元`提供了几个核心服务，它们如同这个数字生命体的“器官”。
|
||||
### 2. 前端皮囊：按需加载的 Web 外壳
|
||||
|
||||
### 第二大脑服务
|
||||
应用的用户界面，主要是一个**Web 应用** (HTML/JS/CSS)。这拥抱了最庞大的开发者生态，并确保了最大化的可移植性。其生命周期遵循 **“一次注册，按需加载”** 的模型：
|
||||
|
||||
这是用户的中央信息枢纽，管理着密码、笔记、文件等。在架构上，它服务于双重目的：不仅是被动的数据存储，更是主动为“大道AI”提供支持的**“私有特征库 (Personal Feature Store)”**。每一条数据——一篇笔记、一个日历事件、一位联系人——都被视为一个“特征”，AI可以从中提取信息，以获得对用户上下文的全局理解，从而实现更智能、更个性化的行动。
|
||||
* **注册**: 当用户“安装”一个应用时，他是将其注册到自己的“大道”中。应用的清单（包含其WASM和Web UI资源包的地址）会被同步到所有`化身`。
|
||||
* **按需加载**: 当用户在任何设备上打开该应用时，官方的 **“大道 Web 化身”**（我们的安全Web运行时）会检查其缓存中是否有该应用的UI。如果不存在，它会按需获取UI资源包并进行渲染。
|
||||
|
||||
### P2P 网络服务
|
||||
这个模型意味着，用户只需向他的“大道”安装一次应用，就可以在任何设备上即时访问它，而无需重复安装。
|
||||
|
||||
这个服务基于`libp2p`构建，将一个用户的所有`化身`连接成一个私有的、端到端加密的网络。这构成了系统的“神经系统”。
|
||||
### 3. 数据层：私有特征库
|
||||
|
||||
## “云-边-端”协同网络
|
||||
所有应用的数据，都安全地存储在由`元`管理的 **“第二大脑”** 中。在架构上，“第二大脑”扮演着AI的 **“私有特征库 (Personal Feature Store)”** 的角色，为智能决策提供丰富的、多模态的上下文（笔记、事件、联系人等）。
|
||||
|
||||
这个私有的P2P网络，促成了一个跨越三个层级的协同智能系统：轻量级的**端 (Client)**（终端），强大的**边 (Edge)**设备（本地AI处理），以及用户的私有**云 (Cloud)**（作为完整数据和远程推理能力的主化身/归档节点）。
|
||||
## 架构总结
|
||||
|
||||
## 新陈代谢系统：资源感知与自适应系统
|
||||
* **化身 (Avatar)**：作为`元`的原生宿主，以及应用UI的渲染器（主要通过“大道 Web 化身”）。
|
||||
* **元 (Meta Unit)**：主权核心，负责运行沙箱化的应用逻辑（WASM），管理所有数据和状态，并在用户的私有P2P网络中协调任务。
|
||||
|
||||
“大道”被设计成一个体贴的伙伴，而非一个资源怪兽。它的“新陈代谢”由一个内置的资源管理系统来调节，具备三大特性：
|
||||
|
||||
* **智能数据分层**：管理“热数据”和“冷数据”以节省空间。
|
||||
* **自适应同步策略**：根据网络和电量状态调整同步行为。
|
||||
* **优雅降级**：根据硬件能力平滑缩放用户体验。
|
||||
|
||||
这些架构组件共同构成了一个主权的、坚韧的、智能的系统，一个真正属于用户的生命延伸。
|
||||
|
||||
# 核心架构
|
||||
|
||||
大道 (Dao OS) 的架构，旨在如一个活的、协同的数字生命体般运作。它由我们用户主权、体验至上和系统韧性的核心原则所指引。本文档将概述其基本组件及它们之间的相互作用。
|
||||
|
||||
## 核心二元性：化身 (Avatar) 与元 (Meta Unit)
|
||||
|
||||
在其核心，大道 (Dao OS) 基于一个简单而强大的二元性运作，类似于身体与灵魂：
|
||||
|
||||
* **化身 (Avatar)**：是“身体”。它们是你的“大道”在你各种设备上的有形存在。
|
||||
* **元 (Meta Unit)**：是“灵魂”。它是内嵌于每个`化身`中的、通用的核心逻辑，赋予其生命与智能。
|
||||
|
||||
## 身体：`化身` (Avatar) —— 用户的临在
|
||||
|
||||
`化身`是你的“大道”在特定平台上的具体显现。你所有的`化身`共同构成了你完整的“大道”。主要有两种类型：**Client 化身**（拥有UI）和 **Agent 化身**（无界面）。用户还可以指定一个强大的`化身`来扮演**主化身/归档节点**的角色。
|
||||
|
||||
## 灵魂：`元` (Meta Unit) —— 通用的内核
|
||||
|
||||
`元`是“大道”的核心逻辑，被编译成一个可移植的 WebAssembly (`.wasm`) 模块。`元`的一个关键特性是其**可进化性**，通过**“化身-元兼容层 (AMCL)”**来实现，它将内核与宿主`化身`进行了解耦。
|
||||
|
||||
## 核心服务及其架构定位
|
||||
|
||||
`元`提供了几个核心服务，它们如同这个数字生命体的“器官”。
|
||||
|
||||
### 第二大脑服务
|
||||
|
||||
这是用户的中央信息枢纽，管理着密码、笔记、文件等。在架构上，它服务于双重目的：不仅是被动的数据存储，更是主动为“大道AI”提供支持的**“私有特征库 (Personal Feature Store)”**。每一条数据——一篇笔记、一个日历事件、一位联系人——都被视为一个“特征”，AI可以从中提取信息，以获得对用户上下文的全局理解，从而实现更智能、更个性化的行动。
|
||||
|
||||
### P2P 网络服务
|
||||
|
||||
这个服务基于`libp2p`构建，将一个用户的所有`化身`连接成一个私有的、端到端加密的网络。这构成了系统的“神经系统”。
|
||||
|
||||
## “云-边-端”协同网络
|
||||
|
||||
这个私有的P2P网络，促成了一个跨越三个层级的协同智能系统：轻量级的**端 (Client)**（终端），强大的**边 (Edge)**设备（本地AI处理），以及用户的私有**云 (Cloud)**（作为完整数据和远程推理能力的主化身/归档节点）。
|
||||
|
||||
## 新陈代谢系统：资源感知与自适应系统
|
||||
|
||||
“大道”被设计成一个体贴的伙伴，而非一个资源怪兽。它的“新陈代谢”由一个内置的资源管理系统来调节，具备三大特性：
|
||||
|
||||
* **智能数据分层**：管理“热数据”和“冷数据”以节省空间。
|
||||
* **自适应同步策略**：根据网络和电量状态调整同步行为。
|
||||
* **优雅降级**：根据硬件能力平滑缩放用户体验。
|
||||
|
||||
这些架构组件共同构成了一个主权的、坚韧的、智能的系统，一个真正属于用户的生命延伸。
|
||||
这种解耦的架构，使得“大道”上的应用安全、坚韧、无缝跨平台，并且对于开发者构建和用户管理都极其简单。
|
||||
|
||||
@@ -1,50 +1,52 @@
|
||||
# 用户旅程：从便利到主权
|
||||
|
||||
任何主权系统的一个核心挑战，都在于“绝对控制”与“轻松便利”之间的张力。大道 (Dao OS) 解决这个问题的方式，不是强迫用户二选一，而是设计了一场充满引导、相互尊重的**“渐进式主权”**之旅。我们在用户熟悉的地方与他们相遇，并赋能他们去往任何他们想去的地方。
|
||||
任何主权系统的一个核心挑战，都在于“绝对控制”与“轻松便利”之间的张力。“大道”解决这个问题的方式，不是强迫用户二选一，而是设计了一场充满引导、相互尊重的**“渐进式主权”**之旅。我们在用户熟悉的地方与他们相遇，并赋能他们去往任何他们想去的地方。
|
||||
|
||||
这场旅程由几个阶段组成，从无缝的上手体验，到最终的数字自治。
|
||||
这场旅程由几个阶段组成，从无缝的上手体验，到最终的数字自治。它不仅适用于用户对核心数据的掌控，也同样适用于他们与应用交互的方式。
|
||||
|
||||
## 第一步：欢迎仪式
|
||||
## 应用之旅：一次注册，随处使用
|
||||
|
||||
用户与“大道”的初次互动，不是一个冰冷的设置界面，而是一场温暖的、交互式的欢迎仪式，旨在提供即时价值和引导。
|
||||
在“大道”中安装应用，与传统应用商店有着本质的不同。它不是将一个程序安装到单一的设备上，而是为你整个的数字生命体——你的“大道”——授予一项新的能力。
|
||||
|
||||
这个**“引导式数据播种”**过程，会指引新用户完成：
|
||||
### 1. 发现与信任
|
||||
|
||||
* **导入现有数据**：“让我们从保护您的数字生活开始。您可以从浏览器或其他密码管理器中导入您的密码。”
|
||||
* **创造初始内容**：“伟大的计划始于第一个想法。让我们写下您的第一条笔记吧——或许是您这个月最重要的三个目标？”
|
||||
* **设定偏好**：“为了帮您过滤噪音，您最感兴趣的3-5个领域是什么？”
|
||||
旅程始于一个去中心化的发现界面。当你找到一个像“资讯中枢”这样的应用时，你看到的不仅仅是一个下载按钮，还有它的**“信任仪表盘”**，其中包括：
|
||||
|
||||
这个过程在为用户的“第二大脑”填充初始高价值数据的同时，也以一种极具参与感的方式，教会了他们系统的核心功能。
|
||||
* 来自自动化 `dao-verify` 安全与合规扫描的结果。
|
||||
* 为其背书的、有信誉的社区开发者或组织列表。
|
||||
* 用户评价与评级。
|
||||
这让你能基于可验证的数据和社会化证明，做出知情的决定。
|
||||
|
||||
## 第一阶段：“托管模式” (Managed Mode) —— 你的向导之旅
|
||||
### 2. 注册与授权 (即“安装”)
|
||||
|
||||
默认情况下，每一位新用户都从“托管模式”开始。此阶段旨在提供如最佳云服务般简单可靠的体验，完全消除了自主保管（密钥）的初始技术负担。
|
||||
当你决定“安装”应用时，系统会向你展示它的**“应用清单 (Manifest)”**。这是一个清晰的、人类可读的列表，说明了该应用运行所需的权限（例如：“请求读写您‘第二大脑’中的笔记”、“请求运行后台网络任务”）。
|
||||
|
||||
此阶段的核心特性包括：
|
||||
你对这份清单的明确批准，就是那一次性的“安装”事件。这个行为将该应用**“注册”**到你的“大道”中，这个注册状态会被同步到你所有的`化身`。
|
||||
|
||||
* **友好的密钥管理**：我们不使用24个单词的助记词来面对用户，而是采用更友好的恢复方式，如**“社交恢复”**（由信任的联系人帮助恢复账户）或多因子恢复。
|
||||
* **默认同步节点**：用户的`化身`会自动连接到一个由“大道基金会”维护的、可靠的、高可用的引导节点。这确保了用户开箱即可获得完美、快速的跨设备同步体验。
|
||||
### 3. 无缝的跨设备访问
|
||||
|
||||
最关键的是，即便在此模式下，用户的所有数据依然是**端到端加密**的。“托管”的方面仅适用于可用性和密钥恢复，绝不涉及数据隐私。
|
||||
一旦注册，该应用就成为你“大道”的一部分，无需重复安装，即可在任何设备上访问。
|
||||
|
||||
## 十字路口：主权仪表盘 (Sovereignty Dashboard)
|
||||
* **在你的手机上**: 你点击新的“资讯中枢”图标。“大道 Web 化身”会即时加载其 Web 界面，很可能是从本地缓存加载。体验是即时的。
|
||||
* **在一台新笔记本上**: 你首次登录你的`化身`。你会发现“资讯中枢”的图标**已经在那儿了**。当你点击它，“大道 Web 化身”会识别出这个注册，首次从网络获取UI资源包，缓存它，然后运行应用。完全无需访问任何“应用商店”。
|
||||
|
||||
“主权仪表盘”是用户通往自治之旅的指挥中心。它不仅是一个设置面板，更是一个赋能与教育的工具。
|
||||
### 4. 高级配置
|
||||
|
||||
它有三个功能：
|
||||
这段旅程与你的主权之旅紧密相连。在任何时候，你都可以进入你的**“主权仪表盘”**来：
|
||||
|
||||
1. **可视化**：它用清晰的图表，展示用户当前的主权状态：“您的数据存储在您的3个化身中”，“您的账户恢复由您的手机、您的伴侣和一个基金会节点共同保障”。
|
||||
2. **无压力教育**：它用简单易懂的语言，解释“什么是主密钥？”或“自托管的好处”等概念。
|
||||
3. **游戏化升级**：它提供一系列“主权任务”（例如“备份您的主密钥”），用户在完成后，会获得徽章以及一种切实的前进感和成就感。
|
||||
* 审查并撤销你授予该应用的权限。
|
||||
* 使用**“服务钉选 (Service Pinning)”**功能，将其后端任务指定给你专属的`Agent化身`，从而完全控制你的资源分配。
|
||||
|
||||
## 第二阶段：“主权模式” (Sovereign Mode) —— 你的数字王国
|
||||
## 主权之旅的阶段
|
||||
|
||||
这是旅程的最终、可选阶段，专为那些渴望完全、绝对控制的用户而设。在“主权仪表盘”的引导下，用户可以在任何时候“毕业”到此模式。
|
||||
### 第一阶段：“托管模式” (Managed Mode) —— 你的向导之旅
|
||||
|
||||
在“主权模式”下，用户将：
|
||||
默认情况下，每一位新用户都从“托管模式”开始。此阶段旨在提供如最佳云服务般简单可靠的体验，完全消除了自主保管密钥的初始技术负担。它采用友好的密钥恢复方法和默认同步节点，同时保持完全的端到端加密。
|
||||
|
||||
* 完全**自主保管**他们的**主密钥**（助记词），移除任何由基金会托管的恢复分片。
|
||||
* 断开与默认引导节点的连接，完全依赖纯P2P网络，或在自己的**私有服务器上部署`Agent化身`**。
|
||||
* 实现对任何中心化服务的100%独立，成为其数字领地中真正的、唯一的主人。
|
||||
### 第二阶段：主权仪表盘 (Sovereignty Dashboard) —— 十字路口
|
||||
|
||||
“大道”的旅程旨在赋能，而非恐吓。它允许每位用户找到自己的舒适区，在提供一个安全的“便利港湾”的同时，也永远让那座象征完全主权的“灯塔”，在远方清晰地闪耀。
|
||||
这是用户通往自治之旅的指挥中心。它是一个赋能与教育的工具，将用户的主权状态可视化，并提供游戏化的“任务”来鼓励用户获取更多控制权。
|
||||
|
||||
### 第三阶段：“主权模式” (Sovereign Mode) —— 你的数字王国
|
||||
|
||||
这是旅程的最终、可选阶段，专为那些渴望完全、绝对控制的用户而设。在“主权仪表盘”的引导下，用户可以“毕业”到此模式，完全自主保管他们的密钥并运行自己的服务器节点，成为其数字领地中真正的主人。
|
||||
|
||||
@@ -6,41 +6,45 @@
|
||||
|
||||
我们的工程决策由一套核心原则指引，以确保系统是健壮、可移植和开放的。
|
||||
|
||||
* **Web原生与可移植性 (Web-Native & Portable)**: 我们利用源自Web的技术（如 WebAssembly），来创建一个单一的、可移植的核心，使其能运行在任何地方——桌面、手机、服务器和浏览器中。
|
||||
* **通过WASM实现多语言主义 (Polyglotism via WASM)**: 核心逻辑（`元`）被编译成 WebAssembly (WASM)。这使得“化身”可以用任何能够承载WASM运行时的语言（如 Rust, Swift, Kotlin, TypeScript, Go 等）来编写，从而创造一个真正多样化的生态系统。
|
||||
* **API优先 (API-First)**: 核心`元`与宿主`化身`之间的交互，由一个严格的、版本化的API契约来定义。这解耦了开发过程，并允许双方独立演进。
|
||||
* **安全第一 (Security-First)**: 我们采用业界顶级的加密协议和“最小权限原则”设计。安全不是事后补救，而是一个先决条件。
|
||||
* **Web原生与可移植性 (Web-Native & Portable)**: 我们将源自Web的技术（如 WebAssembly 和现代 Web UI 框架）作为应用开发的**主路径**。这能创建一个单一的、可移植的核心，使其能运行在任何地方。
|
||||
* **通过WASM实现多语言主义 (Polyglotism via WASM)**: 核心应用逻辑（`服务模块`）被编译成 WebAssembly (WASM)。这使得逻辑部分可以用 Rust, Go 等语言编写。
|
||||
* **API优先 (API-First)**: 应用逻辑和用户界面之间的交互，由一个严格的、版本化的API契约来定义，以实现真正的解耦。
|
||||
* **安全第一 (Security-First)**: 我们采用业界顶级的加密协议和“最小权限原则”设计，所有第三方应用逻辑都运行在安全的沙箱中。
|
||||
* **自由及开源软件 (FOSS)**: 整个核心协议和参考实现都是开源的，以促进透明度、社区信任和协作创新。
|
||||
|
||||
## 核心组件：开发者视角
|
||||
|
||||
从开发者的角度看，系统由两个主要部分组成，它们通过一个明确定义的边界进行交互。
|
||||
从开发者的角度看，“大道”应用由一个后端的“灵魂”和一个前端的“皮囊”组成，它们通过一个明确定义的边界进行交互。我们将开发路径设计得尽可能地平易近人。
|
||||
|
||||
1. **`元` (Meta Unit - WASM 模块)**: 这是系统的可移植的、逻辑核心。它是一个有状态的、单实例的模块，主要使用 **Rust** 开发，以保证其性能和安全性。它包含了数据管理、AI和P2P协调的所有业务逻辑，但它没有直接访问外部世界的能力。
|
||||
### 1. 应用服务模块 (WASM 后端)
|
||||
|
||||
2. **`化身` (Avatar - 原生宿主)**: 这是“承载”`元`的原生应用程序或运行时环境。其主要职责是：
|
||||
* 提供一个 **WASM 运行时** 来加载和执行`元`。
|
||||
* 提供**用户界面**（对于 Client 化身）。
|
||||
* 作为连接到宿主操作系统的**桥梁**，提供对文件系统、网络和其他系统资源的访问。
|
||||
这是第三方应用的可移植的、逻辑核心。它是一个有状态的 WASM 模块，主要使用 **Rust**（或其他WASM兼容语言）开发。它包含了所有的业务逻辑，并且是唯一能请求访问用户“第二大脑”或其它`元`核心服务的组件。
|
||||
|
||||
## API 契约：WASM 接口
|
||||
### 2. 应用 UI (前端)
|
||||
|
||||
`化身`和`元`之间的通信，遵循一个清晰的、双向的API契约，其精神类似于 WASI (WebAssembly 系统接口)。
|
||||
#### 主路径：面向“大道 Web 化身”进行开发
|
||||
|
||||
* **`yuan_*` (从“元”导出)**: `元`导出一系列函数供`化身`调用。主要的入口点是 `yuan_handle_request`，它接收来自`化身`的结构化请求并进行处理。
|
||||
为了最大化可移植性并降低入门门槛，构建“大道”应用UI的主路径是创建一个**标准的 Web 应用**（使用 React, Vue, Svelte 等）。
|
||||
|
||||
* **`avatar_*` (导入到“元”)**: `元`声明了一系列它需要`化身`宿主提供的函数。这些函数是它通往外部世界的唯一窗口，允许它请求诸如记录日志（`avatar_log`）或发起网络请求（`avatar_net_request`）等操作。
|
||||
这个 Web UI 运行在我们官方的、安全的**“大道 Web 化身”**容器之内，该容器跨所有平台（iOS, Android, 桌面端）。你的 Web UI 与你的 WASM 后端之间的通信，通过我们提供的一个安全的 **`dao.js` JavaScript 桥**来处理。这意味着，开发者只需**编写一个 WASM 后端和一个 Web UI 前端**，他的应用就能运行在所有地方。
|
||||
|
||||
* **数据序列化 (Data Serialization)**: 为了高效、安全地跨越 WASM 内存边界传递复杂的数据结构，我们使用 **Protocol Buffers (Protobuf)**。数据被序列化成字节流，通过指针和长度传递，然后在另一端反序列化。
|
||||
#### 高级路径：构建原生化身外壳
|
||||
|
||||
对于那些需要深度平台集成或极致原生性能的开发者，我们依然保留了构建一个完全原生UI“皮囊”的可能性。这个原生应用将简单地作为`元`的另一个宿主，并通过 API 契约与同一个 WASM 后端服务通信。这被视为一个可选的增强项，而非必需项。
|
||||
|
||||
## API 契约：`dao.js` 桥接脚本
|
||||
|
||||
对于基于 Web 的 UI，通信契约通过注入到 webview 中的 `window.dao` JavaScript 对象来暴露。开发者使用这个桥接脚本，将经过 Protobuf 序列化的请求发送给运行在`元`中的应用服务模块，并异步地接收响应。
|
||||
|
||||
## 关键技术与协议
|
||||
|
||||
| 类别 | 技术 / 协议 | 用途 |
|
||||
| :--- | :--- | :--- |
|
||||
| **核心逻辑** | Rust / WebAssembly (WASM) | 性能、安全与极致的可移植性。 |
|
||||
| **P2P网络** | `libp2p` | 模块化的节点发现(DHT)、传输和安全通道。 |
|
||||
| **数据同步** | 无冲突复制数据类型 (CRDTs) | 确保在没有中心服务器的情况下，各`化身`间的最终一致性。 |
|
||||
| **身份** | DID & VC (去中心化标识符 & 可验证凭证) | 主权身份与可互操作的、基于密码学的信任。 |
|
||||
| **后端逻辑** | Rust / WebAssembly (WASM) | 性能、安全与极致的可移植性。 |
|
||||
| **前端UI** | Web 技术栈 (HTML, CSS, JS/TS) | 跨平台 UI 开发的主路径。 |
|
||||
| **P2P网络** | `libp2p` | 模块化的节点发现、传输和安全通道。 |
|
||||
| **数据同步** | 无冲突复制数据类型 (CRDTs) | 确保各`化身`间的最终一致性。 |
|
||||
| **身份** | DID & VC | 主权身份与可互操作的、基于密码学的信任。 |
|
||||
| **数据序列化** | Protocol Buffers (Protobuf) | 用于API的高效、语言无关的数据结构。 |
|
||||
|
||||
这套模块化的、基于开放协议的体系，专为安全、可移植以及最重要的——社区贡献而设计。
|
||||
这套模块化的、以Web为中心的、基于开放协议的体系，专为安全、可移植以及最重要的——社区贡献而设计。
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Core Architecture
|
||||
|
||||
The architecture of Dao OS is designed to function like a living, collaborative digital organism. It is guided by our core principles of sovereignty, experience, and resilience. This document outlines the fundamental components and their interplay.
|
||||
The architecture of Dao OS is designed to function like a living, collaborative digital organism. It is guided by our core principles of sovereignty, experience, and resilience. This document outlines the fundamental components and their interplay, including our unique application model.
|
||||
|
||||
## The Core Duality: Avatars & The Meta Unit
|
||||
|
||||
@@ -9,36 +9,33 @@ At its heart, Dao OS operates on a simple yet powerful duality, analogous to a b
|
||||
* **Avatars (`化身`)**: The "bodies." They are the tangible presence of your Dao OS on your various devices.
|
||||
* **The Meta Unit (`元`)**: The "soul." It is the universal, core logic embedded within each Avatar, giving it life and intelligence.
|
||||
|
||||
## The Body: `Avatar` — A User's Presence
|
||||
## The Dao OS Application Model
|
||||
|
||||
An Avatar is the concrete manifestation of your Dao OS on a specific platform. All of your Avatars collectively form your complete Dao. There are two primary types: **Client Avatars** (with UI) and **Agent Avatars** (headless). A user can also designate a powerful Avatar to act as their **Primary/Archive Node**.
|
||||
An application in Dao OS is not a monolithic program but a decentralized, decoupled entity composed of a "soul" and one or more "skins."
|
||||
|
||||
## The Soul: `Meta Unit` — The Universal Kernel
|
||||
### 1. The Backend Soul: The Fluid & Pinnable Service
|
||||
|
||||
The Meta Unit is the core logic of Dao OS, compiled into a portable WebAssembly (`.wasm`) module. A key characteristic of the Meta Unit is its **evolvability**, enabled by the **Avatar-Meta Compatibility Layer (AMCL)**, which decouples the kernel from the host Avatars.
|
||||
The application's core logic is a **WASM module** that runs sandboxed within the Meta Unit. Its deployment follows a hybrid model we call **Fluid Replication with Service Pinning**:
|
||||
|
||||
## Core Services & Their Architectural Role
|
||||
* **Fluid Replication (Default)**: By default, the application's WASM module is replicated across all of the user's capable Avatars. The Meta Unit's scheduler intelligently decides which Avatar is best suited to run a given backend task at any moment (e.g., an always-on Agent Avatar for background fetching). This provides maximum resilience and offline capability.
|
||||
* **Service Pinning (Advanced)**: For advanced users, the "Sovereignty Dashboard" allows them to "pin" a specific application's backend service to a designated Avatar (e.g., a home server). This provides explicit control over resource allocation.
|
||||
|
||||
The Meta Unit provides several core services that function as the "organs" of the digital life form.
|
||||
### 2. The Frontend Skin: The On-Demand Web Shell
|
||||
|
||||
### The Second Brain Service
|
||||
The application's user interface is primarily a **Web Application** (HTML/JS/CSS). This embraces the largest developer ecosystem and ensures maximum portability. Its lifecycle follows a **"Register Once, Load On-Demand"** model:
|
||||
|
||||
This is the central information hub for the user, managing passwords, notes, files, and more. Architecturally, it serves a dual purpose: not just as passive storage, but as an active **Personal Feature Store** for the Dao OS AI. Each piece of data—a note, a calendar event, a contact—is treated as a "feature" that the AI can draw upon to gain a holistic understanding of the user's context, enabling more intelligent and personalized actions.
|
||||
* **Registration**: When a user "installs" an app, they are registering it with their Dao. The app's manifest (containing the locations of its WASM and Web UI bundles) is synced to all Avatars.
|
||||
* **On-Demand Loading**: When the user opens the app on any device, the official **"Dao Web Avatar"** (our secure web runtime) checks its cache for the app's UI. If not present, it fetches the UI bundle on-demand and renders it.
|
||||
|
||||
### The P2P Networking Service
|
||||
This model means a user installs an app once to their Dao, and can then instantly access it on any device without repeated installations.
|
||||
|
||||
This service, built on `libp2p`, connects all of a user's Avatars into a private, end-to-end encrypted network. This forms the system's "nervous system."
|
||||
### 3. The Data Layer: The Personal Feature Store
|
||||
|
||||
## The "Cloud-Edge-Client" Collaborative Network
|
||||
The data for all applications is stored securely in the user's **Second Brain**, which is managed by the Meta Unit. Architecturally, the Second Brain acts as a **Personal Feature Store** for the AI, providing rich, multi-modal context (notes, events, contacts, etc.) for intelligent decision-making.
|
||||
|
||||
This private P2P network enables a collaborative intelligence system across three tiers: lightweight **Clients** (terminals), powerful **Edge** devices (local AI processing), and the user's personal **Cloud** (the Primary/Archive Node for complete data and remote inference).
|
||||
## Architectural Summary
|
||||
|
||||
## The Metabolism: The Resource-Aware & Adaptive System
|
||||
* **Avatars**: Act as native hosts for the Meta Unit and renderers for application UIs (primarily via the Dao Web Avatar).
|
||||
* **Meta Unit**: The sovereign core that runs sandboxed application logic (WASM), manages all data and state, and orchestrates tasks across the user's private P2P network.
|
||||
|
||||
Dao OS is designed to be a considerate partner. Its "metabolism" is regulated by a built-in resource management system featuring:
|
||||
|
||||
* **Intelligent Data Tiering**: Manages "hot" and "cold" data to save space.
|
||||
* **Adaptive Synchronization Policies**: Adjusts sync behavior based on network and battery status.
|
||||
* **Graceful Degradation**: Scales the user experience according to hardware capabilities.
|
||||
|
||||
Together, these architectural components form a sovereign, resilient, and intelligent system that is truly an extension of the user.
|
||||
This decoupled architecture makes applications on Dao OS secure, resilient, seamlessly cross-platform, and incredibly easy for developers to build and for users to manage.
|
||||
|
||||
@@ -2,49 +2,51 @@
|
||||
|
||||
A core challenge for any sovereign system is the tension between absolute control and effortless convenience. Dao OS resolves this not by forcing a choice, but by designing a guided, respectful **"Progressive Sovereignty"** journey. We meet users where they are and empower them to travel as far as they wish.
|
||||
|
||||
This journey consists of several stages, from a seamless onboarding to ultimate digital autonomy.
|
||||
This journey consists of several stages, from a seamless onboarding to ultimate digital autonomy. It applies not only to the user's control over their core data, but also to how they interact with applications.
|
||||
|
||||
## The First Step: The Welcome Ceremony
|
||||
## The Application Journey: Register Once, Use Anywhere
|
||||
|
||||
A user's first interaction with Dao OS is not a cold setup screen, but a warm, interactive welcoming ceremony designed to provide immediate value and education.
|
||||
Installing an application in Dao OS is fundamentally different from a traditional app store. It's not about putting a program onto a single device; it's about granting a new capability to your entire digital life-form—your Dao.
|
||||
|
||||
This **Interactive Data Seeding** process guides the new user through:
|
||||
### 1. Discovery and Trust
|
||||
|
||||
* **Importing existing data**: "Let's begin by securing your digital life. You can import your passwords from your browser or another password manager."
|
||||
* **Creating initial content**: "Great plans start with a single thought. Let's write your first note—perhaps your top three goals for this month?"
|
||||
* **Setting preferences**: "To help me filter the noise, what are 3-5 topics you're most interested in?"
|
||||
The journey begins in a decentralized discovery interface. When you find an application like "Info Hub," you are not just presented with a download button. You see its **Trust Dashboard**, which includes:
|
||||
|
||||
This process simultaneously populates the user's "Second Brain" with initial high-value data and teaches them the core functionalities of the system in an engaging way.
|
||||
* Results from the automated `dao-verify` security and compliance scans.
|
||||
* A list of reputable community developers or organizations that have vouched for the app.
|
||||
* User reviews and ratings.
|
||||
This allows you to make an informed decision based on verifiable data and social proof.
|
||||
|
||||
## Stage One: The "Managed Mode" — Your Guided Tour
|
||||
### 2. Registration and Permissioning (The "Install")
|
||||
|
||||
By default, every new user begins in Managed Mode. This stage is designed to feel as simple and reliable as the best cloud services, completely removing the initial technical burden of self-custody.
|
||||
When you decide to "install" the app, you are shown its **Manifest**. This is a clear, human-readable list of permissions the application requires to function (e.g., "Permission to read and write notes in your Second Brain," "Permission to run background tasks").
|
||||
|
||||
Key features of this stage include:
|
||||
Your explicit approval of this manifest is the one-time "installation" event. This act **registers** the application with your Dao, and this registration is synced across all your Avatars.
|
||||
|
||||
* **Friendly Key Management**: Instead of immediately confronting the user with a 24-word seed phrase, we use user-friendly recovery methods like **Social Recovery** (where trusted contacts can help recover an account) or multi-factor recovery.
|
||||
* **Default Sync Nodes**: The user's Avatars automatically connect to a reliable, high-availability bootstrap node maintained by the Dao OS foundation. This ensures a flawless and fast cross-device sync experience out of the box.
|
||||
### 3. Seamless Cross-Device Access
|
||||
|
||||
Crucially, even in this mode, all user data is **end-to-end encrypted**. The "managed" aspect applies only to availability and key recovery, never to data privacy.
|
||||
Once registered, the application becomes a part of your Dao, accessible on any device without re-installation.
|
||||
|
||||
## The Crossroads: The Sovereignty Dashboard
|
||||
* **On your Phone**: You tap the new "Info Hub" icon. The Dao Web Avatar instantly loads its web-based UI, likely from a local cache. The experience is immediate.
|
||||
* **On a New Laptop**: You log into your Dao Avatar for the first time. You'll see the "Info Hub" icon is already there. When you click it, the Dao Web Avatar on your laptop recognizes the registration, fetches the UI bundle from the network for the first time, caches it, and runs the application. No visit to an "app store" is required.
|
||||
|
||||
The Sovereignty Dashboard is the user's command center for their journey towards autonomy. It is not just a settings panel, but an educational and empowering tool.
|
||||
### 4. Advanced Configuration
|
||||
|
||||
It serves three functions:
|
||||
The journey connects back to your sovereignty. At any time, you can go into your **Sovereignty Dashboard** to:
|
||||
|
||||
1. **Visualization**: It provides a clear, graphical representation of the user's current sovereignty status: "Your data is stored on your 3 Avatars," "Your account recovery is secured by your phone, your partner, and one foundation node."
|
||||
2. **Education**: It offers simple, jargon-free explanations of concepts like "What is a Master Key?" or "The benefits of self-hosting."
|
||||
3. **Gamification**: It presents a series of "Sovereignty Missions" (e.g., "Back up your Master Key") that, upon completion, award the user with badges and a tangible sense of progression and achievement.
|
||||
* Review and revoke the permissions you granted to the application.
|
||||
* Use the **Service Pinning** feature to assign the application's backend tasks to a specific Agent Avatar, taking full control over your resource allocation.
|
||||
|
||||
## Stage Two: The "Sovereign Mode" — Your Digital Kingdom
|
||||
## The Sovereignty Journey Stages
|
||||
|
||||
This is the final, optional stage of the journey for users who desire complete and absolute control. Guided by the Sovereignty Dashboard, a user can "graduate" to this mode at any time.
|
||||
### Stage One: The "Managed Mode" — Your Guided Tour
|
||||
|
||||
In Sovereign Mode, the user:
|
||||
By default, every new user begins in Managed Mode. This stage is designed to feel as simple and reliable as the best cloud services, completely removing the initial technical burden of self-custody. It uses friendly key recovery methods and default sync nodes while maintaining full end-to-end encryption.
|
||||
|
||||
* Takes full self-custody of their **Master Key** (seed phrase), removing any foundation-held recovery shards.
|
||||
* Disconnects from default bootstrap nodes, relying either on the pure P2P network or on their **self-hosted Agent Avatar** (e.g., on a home server).
|
||||
* Achieves 100% independence from any central service, becoming the true and only master of their digital domain.
|
||||
### Stage Two: The Sovereignty Dashboard — The Crossroads
|
||||
|
||||
The Dao OS journey is designed to be empowering, not intimidating. It allows every user to find their own comfort level, providing a safe harbor of convenience while always keeping the lighthouse of full sovereignty shining brightly on the horizon.
|
||||
This is the user's command center for their journey towards autonomy. It's an educational and empowering tool that visualizes their sovereignty status and provides gamified "missions" to encourage them to take more control.
|
||||
|
||||
### Stage Three: The "Sovereign Mode" — Your Digital Kingdom
|
||||
|
||||
This is the final, optional stage for users who desire complete and absolute control. Guided by the Sovereignty Dashboard, a user can "graduate" to this mode, taking full self-custody of their keys and running their own server nodes, becoming the true master of their digital domain.
|
||||
|
||||
@@ -6,41 +6,45 @@ This document provides a high-level overview of the architecture, core technolog
|
||||
|
||||
Our engineering decisions are guided by a set of core principles to ensure the system is robust, portable, and open.
|
||||
|
||||
* **Web-Native & Portable**: We leverage technologies born from the web (like WebAssembly) to create a single, portable core that can run anywhere—on desktops, mobile phones, servers, and in the browser.
|
||||
* **Polyglotism via WASM**: The core logic (`Meta Unit`) is compiled to WebAssembly (WASM). This allows "Avatars" to be written in any language (Rust, Swift, Kotlin, TypeScript, Go, etc.) that can host a WASM runtime, creating a truly diverse ecosystem.
|
||||
* **API-First**: The interaction between the core `Meta Unit` and the host `Avatar` is defined by a strict, versioned API contract. This decouples development and allows for independent evolution.
|
||||
* **Security-First**: We employ best-in-class cryptographic protocols and a "principle of least privilege" design. Security is not an afterthought; it is a prerequisite.
|
||||
* **Web-Native & Portable**: We leverage technologies born from the web (like WebAssembly and modern web UI frameworks) as the **primary path** for application development. This creates a single, portable core that can run anywhere.
|
||||
* **Polyglotism via WASM**: The core application logic (`Service Module`) is compiled to WebAssembly (WASM). This allows the logic to be written in languages like Rust, Go, etc.
|
||||
* **API-First**: The interaction between application logic and the user interface is defined by a strict, versioned API contract, enabling true decoupling.
|
||||
* **Security-First**: We employ best-in-class cryptographic protocols and a "principle of least privilege" design, with all third-party application logic running in a secure sandbox.
|
||||
* **FOSS (Free and Open Source Software)**: The entire core protocol and reference implementations are open source to foster transparency, community trust, and collaborative innovation.
|
||||
|
||||
## The Core Components: A Developer's View
|
||||
|
||||
From a developer's perspective, the system consists of two main parts that interact via a well-defined boundary.
|
||||
From a developer's perspective, a Dao OS application consists of a backend "soul" and a frontend "skin" that interact via a well-defined boundary. We have designed the development path to be as accessible as possible.
|
||||
|
||||
1. **The `Meta Unit` (WASM Module)**: This is the portable, logical core of the system. It is a stateful, single-instance module developed primarily in **Rust** for its performance and safety guarantees. It contains all the business logic for data management, AI, and peer-to-peer coordination, but it has no direct access to the outside world.
|
||||
### 1. The App Service Module (WASM Backend)
|
||||
|
||||
2. **The `Avatar` (Native Host)**: This is the native application or runtime environment that "hosts" the Meta Unit. Its primary responsibilities are:
|
||||
* Providing a **WASM runtime** to load and execute the `Meta Unit`.
|
||||
* Providing a **User Interface** (for Client Avatars).
|
||||
* Acting as a **bridge** to the host operating system, providing access to the filesystem, network, and other system resources.
|
||||
This is the portable, logical core of a third-party application. It is a stateful WASM module developed primarily in **Rust** (or other WASM-compatible languages). It contains all the business logic and is the only component that can request access to the user's Second Brain or other core Meta Unit services.
|
||||
|
||||
## The API Contract: The WASM Interface
|
||||
### 2. The App UI (The Frontend)
|
||||
|
||||
The communication between the `Avatar` and the `Meta Unit` follows a clear, bidirectional API contract, similar in spirit to WASI (WebAssembly System Interface).
|
||||
#### The Primary Path: Targeting the "Dao Web Avatar"
|
||||
|
||||
* **`yuan_*` (Exports from Meta Unit)**: The `Meta Unit` exposes a set of functions that the `Avatar` can call. The primary entry point is `yuan_handle_request`, which takes a structured request from the Avatar and processes it.
|
||||
To maximize portability and lower the barrier to entry, the primary way to build a UI for a Dao OS application is by creating a **standard Web Application** (using React, Vue, Svelte, etc.).
|
||||
|
||||
* **`avatar_*` (Imports into Meta Unit)**: The `Meta Unit` declares a set of functions that it needs the `Avatar` host to provide. These functions are its only window to the outside world, allowing it to request actions like logging a message (`avatar_log`) or making a network request (`avatar_net_request`).
|
||||
This web UI runs inside our official, secure **"Dao Web Avatar"** container on all platforms (iOS, Android, Desktop). Communication with your WASM backend is handled via a secure **`dao.js` JavaScript bridge** that we provide. This means a developer can **write one WASM backend and one Web UI frontend** and have their application run everywhere.
|
||||
|
||||
* **Data Serialization**: To pass complex data structures across the WASM memory boundary efficiently and safely, we use **Protocol Buffers (Protobuf)**. Data is serialized into a byte buffer, passed as a pointer and length, and then deserialized on the other side.
|
||||
#### The Advanced Path: Building a Native Avatar Skin
|
||||
|
||||
For developers who require deep platform integration or the absolute peak of native performance, it is still possible to build a fully native UI "skin." This native application would simply act as another host for the `Meta Unit` and would communicate with the same WASM backend service via the API contract. This is considered an optional enhancement, not a requirement.
|
||||
|
||||
## The API Contract: The `dao.js` Bridge
|
||||
|
||||
For web-based UIs, the communication contract is exposed through the `window.dao` JavaScript object injected into the webview. Developers use this bridge to send Protobuf-serialized requests to their application's service module running in the Meta Unit and receive asynchronous responses.
|
||||
|
||||
## Key Technologies & Protocols
|
||||
|
||||
| Category | Technology / Protocol | Purpose |
|
||||
| --------------------- | --------------------------------------------------------- | ------------------------------------------------------------ |
|
||||
| **Core Logic** | Rust / WebAssembly (WASM) | Performance, safety, and ultimate portability. |
|
||||
| **P2P Networking** | `libp2p` | Modular peer discovery (DHT), transport, and secure channels. |
|
||||
| **Data Synchronization** | CRDTs (Conflict-Free Replicated Data Types) | Ensuring eventual consistency across Avatars without a central server. |
|
||||
| **Identity** | DID & VC (Decentralized Identifiers & Verifiable Credentials) | Sovereign identity and interoperable, cryptographic trust. |
|
||||
| **Data Serialization** | Protocol Buffers (Protobuf) | Efficient, language-agnostic data structures for APIs. |
|
||||
| Category | Technology / Protocol | Purpose |
|
||||
| :--- | :--- | :--- |
|
||||
| **Backend Logic** | Rust / WebAssembly (WASM) | Performance, safety, and ultimate portability. |
|
||||
| **Frontend UI** | Web Stack (HTML, CSS, JS/TS) | Primary path for cross-platform UI development. |
|
||||
| **P2P Networking** | `libp2p` | Modular peer discovery, transport, and secure channels. |
|
||||
| **Data Synchronization**| CRDTs (Conflict-Free Replicated Data Types) | Ensuring eventual consistency across Avatars. |
|
||||
| **Identity** | DID & VC | Sovereign identity and interoperable, cryptographic trust. |
|
||||
| **Data Serialization** | Protocol Buffers (Protobuf) | Efficient, language-agnostic data structures for APIs. |
|
||||
|
||||
This modular, open-protocol-based stack is designed for security, portability, and, most importantly, community contribution.
|
||||
This modular, web-centric, and open-protocol-based stack is designed for security, portability, and, most importantly, community contribution.
|
||||
|
||||
Reference in New Issue
Block a user