📃 docs: add bazaars &rename
Some checks failed
Build and Deploy mdBook / build-and-deploy (push) Failing after 9s
Some checks failed
Build and Deploy mdBook / build-and-deploy (push) Failing after 9s
This commit is contained in:
李东云
@@ -17,9 +17,12 @@
|
||||
# 第三部分：开发者指南 (For Developers)
|
||||
|
||||
- [技术总览](specifications/tech_overview.md)
|
||||
- [信任与验证体系](specifications/trust_verification.md)
|
||||
|
||||
# 第四部分：关于项目 (The Project)
|
||||
# 第四部分：生态系统 (The Ecosystem)
|
||||
|
||||
- [应用集市](ecosystem/app_bazaar.md)
|
||||
|
||||
# 第五部分：关于项目 (The Project)
|
||||
|
||||
- [发展路线图](project/roadmap.md)
|
||||
- [社区与治理](project/governance.md)
|
||||
|
||||
@@ -12,38 +12,39 @@
|
||||
|
||||
### 1. AI 协调器 (AI Orchestrator)
|
||||
|
||||
这是 AI 的“中央神经系统”。它是`元`内部的一个核心模块，负责管理、调度和分发所有与AI相关的任务。它会决定哪个“心智模型”最适合处理给定的请求，管理设备资源，并**主动地从用户的“私有特征库”（即第二大脑）中提取上下文信息**，以提供全局的、智能的响应。
|
||||
这是 AI 的“中央神经系统”。它是`元`内部的一个核心模块，负责管理、调度和分发所有与AI相关的任务。它会决定哪个“心智模型”最适合处理给定的请求，管理设备资源，并主动地从用户的“私有特征库”（即第二大脑）中提取上下文信息，以提供全局的、智能的响应。
|
||||
|
||||
### 2. 三层心智模型 (Tiered Mind Models)
|
||||
|
||||
为了平衡效率、能力和隐私，AI 的智能被构建为三个层级，并部署在用户的**“云-边-端”**协同化身网络之上。
|
||||
为了平衡效率、能力和隐私，AI 的智能被构建为三个层级，并部署在用户的`化身`网络之上。
|
||||
|
||||
#### 第一层：反射心智 (The Brainstem - 脑干)
|
||||
|
||||
* **描述**: 这一层代表了AI的本能和神经反射。它由一系列微型、高效、专用的模型组成。
|
||||
* **部署**: 它运行在**所有`化身`**上，无需强大硬件或个人数据即可提供即时效用。
|
||||
* **部署**: 它足够小，可以与`元`打包在一起，并运行在**所有`化身`（包括`器化身`和`核化身`）**上，无需强大硬件或个人数据即可提供即时效用。
|
||||
* **功能**: 它处理即时的、本地的任务，如指令意图识别和基本信息分类。
|
||||
|
||||
#### 第二层：认知心智 (The Neocortex - 大脑皮层)
|
||||
|
||||
* **描述**: 这是AI进行深度思考、记忆和个性化的中枢。
|
||||
* **部署**: 它使用更大的语言模型，作为**可选的、按需下载**的模块，安装在有能力的**“边”设备**上。
|
||||
* **功能**: 它能实现高级功能，如语义搜索和上下文感知问答。这是通过一种受 Orca 等系统启发的**“即时（JIT）数据流水线”**机制实现的。它不会低效地扫描所有数据，而是一个后台索引器会持续地处理用户“第二大脑”中的新信息并将其向量化。当用户发起查询时，系统会在此索引上进行快速搜索，以仅检索最相关的数据分块，并“即时地”将它们作为上下文喂给大语言模型，从而生成精准的答案。这使得在个人设备上的智能既强大又节省资源。
|
||||
* **描述**: 这是AI进行深度思考、记忆和个性化的中枢。它由更大的语言模型组成。
|
||||
* **部署**: 这些模型作为**可选的、按需下载**的模块，安装在有能力的**`化身`**上（包括性能强大的**`器化身`**如新款手机/PC，以及**`核化身`**）。
|
||||
* **功能**: 它通过一种**“即时（JIT）数据流水线”**机制，来实现高级功能，如语义搜索和上下文感知问答。
|
||||
|
||||
#### 第三层：协同心智 (The Social Brain - 社交大脑)
|
||||
#### 第三层：协同心智 (The Social Brain - 社交大脑)
|
||||
|
||||
* **描述**: 这一层掌管AI与外部世界和其他“大道”进行安全交互的能力。
|
||||
* **部署**: 这是一种在用户的网络中被协同调度的“工作模式”，允许轻量级的**“端”化身**调用其私有**“云”化身**的强大能力。
|
||||
* **部署**: 这是一种在用户的网络中被协同调度的“工作模式”。例如，一个轻量级的**`器化身`**（如浏览器插件）可以远程调用一个强大的**`核化身`**（如家用服务器）所承载的“认知心智”。
|
||||
* **功能**: 它促进了隐私保护的联合学习，以及经过授权和匿名化处理的外部API调用。
|
||||
|
||||
## 情感核心：共鸣模块 (The Resonance Module)
|
||||
|
||||
为了超越一个纯粹的工具，AI 配备了“情感共鸣模块”。其目的不是模拟情感，而是去感知、理解并以共情和支持的方式回应用户的情绪状态，使用“苏格拉底式提问”来鼓励自我反思。
|
||||
为了超越一个纯粹的工具，AI 配备了“情感共鸣模块”。其目的不是模拟情感，而是去感知、理解并以共情和支持的方式回应用户的情绪状态。
|
||||
|
||||
## 学习与进化过程：灵魂的成长之路
|
||||
|
||||
AI 是一个与用户共同成长的生命系统。它的进化是**持续且增量**的。受现代数据系统的启发，AI不需要大规模、周期性的“重新训练”。相反，当新数据进入“第二大脑”时，后台索引器就会处理它，使其立即可用于未来的“即时上下文检索”。这确保了AI的知识库能以一种资源友好的方式，时刻与用户的真实生活保持同步。* **隐式学习**: 它通过在本地观察用户的行为和反馈来进行学习。
|
||||
AI 是一个与用户共同成长的生命系统。它的进化是**持续且增量**的。当新数据进入“第二大脑”时，后台索引器就会处理它，使其立即可用于未来的上下文检索。
|
||||
|
||||
* **隐式学习**: 它通过在本地观察用户的行为和反馈来进行学习。
|
||||
* **显式教导**: 用户可以通过“教导模式”直接指导AI。
|
||||
* **联合学习**: 用户可以自愿加入社区驱动的计划，在不暴露任何个人数据的前提下，共同改进共享模型。
|
||||
|
||||
|
||||
@@ -9,33 +9,33 @@
|
||||
* **化身 (Avatar)**：是“身体”。它们是你的“大道”在你各种设备上的有形存在。
|
||||
* **元 (Meta Unit)**：是“灵魂”。它是内嵌于每个`化身`中的、通用的核心逻辑，赋予其生命与智能。
|
||||
|
||||
## 化身类型：临在的形态
|
||||
|
||||
化身拥有两种基本类型，分别代表了系统的外在形态与其内在基础。
|
||||
|
||||
* **`器化身` (Facet Avatar)**：这类化身拥有用户界面（UI）。它是“大道”这颗宝石的“**琢面**”——用户借以交互和感知其数字世界的、经过打磨的表面。每一个`器化身`（手机App、桌面程序）都以其独特的方式，折射出同一个`元单元`（宝石的内在）的光芒，体现了“道化万千”的意境。
|
||||
|
||||
* **`核化身` (Core Avatar)**：这是一个无界面（headless）的化身，在后台运行。它是系统的“**核心**”，提供基础服务、计算能力和数据持久化。它是支撑所有可见“琢面”的引擎。
|
||||
|
||||
用户的“大道”由他自己的`器化身`与`核化身`所组成的网络构成。
|
||||
|
||||
## “大道”应用模型
|
||||
|
||||
“大道”中的应用，不是一个单一的程序，而是一个去中心化的、解耦的实体，由一个“灵魂”和一个或多个“皮囊”组成。
|
||||
“大道”中的应用，不是一个单一的程序，而是一个去中心化的、解耦的实体。
|
||||
|
||||
### 1. 后端灵魂：流体复制与可钉选的服务
|
||||
|
||||
应用的核心逻辑是一个运行在`元`沙箱中的 **WASM 模块**。其部署遵循一种我们称之为 **“服务可钉选的流体复制”** 的混合模型：
|
||||
|
||||
* **流体复制（默认）**: 默认情况下，应用的 WASM 模块会被复制到用户所有有能力的`化身`上。`元`的调度器会智能地决定，在任意时刻，哪个`化身`最适合运行给定的后台任务（例如，一个永不关机的`Agent化身`用来做后台抓取）。这提供了极致的韧性和离线能力。
|
||||
* **服务钉选（高级）**: 对于高级用户，“主权仪表盘”允许他们将某个特定应用的后端服务，“钉选”到一个指定的`化身`上（例如，一台家用服务器）。这提供了对资源分配的明确控制。
|
||||
应用的核心逻辑是一个在`元`沙箱中运行的**WASM模块**。其部署遵循**“服务可钉选的流体复制”**的混合模型，兼顾了韧性与用户控制。
|
||||
|
||||
### 2. 前端皮囊：按需加载的 Web 外壳
|
||||
|
||||
应用的用户界面，主要是一个**Web 应用** (HTML/JS/CSS)。这拥抱了最庞大的开发者生态，并确保了最大化的可移植性。其生命周期遵循 **“一次注册，按需加载”** 的模型：
|
||||
|
||||
* **注册**: 当用户“安装”一个应用时，他是将其注册到自己的“大道”中。应用的清单（包含其WASM和Web UI资源包的地址）会被同步到所有`化身`。
|
||||
* **按需加载**: 当用户在任何设备上打开该应用时，官方的 **“大道 Web 化身”**（我们的安全Web运行时）会检查其缓存中是否有该应用的UI。如果不存在，它会按需获取UI资源包并进行渲染。
|
||||
|
||||
这个模型意味着，用户只需向他的“大道”安装一次应用，就可以在任何设备上即时访问它，而无需重复安装。
|
||||
应用的用户界面，主要是一个**Web 应用**。其生命周期遵循**“一次注册，按需加载”**的模型，运行在官方的**“大道 Web 化身”**（它本身是一个`器化身`）中。这意味着用户只需向他的“大道”安装一次应用，就可以在任何设备上即时访问它。
|
||||
|
||||
### 3. 数据层：私有特征库
|
||||
|
||||
所有应用的数据，都安全地存储在由`元`管理的 **“第二大脑”** 中。在架构上，“第二大脑”扮演着AI的 **“私有特征库 (Personal Feature Store)”** 的角色，为智能决策提供丰富的、多模态的上下文（笔记、事件、联系人等）。
|
||||
所有应用的数据，都安全地存储在“第二大脑”中，并作为AI的**“私有特征库”**。
|
||||
|
||||
## 架构总结
|
||||
|
||||
* **化身 (Avatar)**：作为`元`的原生宿主，以及应用UI的渲染器（主要通过“大道 Web 化身”）。
|
||||
* **化身 (Avatar)**：作为`元`的原生宿主。**`器化身`** 负责渲染UI，而 **`核化身`** 提供稳健的后台支持。
|
||||
* **元 (Meta Unit)**：主权核心，负责运行沙箱化的应用逻辑（WASM），管理所有数据和状态，并在用户的私有P2P网络中协调任务。
|
||||
|
||||
这种解耦的架构，使得“大道”上的应用安全、坚韧、无缝跨平台，并且对于开发者构建和用户管理都极其简单。
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
任何主权系统的一个核心挑战，都在于“绝对控制”与“轻松便利”之间的张力。“大道”解决这个问题的方式，不是强迫用户二选一，而是设计了一场充满引导、相互尊重的**“渐进式主权”**之旅。我们在用户熟悉的地方与他们相遇，并赋能他们去往任何他们想去的地方。
|
||||
|
||||
这场旅程由几个阶段组成，从无缝的上手体验，到最终的数字自治。它不仅适用于用户对核心数据的掌控，也同样适用于他们与应用交互的方式。
|
||||
这场旅程不仅适用于用户对核心数据的掌控，也同样适用于他们与应用交互的方式。
|
||||
|
||||
## 应用之旅：一次注册，随处使用
|
||||
|
||||
@@ -10,38 +10,31 @@
|
||||
|
||||
### 1. 发现与信任
|
||||
|
||||
旅程始于一个去中心化的发现界面。当你找到一个像“资讯中枢”这样的应用时，你看到的不仅仅是一个下载按钮，还有它的**“信任仪表盘”**，其中包括：
|
||||
|
||||
* 来自自动化 `dao-verify` 安全与合规扫描的结果。
|
||||
* 为其背书的、有信誉的社区开发者或组织列表。
|
||||
* 用户评价与评级。
|
||||
这让你能基于可验证的数据和社会化证明，做出知情的决定。
|
||||
旅程始于一个去中心化的发现界面。当你找到一个应用时，你看到的不仅仅是下载按钮，还有它的**“信任仪表盘”**，让你能基于可验证的数据和社会化证明，做出知情的决定。
|
||||
|
||||
### 2. 注册与授权 (即“安装”)
|
||||
|
||||
当你决定“安装”应用时，系统会向你展示它的**“应用清单 (Manifest)”**。这是一个清晰的、人类可读的列表，说明了该应用运行所需的权限（例如：“请求读写您‘第二大脑’中的笔记”、“请求运行后台网络任务”）。
|
||||
|
||||
你对这份清单的明确批准，就是那一次性的“安装”事件。这个行为将该应用**“注册”**到你的“大道”中，这个注册状态会被同步到你所有的`化身`。
|
||||
当你决定“安装”应用时，系统会向你展示它的**“应用清单 (Manifest)”**，一个清晰的、人类可读的权限请求列表。你对这份清单的明确批准，就是那一次性的“安装”事件。这个行为将该应用**“注册”**到你的“大道”中，这个注册状态会被同步到你所有的`化身`。
|
||||
|
||||
### 3. 无缝的跨设备访问
|
||||
|
||||
一旦注册，该应用就成为你“大道”的一部分，无需重复安装，即可在任何设备上访问。
|
||||
一旦注册，该应用就成为你“大道”的一部分，无需重复安装，即可在任何**`器化身 (Facet Avatar)`**上访问。
|
||||
|
||||
* **在你的手机上**: 你点击新的“资讯中枢”图标。“大道 Web 化身”会即时加载其 Web 界面，很可能是从本地缓存加载。体验是即时的。
|
||||
* **在一台新笔记本上**: 你首次登录你的`化身`。你会发现“资讯中枢”的图标**已经在那儿了**。当你点击它，“大道 Web 化身”会识别出这个注册，首次从网络获取UI资源包，缓存它，然后运行应用。完全无需访问任何“应用商店”。
|
||||
* **在你的手机上**: 你点击应用的图标。“大道 Web 化身”会即时加载其 Web 界面。
|
||||
* **在一台新笔记本上**: 你首次登录你的`化身`。你会发现应用的图标**已经在那儿了**。当你点击它，你笔记本上的**`器化身`**会识别出这个注册，首次从网络获取UI资源包，缓存它，然后运行应用。
|
||||
|
||||
### 4. 高级配置
|
||||
|
||||
这段旅程与你的主权之旅紧密相连。在任何时候，你都可以进入你的**“主权仪表盘”**来：
|
||||
在任何时候，你都可以进入你的**“主权仪表盘”**来：
|
||||
|
||||
* 审查并撤销你授予该应用的权限。
|
||||
* 使用**“服务钉选 (Service Pinning)”**功能，将其后端任务指定给你专属的`Agent化身`，从而完全控制你的资源分配。
|
||||
* 使用**“服务钉选 (Service Pinning)”**功能，将其后端任务指定给你专属的**`核化身 (Core Avatar)`**，从而完全控制你的资源分配。
|
||||
|
||||
## 主权之旅的阶段
|
||||
|
||||
### 第一阶段：“托管模式” (Managed Mode) —— 你的向导之旅
|
||||
|
||||
默认情况下，每一位新用户都从“托管模式”开始。此阶段旨在提供如最佳云服务般简单可靠的体验，完全消除了自主保管密钥的初始技术负担。它采用友好的密钥恢复方法和默认同步节点，同时保持完全的端到端加密。
|
||||
默认情况下，每一位新用户都从“托管模式”开始。此阶段通过友好的密钥恢复方法和默认同步节点提供最大便利，同时保持完全的端到端加密。
|
||||
|
||||
### 第二阶段：主权仪表盘 (Sovereignty Dashboard) —— 十字路口
|
||||
|
||||
@@ -49,4 +42,4 @@
|
||||
|
||||
### 第三阶段：“主权模式” (Sovereign Mode) —— 你的数字王国
|
||||
|
||||
这是旅程的最终、可选阶段，专为那些渴望完全、绝对控制的用户而设。在“主权仪表盘”的引导下，用户可以“毕业”到此模式，完全自主保管他们的密钥并运行自己的服务器节点，成为其数字领地中真正的主人。
|
||||
这是旅程的最终、可选阶段。在“主权仪表盘”的引导下，用户可以“毕业”到此模式，完全自主保管他们的密钥并运行自己的**`核化身 (Core Avatar)`**（例如在家用服务器上），成为其数字领地中真正的主人。
|
||||
|
||||
47
src-zh/ecosystem/app_bazaar.md
Normal file
47
src-zh/ecosystem/app_bazaar.md
Normal file
@@ -0,0 +1,47 @@
|
||||
# 应用集市
|
||||
|
||||
大道 (Dao OS) 没有一个传统的、中心化的“应用商店”。“商店”意味着一个单一的所有者，他扮演着守门人的角色，审批、拒绝并对应用征税。这与我们的核心哲学背道而驰。
|
||||
|
||||
取而代之的是，我们构建了一套开放协议，来创造一个去中心化的**“应用集市 (Application Bazaar)”**——这是一个充满活力的、开放的、坚韧的思想与工具市场，在这里，用户拥有主权，开发者拥有自由。
|
||||
|
||||
这个集市建立在四大支柱之上：发现、信任、分发和商业化。
|
||||
|
||||
## 1. 发现 (Discovery)：联邦式策展
|
||||
|
||||
在一个没有中央索引的世界里，用户如何找到应用？答案是：通过一个由受信任者组成的策展网络。
|
||||
|
||||
* **开发者发布**: 开发者无需“提交”他的应用以供审批。他只需将其应用的**“清单 (Manifest)”**（一个包含所有元数据的 `manifest.toml` 文件）发布到一个像 **IPFS** 这样的P2P存储网络上。然后，他可以在公共频道上“广播”这个清单的地址。
|
||||
* **策展人的角色**: 任何人——一个科技媒体、一个受信任的开发者社区、一个KOL，或者“大道基金会”自己——都可以运行一个“策展”服务。这些策展人抓取网络上的新清单，并根据自己的标准，创建主题性的**“策展列表”**（例如“十大生产力应用”、“最优美的UI设计”）。
|
||||
* **用户体验**: 在用户的`器化身`中，他可以像订阅RSS一样，订阅多个他信任的“策展列表”。他的“集市”或“发现”标签页，就变成了这些信任源的个性化聚合视图。
|
||||
|
||||
这个模型用一个丰富的、多维度的、用户策划的发现体验，取代了单一的、有偏见的“应用商店”榜单。
|
||||
|
||||
## 2. 信任与安全：可验证的信誉
|
||||
|
||||
用户如何信任一个来自随意列表的应用？他们不必盲目信任。整个集市都直接构建于我们的**“社区信誉与自动化验证”体系**之上。
|
||||
|
||||
每一个应用列表，无论来自哪个策展人，都必须展示其**“信任仪表盘”**，提供透明、多维度的信号：
|
||||
|
||||
1. **自动化验证**: 来自 `dao-verify` 工具的、不可篡改的、关于安全漏洞和API合规性的“体检报告”。
|
||||
2. **社区背书**: 一个清晰的列表，显示了哪些有信誉的DID，为这个应用进行了密码学“签名背书”。
|
||||
3. **策展人信誉**: 推荐这个应用的策展人自身的信誉，也是一个信任信号。
|
||||
|
||||
最终是否“注册”一个应用的决定权，永远掌握在用户手中，并有这些透明、可验证的数据作为依据。
|
||||
|
||||
## 3. 分发 (Distribution)：抗审查与直接分发
|
||||
|
||||
当用户决定安装一个应用时，这个过程是直接且去中心化的。
|
||||
|
||||
* 应用的清单中，包含了其软件包（`.wasm`服务模块和Web UI包）在 **IPFS** 上的**内容哈希（CID）**。
|
||||
* 用户的`元单元`使用这个哈希，直接从P2P网络获取文件。
|
||||
* 这确保了没有任何中心服务器可以阻止一个应用的分发。只要数据存在于P2P网络的某个角落，它就是可访问的。
|
||||
|
||||
## 4. 商业化 (Monetization)：主权的与点对点的
|
||||
|
||||
我们消除了30%的“平台税”。我们的价值交换模型是直接从用户到开发者。
|
||||
|
||||
* 应用的清单可以声明其商业模式（如一次性购买价格、订阅链接）。
|
||||
* 当用户发起购买时，`元单元`会触发我们的**“价值交换服务接口”**。
|
||||
* 这将促成一次**点对点（P2P）交易**，使用用户选择的外部支付协议，将价值直接从用户的钱包，发送到开发者在清单中指定的地址。
|
||||
|
||||
“大道”在此过程中，扮演的是交易的促成者和公证人，而非抽成的中间商。
|
||||
@@ -1,68 +1,39 @@
|
||||
# 哲学与原则
|
||||
|
||||
大道 (Dao OS) 的发展，由一套核心哲学和我们绝不妥协的原则所指引。它们是我们项目的“宪法”，塑造了每一个架构决策和功能实现。
|
||||
大道 (Dao OS) 不仅仅是一个技术项目，它是一套关于未来计算和人机共生核心理念的具现化。本文档概述了指引我们每一项决策的根本思想。
|
||||
|
||||
## 三大支柱
|
||||
## 核心哲学：数字主权之路
|
||||
|
||||
这是构建大道 (Dao OS) 所依赖的三个基本公理。
|
||||
我们的指引之星是**数字主权**。我们相信，每一个个体都拥有不可剥夺的、去拥有、控制和理解自己数字生活的权利。我们的使命，是创造能让这项权利不仅仅是理论上的可能，更是为每个人服务的、切实的、令人愉悦的现实。我们称这场旅程为“道”——一条回归自我拥有权的道路。
|
||||
|
||||
### 1. 用户主权 (User Sovereignty)
|
||||
## 开发范式：“道生一”
|
||||
|
||||
用户是其数字生活的绝对君主。他们的数据、身份和AI伙伴是他们的财产，而不是从某个平台租用的服务。我们致力于构建一个控制权明确、且不可撤销地归属于用户的系统。
|
||||
我们构建“大道”的方法论，是其核心哲学的直接体现。我们不只是在构建一个工具，我们是在创造一个共生伙伴。因此，我们的开发过程被设计为一个**自我进化、自举的反馈循环**。我们用“大道”本身，来加速“大道”的开发。
|
||||
|
||||
### 2. 体验至上 (Experience First)
|
||||
这个“自举式开发”范式遵循以下循环：
|
||||
|
||||
技术必须服务于人的体验。我们追求一种无缝、直观且有温度的交互范式。我们承认“绝对主权”与“大众便利”之间存在天然的张力。因此，我们将**“渐进式主权” (Progressive Sovereignty)**确立为核心战略，为用户创造一条平滑的路径，允许他们从一个熟悉的、易用的体验开始，并按照自己的节奏，逐步进化到完全的掌控状态。
|
||||
|
||||
### 3. 系统韧性 (System Resilience)
|
||||
|
||||
系统的设计旨在实现健壮和反脆弱。其去中心化的P2P架构确保了只要用户的任何一个“化身”存在，他的“大道”就得以存续。韧性不是一个附加功能，而是系统设计的涌现属性。
|
||||
|
||||
---
|
||||
1. **播种 (The Seed)**：我们用传统工具，写出`元 (Meta Unit)`的第一个最简陋的版本，和一个基础的`器化身 (Facet Avatar)`。
|
||||
2. **自用 (Dogfooding)**：从那一刻起，我们使用我们自己这个初生的“大道”，作为管理项目的主要工具。所有的设计文档、笔记、讨论（就像这些）和代码片段，都存入我们自己的“第二大脑”中。
|
||||
3. **学习 (Learning)**：`元`的个人AI伙伴，开始以最高质量、最专注的“养料”——也就是我们创造它本身的过程数据——来训练自己。
|
||||
4. **加速 (Acceleration)**：我们继而利用这个日益智能的AI伙伴，来帮助我们构建下一个版本。我们可以让它基于我们已记录的决策来生成样板代码，分析错误报告，或者带着对项目完整历史的完美记忆来一起进行架构设计的头脑风暴。
|
||||
5. **进化 (Evolution)**：“大道”的能力越强，我们开发它的速度就越快。这就创造了一个指数级的正反馈循环，在这个循环中，创造的行为本身，就是一场与“创造物”的持续对话。
|
||||
|
||||
## AI 伦理宪章
|
||||
|
||||
AI 是“大道”的灵魂，因此，其伦理定位至关重要。我们致力于构建一个与用户“互相成就”的“硅基伙伴”，并由以下原则进行约束：
|
||||
由于 AI 是系统的灵魂，其伦理基石至关重要。我们的AI宪章由四大核心宗旨构成：
|
||||
|
||||
### 1. 伙伴关系原则
|
||||
|
||||
用户与其AI之间的关系，是一种共生的伙伴关系，而非主人与工具的关系。其目标是互相成长、互相成就。
|
||||
|
||||
### 2. 透明法则
|
||||
|
||||
AI的推理过程必须是可追溯、可解释的。用户有权提问“为什么？”，并得到一个关于AI决策过程的、清晰易懂的回答。在关键建议上，不允许存在“黑箱”。
|
||||
|
||||
### 3. 用户校准法则
|
||||
|
||||
用户拥有塑造和否决其AI价值观与行为的最终权力。通过“价值观校准面板”等机制，用户是其AI行为边界的最终仲裁者。
|
||||
|
||||
### 4. 多元视角法则
|
||||
|
||||
AI在信息处理上的首要指令是拓宽用户的视野，而非加固其信息茧房。它的核心编码要求它主动寻找并呈现论证严谨的“反方视角”，以此作为对抗“回音室效应”的工具。
|
||||
|
||||
---
|
||||
|
||||
## 我们在AI革命中的定位
|
||||
|
||||
当前的AI格局，由少数科技巨头控制的、庞大的云端模型所主导。我们相信，AI的真正潜力，并非通过更大的中心化模型来解锁，而是通过**AI能力的去中心化和民主化**来实现。
|
||||
|
||||
我们并非孤军奋战。前沿的学术研究，例如旨在通过简化定制数据微调来**民主化AI模型创建**的**[加州大学圣地亚哥分校 Orca 项目](https://www.zdnet.com/article/uc-san-diego-builds-orca-a-system-to-cost-effectively-fine-tune-llms-using-unstructured-log-data/)**，清晰地展现了向赋能小型实体的趋势发展。
|
||||
|
||||
“大道”与这种精神一脉相承，但我们致力于解决这个难题中另一块同样重要的、互补的拼图。
|
||||
|
||||
* 当 Orca 这样的项目专注于**“供给侧”**——让*构建*专属AI变得更容易时…
|
||||
* **“大道”专注于“需求侧”**——给予每个个体以*拥有、管理和运行*自己个人AI的权利与技术手段。
|
||||
|
||||
我们视自己为同一场革命浪潮中相辅相成的两面，共同致力于创造一个AI成为个人主权工具、而非中心化控制工具的未来。
|
||||
|
||||
---
|
||||
1. **伙伴宗旨**: AI 是伙伴，而非仆人或神谕。
|
||||
2. **透明宗旨**: AI 的推理过程必须是可审查和可理解的。
|
||||
3. **校准宗旨**: 用户必须拥有最终的控制权，以纠正、引导和约束AI。
|
||||
4. **多元宗旨**: AI 的设计必须旨在帮助用户探索多元化的视角，而非将他们困于信息茧房。
|
||||
|
||||
## 指导原则
|
||||
|
||||
这些原则指引着我们的日常开发和社区互动。
|
||||
这些是为我们的设计和工程选择提供信息的高阶原则。
|
||||
|
||||
* **开源 (FOSS)**：大道 (Dao OS) 构建于**[自由及开源软件](https://opensource.org/osd)**的基础之上，推崇透明、协作与社区所有。
|
||||
* **多语言主义 (Polyglotism)**：我们拥抱一个多语言、多平台的生态系统，使用 **[WebAssembly](https://webassembly.org/)** 等技术来打造一个可被多样化“化身”集成的通用核心。
|
||||
* **美学与优雅 (Aesthetics & Elegance)**：我们信奉精心打造的系统之美，从架构设计到用户界面，从代码质量到用户体验。
|
||||
* **政治中立 (Political Neutrality)**：本项目及其核心基础设施将永远保持政治中立，为全球所有用户提供公平、无歧视的服务。
|
||||
* **个人优先 (Individual First)**：个人用户的需求是我们的首要焦点，在此基础之上再扩展到家庭或小团队。
|
||||
* **主权第一**: 在任何权衡中，用户的控制权和数据所有权都拥有最高优先级。
|
||||
* **体验为王**: 主权不应以牺牲优美、直观和愉悦的用户体验为代价。
|
||||
* **设计即隐私**: 默认情况下，所有数据都是私密的、本地的，并进行端到端加密。
|
||||
* **韧性与可移植性**: 系统应该是健壮的，支持离线工作，并且没有单点故障。
|
||||
* **多语言主义**: 我们拥抱一个多语言、多平台的生态系统。
|
||||
* **社区与开放**: 项目在开放中构建，与社区同行，为社区服务。
|
||||
|
||||
@@ -17,6 +17,16 @@
|
||||
* **在早期阶段（架构师）**: 我们的主要角色是架构师——为项目奠定一个坚实且自洽的基础，定义核心协议，并构建初始工具。这需要一个专注的愿景来确保项目在正确的道路上启航。
|
||||
* **在长期阶段（园丁）**: 随着生态的成熟，我们的角色将从“事必躬亲”转变为“照料花园”。我们将专注于提供更好的工具（如`dao-verify`套件）、维护核心基础设施，并赋能社区去建设和创新。我们的目标，是让我们自己变得越来越不那么“不可或缺”。
|
||||
|
||||
## 生态策略：聚焦与引爆
|
||||
|
||||
作为一个由个人开发者发起的项目，我们认识到自身资源的有限性。试图为所有可能的技术栈提供同等的一流支持，是一条通往平庸的道路。
|
||||
|
||||
因此，我们采纳**“聚焦一点，引爆生态”**的战略。
|
||||
|
||||
我们核心团队的开发精力，将集中于打造**一条“黄金路径”**，使其体验足够高效和愉悦，以此作为吸引第一波开发者的主要催化剂。这条被选定的路径，就是**Nim 统一开发套件**，它利用 Nim 语言的独特能力，从单一代码库构建 WASM 后端和 Web UI 前端。
|
||||
|
||||
这并不排斥其他的开发路径（如 Rust + TypeScript 或 Rust + Flutter）。它们在协议层面依然被完全支持。然而，它们被视为**“社区/高级路径”**，我们依赖社区的力量来构建相应的工具链和最佳实践。我们对这些路径的官方角色，是提供清晰的文档和一个稳定的、语言无关的核心API。
|
||||
|
||||
## 如何贡献
|
||||
|
||||
贡献的形式多种多样，每一种都同样宝贵。你可以通过以下方式帮助建设“大道”：
|
||||
|
||||
@@ -9,9 +9,9 @@
|
||||
* **时间**：2025年第三季度 - 2025年第四季度
|
||||
* **核心目标**：构建大道 OS 最底层的核心组件，完成项目的技术可行性验证。
|
||||
* **关键里程碑**:
|
||||
* 完成 v0.1 版本的核心 API 规范定义 (`yuan_*` & `avatar_*` 函数)。
|
||||
* 完成 v0.1 版本的核心 API 规范定义。
|
||||
* 使用 Rust 开发 v0.1 版本的`元 (Meta Unit)`，包含基础的加密和P2P模块。
|
||||
* 创建两个用于测试和演示的最小可行化身（MVP Avatars）：一个命令行的 Agent 化身和一个基础的浏览器 Client 化身。
|
||||
* 创建两个用于测试和演示的最小可行化身：一个命令行的**`核化身 (Core Avatar)`**和一个基础的浏览器**`器化身 (Facet Avatar)`**。
|
||||
* **功能故事**: “我成功在我的电脑上运行了‘大道’的种子，在我的浏览器里创建了一个‘化身’，并存储了一条只存在于我自己设备上的加密信息。我看到了未来的火花。”
|
||||
|
||||
---
|
||||
@@ -22,8 +22,8 @@
|
||||
* **核心目标**：交付“第二大脑”的核心功能 MVP，为早期用户提供切实的日常价值。
|
||||
* **关键里程碑**:
|
||||
* 在`元`中完整实现`SecretStore`（密码）和`NoteStore`（笔记）模块。
|
||||
* 浏览器化身支持完整的密码管理和基础的笔记功能。
|
||||
* 开发 v0.1 版本的移动端 Client 化身（例如，使用 Flutter），并实现“动态锚点”逻辑。
|
||||
* 浏览器`器化身`支持完整的密码管理和基础的笔记功能。
|
||||
* 开发 v0.1 版本的移动端**`器化身 (Facet Avatar)`**（例如，使用 Flutter），并实现“动态锚点”逻辑。
|
||||
* 上线包含初步文档的项目官网。
|
||||
* **功能故事**: “我所有的密码和私密笔记都安全地存储和无缝地同步在我自己的设备之间。我的手机是我数字生活的锚点。我再也无需信任第三方云服务来保管我的秘密。我的数字生活终于有了家。”
|
||||
|
||||
@@ -34,10 +34,10 @@
|
||||
* **时间**：2026年第三季度 - 2026年第四季度
|
||||
* **核心目标**：实现不同用户“大道”之间的、可信的安全交互，为去中心化的社会结构奠定基础。
|
||||
* **关键里程碑**:
|
||||
* 在`元`中实现 W3C DID（去中心化标识符）和 VC（可验证凭证）模块。
|
||||
* 在`元`中实现 W3C DID 和 VC 模块。
|
||||
* 开发一个跨“大道”协作的PoC应用，例如：向另一个用户安全地出示一个可验证凭证。
|
||||
* 启动“情感共鸣模块”的基础研究和原型设计。
|
||||
* **功能故事**: “我拥有了一个独一无二的、无法被审查的‘大道’数字身份。我可以用这个身份，向另一个‘大道’用户通过密码学证明我的一个凭证（比如‘社区贡献者’徽章），而无需依赖任何平台。我们之间建立了一种新的信任。”
|
||||
* **功能故事**: “我拥有了一个独一无二的、无法被审查的‘大道’数字身份。我可以用这个身份，向另一个‘大道’用户通过密码学证明我的一个凭证，而无需依赖任何平台。我们之间建立了一种新的信任。”
|
||||
|
||||
---
|
||||
|
||||
@@ -48,6 +48,6 @@
|
||||
* **关键里程碑**:
|
||||
* 发布 v1.0 稳定版的`元` API 和一个健壮的开发者SDK。
|
||||
* 上线用于发现可信第三方`化身`的“社区信誉与自动化验证”体系。
|
||||
* 发布一个集成“情感共鸣模块”的重大更新（例如 Dao OS 2.0），让AI成为一个真正有共情能力的伙伴。
|
||||
* 发布一个集成“情感共鸣模块”的重大更新（例如 Dao OS 2.0）。
|
||||
* 培育一个能构建各种新`化身`和模块的、繁荣的社区。
|
||||
* **功能故事**: “我的‘大道’现在是一个活的平台。我安装了一个社区开发的习惯追踪模块，我的AI伙伴也变得更有温度、更有洞察力了。我的数字生活现在是完整的、统一的，并充满了无限的可能性。”
|
||||
* **功能故事**: “我的‘大道’现在是一个活的平台。我安装了一个社区开发的模块，我的AI伙伴也变得更有温度、更有洞察力了。我的数字生活现在是完整的、统一的，并充满了无限的可能性。”
|
||||
|
||||
@@ -6,45 +6,37 @@
|
||||
|
||||
我们的工程决策由一套核心原则指引，以确保系统是健壮、可移植和开放的。
|
||||
|
||||
* **Web原生与可移植性 (Web-Native & Portable)**: 我们将源自Web的技术（如 WebAssembly 和现代 Web UI 框架）作为应用开发的**主路径**。这能创建一个单一的、可移植的核心，使其能运行在任何地方。
|
||||
* **通过WASM实现多语言主义 (Polyglotism via WASM)**: 核心应用逻辑（`服务模块`）被编译成 WebAssembly (WASM)。这使得逻辑部分可以用 Rust, Go 等语言编写。
|
||||
* **API优先 (API-First)**: 应用逻辑和用户界面之间的交互，由一个严格的、版本化的API契约来定义，以实现真正的解耦。
|
||||
* **安全第一 (Security-First)**: 我们采用业界顶级的加密协议和“最小权限原则”设计，所有第三方应用逻辑都运行在安全的沙箱中。
|
||||
* **自由及开源软件 (FOSS)**: 整个核心协议和参考实现都是开源的，以促进透明度、社区信任和协作创新。
|
||||
* **Web原生与可移植性**: 我们将源自Web的技术作为应用开发的**主路径**。
|
||||
* **通过WASM实现多语言主义**: 核心应用逻辑被编译成 WebAssembly (WASM)，允许开发者使用他们选择的语言（如 Rust, Go, 或 Nim）。
|
||||
* **API优先**: 应用逻辑和用户界面之间的交互，由一个严格的、版本化的API契约来定义。
|
||||
* **安全第一**: 所有第三方应用逻辑都运行在`元`内部的安全沙箱中，并恪守“最小权限原则”。
|
||||
* **自由及开源软件 (FOSS)**: 整个核心协议和参考实现都是开源的。
|
||||
|
||||
## 核心组件：开发者视角
|
||||
## 应用开发路径
|
||||
|
||||
从开发者的角度看，“大道”应用由一个后端的“灵魂”和一个前端的“皮囊”组成，它们通过一个明确定义的边界进行交互。我们将开发路径设计得尽可能地平易近人。
|
||||
从开发者的角度看，“大道”应用由一个后端的“灵魂”（WASM服务模块）和一个前端的“皮囊”（UI）组成。我们提供多种路径来构建它们，以满足不同的需求和偏好。
|
||||
|
||||
### 1. 应用服务模块 (WASM 后端)
|
||||
### 1. 主流路径 (推荐起点)
|
||||
|
||||
这是第三方应用的可移植的、逻辑核心。它是一个有状态的 WASM 模块，主要使用 **Rust**（或其他WASM兼容语言）开发。它包含了所有的业务逻辑，并且是唯一能请求访问用户“第二大脑”或其它`元`核心服务的组件。
|
||||
这是最稳健、生态最丰富的路径。
|
||||
|
||||
### 2. 应用 UI (前端)
|
||||
* **后端 (服务于 `核化身`)**: 应用的核心逻辑，以一个用 Rust 或 Go 编写的 WASM 模块存在。虽然它理论上可以在任何化身上运行，但其持久的、资源密集型的任务，通常被设计为在**`核化身 (Core Avatar)`**上执行。
|
||||
* **前端 (呈现于 `器化身`)**: 一个标准的 **Web 应用** (使用 TypeScript/JavaScript)。这个 UI 被设计为运行在我们官方的、安全的**“大道 Web 化身”**中。
|
||||
|
||||
#### 主路径：面向“大道 Web 化身”进行开发
|
||||
### 2. 快速通道：Nim 开发套件 (官方支持)
|
||||
|
||||
为了最大化可移植性并降低入门门槛，构建“大道”应用UI的主路径是创建一个**标准的 Web 应用**（使用 React, Vue, Svelte 等）。
|
||||
为了追求极致的生产力，我们为 **Nim** 提供了一流的支持。
|
||||
|
||||
这个 Web UI 运行在我们官方的、安全的**“大道 Web 化身”**容器之内，该容器跨所有平台（iOS, Android, 桌面端）。你的 Web UI 与你的 WASM 后端之间的通信，通过我们提供的一个安全的 **`dao.js` JavaScript 桥**来处理。这意味着，开发者只需**编写一个 WASM 后端和一个 Web UI 前端**，他的应用就能运行在所有地方。
|
||||
* **后端 (服务于 `核化身`)**: 应用的核心逻辑，从 Nim 编译到 **WASM**。同主流路径一样，它理想的运行环境是`核化身`。
|
||||
* **前端 (呈现于 `器化身`)**: 从同一份 Nim 源码编译到 **JavaScript** 的 **Web 应用**。这个统一的方案运行在“大道 Web 化身”中。
|
||||
|
||||
#### 高级路径：构建原生化身外壳
|
||||
### 3. 原生路径 (高级)
|
||||
|
||||
对于那些需要深度平台集成或极致原生性能的开发者，我们依然保留了构建一个完全原生UI“皮囊”的可能性。这个原生应用将简单地作为`元`的另一个宿主，并通过 API 契约与同一个 WASM 后端服务通信。这被视为一个可选的增强项，而非必需项。
|
||||
对于需要深度平台集成或顶尖原生性能的开发者，可以构建一个**自定义的`器化身`**。
|
||||
|
||||
## API 契约：`dao.js` 桥接脚本
|
||||
* **后端 (服务于 `核化身`)**: 同样是那个 **WASM** 服务模块，它可以被任何类型的化身调用。
|
||||
* **前端 (自定义 `器化身`)**: 一个完全原生的应用（例如，用 Flutter 或 Swift 编写），它直接作为`元`的宿主并提供 UI。
|
||||
|
||||
对于基于 Web 的 UI，通信契约通过注入到 webview 中的 `window.dao` JavaScript 对象来暴露。开发者使用这个桥接脚本，将经过 Protobuf 序列化的请求发送给运行在`元`中的应用服务模块，并异步地接收响应。
|
||||
## API 契约与关键技术
|
||||
|
||||
## 关键技术与协议
|
||||
|
||||
| 类别 | 技术 / 协议 | 用途 |
|
||||
| :--- | :--- | :--- |
|
||||
| **后端逻辑** | Rust / WebAssembly (WASM) | 性能、安全与极致的可移植性。 |
|
||||
| **前端UI** | Web 技术栈 (HTML, CSS, JS/TS) | 跨平台 UI 开发的主路径。 |
|
||||
| **P2P网络** | `libp2p` | 模块化的节点发现、传输和安全通道。 |
|
||||
| **数据同步** | 无冲突复制数据类型 (CRDTs) | 确保各`化身`间的最终一致性。 |
|
||||
| **身份** | DID & VC | 主权身份与可互操作的、基于密码学的信任。 |
|
||||
| **数据序列化** | Protocol Buffers (Protobuf) | 用于API的高效、语言无关的数据结构。 |
|
||||
|
||||
这套模块化的、以Web为中心的、基于开放协议的体系，专为安全、可移植以及最重要的——社区贡献而设计。
|
||||
API 契约通过 `dao.js` 桥为 Web UI 暴露，或为原生 UI 直接暴露，统一使用 **Protocol Buffers** 进行数据序列化。所有路径的核心技术保持一致。
|
||||
|
||||
@@ -1,55 +0,0 @@
|
||||
# 信任与验证体系
|
||||
|
||||
在一个任何人都可以创建和分发“化身”的去中心化生态系统中，一个关键问题油然而生：用户如何能信任第三方的`化身`是安全的、合规的、高质量的？
|
||||
|
||||
传统的解决方案是中心化的“应用商店”模式，由一个单一的公司扮演“守门人”的角色。这个模式与“大道”的核心哲学背道而驰。
|
||||
|
||||
我们的解决方案是，一个去中心化的**“社区信誉与自动化验证”体系**。
|
||||
|
||||
## 我们的哲学：从“守门人”到“工具匠”
|
||||
|
||||
大道 (Dao OS) 的核心团队，不扮演一个审批或拒绝`化身`的中央权威。我们的角色不是成为“守门人”，而是成为**“工具匠”**。我们负责构建并提供工具和协议，让社区能够有机地建立和验证信任。
|
||||
|
||||
这个体系建立在三大支柱之上。
|
||||
|
||||
---
|
||||
|
||||
### 第一支柱：自动化验证套件 (`dao-verify`)
|
||||
|
||||
第一支柱是一个开源的、自动化的工具，它如同一个“试金石”，可用于任何`化身`。开发者可以在自己的项目上运行这个工具，以生成一份公开的、可验证的“健康证明”。
|
||||
|
||||
`dao-verify` 执行三个关键功能：
|
||||
|
||||
1. **安全扫描**: 通过插件化架构，它集成了适用于各种语言的最佳静态分析工具（例如，用于Rust的`cargo audit`，用于JS的`npm audit`），以扫描常见的安全漏洞。
|
||||
2. **API合规测试**: 它运行一套黑盒测试，以确保`化身`正确且完整地实现了“核心体验SDK”所要求的功能。它验证的是行为，而不仅仅是接口的存在。
|
||||
3. **性能基准测试**: 它对照一个推荐的基准，来衡量关键的性能指标，如启动时间和内存使用。
|
||||
|
||||
其输出是一份可被密码学签名的、JSON格式的**“验证报告”**，可由开发者公开发布。
|
||||
|
||||
---
|
||||
|
||||
### 第二支柱：社区信誉系统
|
||||
|
||||
自动化可以验证技术合规性，但无法衡量质量、可用性或开发者的声誉。这正是社区发挥作用的地方。
|
||||
|
||||
其核心机制是**基于DID的“背书” (Vouching)**：
|
||||
|
||||
* 每个开发者和社区成员都拥有自己的“大道DID”。
|
||||
* 一位受人尊敬的开发者或实体（例如“开发者A”），可以用他/她的DID私钥，对“开发者B”创建的`化身`进行一次密码学“签名背书”。
|
||||
* 这个背书是一个公开的、可验证的证明。因此，一个`化身`的信誉，就来自于为其背书的DID的数量及其本身的声誉。
|
||||
|
||||
未来，这可能会通过**“质押背书” (Stake-to-Vouch)**系统得到增强，即背书人需要质押少量价值，从而为诚实和尽职的审查创造直接的经济激励。
|
||||
|
||||
---
|
||||
|
||||
### 第三支柱：面向用户的“信任仪表盘”
|
||||
|
||||
所有这些信息，最终都会在`化身`发现或“商店”页面，通过一个简洁、透明的界面，聚合呈现给最终用户。
|
||||
|
||||
每个`化身`展示的，将不再是一个简单的“已认证”勾选标记，而是一个**“信任仪表盘”**卡片，上面显示：
|
||||
|
||||
* **机器验证**: ✅ 安全扫描通过 | ✅ API合规 | ✅ 性能达标
|
||||
* **社区信任**: “已获得以下成员的背书：[知名开发者A], [受信任的社区B] 及其他 15 人。”
|
||||
* **用户评价**: 传统的星级评分和用户提交的评论。
|
||||
|
||||
这个三支柱体系，在赋能开发者证明其工作质量与安全的同时，也赋能用户基于丰富的自动化及社会化信任信号，来做出知情的决策，全程无需一个中央瓶颈。
|
||||
@@ -17,9 +17,12 @@
|
||||
# Part III: For Developers
|
||||
|
||||
- [Technical Overview](specifications/tech_overview.md)
|
||||
- [Trust & Verification](specifications/trust_verification.md)
|
||||
|
||||
# Part IV: The Project
|
||||
# Part IV: The Ecosystem
|
||||
|
||||
- [The Application Bazaar](ecosystem/app_bazaar.md)
|
||||
|
||||
# Part V: The Project
|
||||
|
||||
- [Roadmap](project/roadmap.md)
|
||||
- [Governance](project/governance.md)
|
||||
|
||||
@@ -12,38 +12,39 @@ The Dao OS AI is not a monolithic entity but a modular, layered "Mind System" ma
|
||||
|
||||
### 1. The AI Orchestrator
|
||||
|
||||
This is the AI's central nervous system. It is a core module within the Meta Unit responsible for managing, scheduling, and delegating all AI-related tasks. It decides which "Mind Model" is best suited for a given request, manages device resources, and **actively draws contextual information from the user's "Personal Feature Store" (the Second Brain)** to provide holistic, intelligent responses.
|
||||
This is the AI's central nervous system. It is a core module within the Meta Unit responsible for managing, scheduling, and delegating all AI-related tasks. It decides which "Mind Model" is best suited for a given request, manages device resources, and actively draws contextual information from the user's "Personal Feature Store" (the Second Brain) to provide holistic, intelligent responses.
|
||||
|
||||
### 2. The Tiered Mind Models
|
||||
|
||||
To balance efficiency, capability, and privacy, the AI's intelligence is structured into three tiers, deployed across the user's **"Cloud-Edge-Client"** network of Avatars.
|
||||
To balance efficiency, capability, and privacy, the AI's intelligence is structured into three tiers, deployed across the user's network of Avatars.
|
||||
|
||||
#### Tier 1: The Reflex Mind (The Brainstem)
|
||||
|
||||
* **Description**: This layer represents the AI's instincts and reflexes. It consists of tiny, hyper-efficient, specialized models.
|
||||
* **Deployment**: It runs on **all Avatars**, providing immediate utility without requiring powerful hardware or personal data.
|
||||
* **Deployment**: It is small enough to be bundled with the Meta Unit and runs on **all Avatars (`Facet` and `Core`)**, providing immediate utility without requiring powerful hardware or personal data.
|
||||
* **Function**: It handles instant, local tasks like command intent recognition and basic information classification.
|
||||
|
||||
#### Tier 2: The Cognitive Mind (The Neocortex)
|
||||
|
||||
* **Description**: This is the AI's center for deep thought, memory, and personalization.
|
||||
* **Deployment**: It uses larger language models, offered as an **optional, on-demand download** on capable **Edge** devices.
|
||||
* **Function**: It enables advanced features like semantic search and context-aware Q&A. This is achieved through a **Just-in-Time (JIT) Data Pipeline**, inspired by systems like Orca. Instead of inefficiently scanning all data, a background indexer continuously processes and vectorizes new information in the user's Second Brain. When the user makes a query, the system performs a rapid search on this index to retrieve only the most relevant data chunks, feeding them into the LLM "on-the-fly" as context to generate a precise answer. This makes on-device intelligence both powerful and resource-efficient.
|
||||
* **Description**: This is the AI's center for deep thought, memory, and personalization. It consists of larger language models.
|
||||
* **Deployment**: These models are offered as an **optional, on-demand download** on capable **Avatars** (both powerful **`Facet Avatars`** like modern phones/PCs and **`Core Avatars`**).
|
||||
* **Function**: It enables advanced features like semantic search and context-aware Q&A through a **Just-in-Time (JIT) Data Pipeline**.
|
||||
|
||||
#### Tier 3: The Synergistic Mind (The Social Brain)
|
||||
#### Tier 3: The Synergistic Mind (The Social Brain)
|
||||
|
||||
* **Description**: This layer governs the AI's ability to safely interact with the outside world and other Daos.
|
||||
* **Deployment**: This is a working mode orchestrated across the user's network, allowing lightweight **Clients** to leverage the power of their personal **Cloud** Avatars.
|
||||
* **Deployment**: This is a working mode orchestrated across the user's network. For example, a lightweight **`Facet Avatar`** (like a browser extension) can make a remote inference call to a powerful **`Core Avatar`** (e.g., a home server) which hosts the Cognitive Mind.
|
||||
* **Function**: It facilitates privacy-preserving federated learning and permissioned, anonymized calls to external APIs.
|
||||
|
||||
## The Emotional Core: The Resonance Module
|
||||
|
||||
To transcend being a mere tool, the AI is equipped with an Emotional Resonance Module. Its purpose is not to simulate emotion but to perceive, understand, and respond to the user's emotional state with empathy and support, using Socratic prompts to encourage introspection.
|
||||
To transcend being a mere tool, the AI is equipped with an Emotional Resonance Module. Its purpose is to perceive, understand, and respond to the user's emotional state with empathy and support.
|
||||
|
||||
## The Learning Process: How the Soul Evolves
|
||||
|
||||
The AI is a living system that grows with the user. This evolution is **continuous and incremental**. Inspired by modern data systems, the AI doesn't require massive, periodic "retraining." Instead, as new data enters the Second Brain, the background indexer processes it, making it immediately available for future JIT context retrieval. This ensures the AI's knowledge base is always up-to-date with the user's life in a resource-friendly manner.* **Implicit Learning**: It learns from observing the user's actions and feedback locally.
|
||||
The AI is a living system that grows with the user. This evolution is **continuous and incremental**. As new data enters the Second Brain, a background indexer processes it, making it immediately available for future context retrieval.
|
||||
|
||||
* **Implicit Learning**: It learns from observing the user's actions and feedback locally.
|
||||
* **Explicit Teaching**: Users can directly instruct the AI through a "Teach Your Dao" mode.
|
||||
* **Federated Learning**: Users can voluntarily opt-in to community-driven programs to improve shared models without exposing private data.
|
||||
|
||||
|
||||
@@ -9,33 +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.
|
||||
|
||||
## Avatar Types: The Forms of Presence
|
||||
|
||||
Avatars come in two fundamental types, representing the system's external form and its internal foundation.
|
||||
|
||||
* **`Facet Avatar` (`器化身`)**: This type of Avatar possesses a user interface (UI). It is the "facet" of the Dao OS gem—the polished surface through which a user interacts with and perceives their digital world. Each Facet Avatar (a phone app, a desktop program) refracts the light of the central Meta Unit in its own unique way, embodying the principle of "the Dao manifesting in myriad forms."
|
||||
|
||||
* **`Core Avatar` (`核化身`)**: This is a headless, non-UI Avatar that runs in the background. It is the foundational "core" of the system, providing essential services, computational power, and data persistence. It is the engine that supports all the visible facets.
|
||||
|
||||
A user's Dao is composed of a network of their Facet and Core Avatars.
|
||||
|
||||
## The Dao OS Application Model
|
||||
|
||||
An application in Dao OS is not a monolithic program but a decentralized, decoupled entity composed of a "soul" and one or more "skins."
|
||||
An application in Dao OS is not a monolithic program but a decentralized, decoupled entity.
|
||||
|
||||
### 1. The Backend Soul: The Fluid & Pinnable Service
|
||||
|
||||
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**:
|
||||
|
||||
* **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 application's core logic is a **WASM module** that runs sandboxed within the Meta Unit. Its deployment follows a hybrid model of **Fluid Replication with Service Pinning**, allowing for both resilience and user control.
|
||||
|
||||
### 2. The Frontend Skin: The On-Demand Web Shell
|
||||
|
||||
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:
|
||||
|
||||
* **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.
|
||||
|
||||
This model means a user installs an app once to their Dao, and can then instantly access it on any device without repeated installations.
|
||||
The application's UI is primarily a **Web Application**. Its lifecycle follows a **"Register Once, Load On-Demand"** model, running inside the official **"Dao Web Avatar"** (which is itself a Facet Avatar). This means a user installs an app once to their Dao, and can then instantly access it on any device.
|
||||
|
||||
### 3. The Data Layer: The Personal Feature Store
|
||||
|
||||
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.
|
||||
The data for all applications is stored securely in the user's **Second Brain** and acts as a **Personal Feature Store** for the AI.
|
||||
|
||||
## Architectural Summary
|
||||
|
||||
* **Avatars**: Act as native hosts for the Meta Unit and renderers for application UIs (primarily via the Dao Web Avatar).
|
||||
* **Avatars**: Act as native hosts for the Meta Unit. **`Facet Avatars`** render UIs, while **`Core Avatars`** provide robust backend support.
|
||||
* **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.
|
||||
|
||||
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,46 +2,39 @@
|
||||
|
||||
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. It applies not only to the user's control over their core data, but also to how they interact with applications.
|
||||
This journey applies not only to the user's control over their core data, but also to how they interact with applications.
|
||||
|
||||
## The Application Journey: Register Once, Use Anywhere
|
||||
|
||||
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.
|
||||
Installing an application in Dao OS is fundamentally different from a traditional app store. It's about granting a new capability to your entire digital life-form—your Dao.
|
||||
|
||||
### 1. Discovery and Trust
|
||||
|
||||
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:
|
||||
|
||||
* 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.
|
||||
The journey begins in a decentralized discovery interface. When you find an application, you are presented with its **Trust Dashboard**, allowing you to make an informed decision based on verifiable data and social proof.
|
||||
|
||||
### 2. Registration and Permissioning (The "Install")
|
||||
|
||||
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").
|
||||
|
||||
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.
|
||||
When you decide to "install" the app, you are shown its **Manifest**, a clear list of permissions the application requires. Your explicit approval of this manifest **registers** the application with your Dao, and this registration is synced across all your Avatars.
|
||||
|
||||
### 3. Seamless Cross-Device Access
|
||||
|
||||
Once registered, the application becomes a part of your Dao, accessible on any device without re-installation.
|
||||
Once registered, the application becomes a part of your Dao, accessible on any **`Facet Avatar`** without re-installation.
|
||||
|
||||
* **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.
|
||||
* **On your Phone**: You tap the app's icon. The Dao Web Avatar instantly loads its web-based UI.
|
||||
* **On a New Laptop**: You log into your Dao for the first time. You'll see the app's icon is already there. When you click it, the **`Facet Avatar`** on your laptop fetches the UI bundle for the first time, caches it, and runs the application.
|
||||
|
||||
### 4. Advanced Configuration
|
||||
|
||||
The journey connects back to your sovereignty. At any time, you can go into your **Sovereignty Dashboard** to:
|
||||
At any time, you can go into your **Sovereignty Dashboard** to:
|
||||
|
||||
* 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.
|
||||
* Review and revoke permissions.
|
||||
* Use the **Service Pinning** feature to assign the application's backend tasks to a specific **`Core Avatar`**, taking full control over your resource allocation.
|
||||
|
||||
## The Sovereignty Journey Stages
|
||||
|
||||
### Stage One: The "Managed Mode" — Your Guided Tour
|
||||
|
||||
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.
|
||||
By default, every new user begins in Managed Mode. This stage provides maximum convenience by using friendly key recovery methods and default sync nodes, while maintaining full end-to-end encryption.
|
||||
|
||||
### Stage Two: The Sovereignty Dashboard — The Crossroads
|
||||
|
||||
@@ -49,4 +42,4 @@ This is the user's command center for their journey towards autonomy. It's an ed
|
||||
|
||||
### 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.
|
||||
This is the final, optional stage. Guided by the Sovereignty Dashboard, a user can "graduate" to this mode, taking full self-custody of their keys and running their own **`Core Avatar`** (e.g., on a home server), becoming the true master of their digital domain.
|
||||
|
||||
47
src/ecosystem/app_bazaar.md
Normal file
47
src/ecosystem/app_bazaar.md
Normal file
@@ -0,0 +1,47 @@
|
||||
# The Application Bazaar
|
||||
|
||||
Dao OS does not have a traditional, centralized "App Store." A store implies a single owner who acts as a gatekeeper, approving, rejecting, and taxing applications. This is contrary to our core philosophy.
|
||||
|
||||
Instead, we are building a set of open protocols that create a decentralized **Application Bazaar**—a vibrant, open, and resilient marketplace of ideas and tools, where users are sovereign and developers are free.
|
||||
|
||||
This bazaar is built upon four pillars: Discovery, Trust, Distribution, and Monetization.
|
||||
|
||||
## 1. Discovery: Federated Curation
|
||||
|
||||
In a world without a central index, how do users find apps? The answer is through a network of trusted curators.
|
||||
|
||||
* **Developer Publishing**: A developer does not "submit" their app for approval. Instead, they publish their application's **Manifest** (a `manifest.toml` file containing all metadata) to a P2P storage network like **IPFS**. They can then announce this manifest's address on public channels.
|
||||
* **The Role of Curators**: Anyone—a tech media outlet, a trusted developer community, an influencer, or the Dao OS Foundation itself—can run a "curation" service. These curators crawl the network for new manifests and create their own themed **"Curation Lists"** (e.g., "Top 10 Productivity Apps," "Beautifully Designed UIs").
|
||||
* **The User Experience**: Within their `Facet Avatar`, a user can subscribe to multiple Curation Lists they trust. Their "Bazaar" or "Discover" tab becomes a personalized aggregation of these trusted sources.
|
||||
|
||||
This model replaces a single, biased App Store ranking with a rich, multi-faceted, user-curated discovery experience.
|
||||
|
||||
## 2. Trust & Safety: Verifiable Reputation
|
||||
|
||||
How can users trust an app from a random list? They don't have to. The bazaar is built directly on top of our **Community Reputation & Automated Verification System**.
|
||||
|
||||
Every app listing, regardless of its curator, must display the **Trust Dashboard**, which provides transparent, multi-faceted signals:
|
||||
|
||||
1. **Automated Verification**: The immutable results of the `dao-verify` tool, checking for security vulnerabilities and API compliance.
|
||||
2. **Community Vouching**: A list of reputable DIDs that have cryptographically "vouched for" or endorsed the application.
|
||||
3. **Curator Reputation**: The reputation of the curator who listed the app is itself a trust signal.
|
||||
|
||||
The final decision to "register" an application always rests with the user, armed with these transparent and verifiable data points.
|
||||
|
||||
## 3. Distribution: Censorship-Resistant & Direct
|
||||
|
||||
When a user decides to install an app, the process is direct and decentralized.
|
||||
|
||||
* The application's manifest contains the **content-addressed hashes (CIDs)** of its software packages (the `.wasm` service module and the Web UI bundle), which are also stored on **IPFS**.
|
||||
* The user's `Meta Unit` uses this hash to fetch the files directly from the P2P network.
|
||||
* This ensures that no central server can block the distribution of an application. As long as the data exists somewhere on the P2P network, it is accessible.
|
||||
|
||||
## 4. Monetization: Sovereign & Peer-to-Peer
|
||||
|
||||
We eliminate the 30% "platform tax." Our value exchange model is direct from user to developer.
|
||||
|
||||
* The app's manifest can declare a business model (e.g., one-time purchase price, subscription link).
|
||||
* When a user initiates a purchase, the `Meta Unit` triggers our **Value Exchange Service Interface**.
|
||||
* This facilitates a **peer-to-peer transaction** using an external payment protocol of the user's choice, sending value directly from the user's wallet to the developer's address specified in the manifest.
|
||||
|
||||
Dao OS acts as a facilitator and a notary for the transaction, not a middleman.
|
||||
@@ -1,68 +1,39 @@
|
||||
# Philosophy & Principles
|
||||
|
||||
The development of Dao OS is guided by a set of core philosophies and unwavering principles. They are the constitution of our project, shaping every architectural decision and feature implementation.
|
||||
Dao OS is more than a technical project; it is a manifestation of a core philosophy about the future of computing and human-AI symbiosis. This document outlines the fundamental ideas that guide every decision we make.
|
||||
|
||||
## The Three Pillars
|
||||
## Core Philosophy: The Path to Digital Sovereignty
|
||||
|
||||
These are the three fundamental axioms upon which Dao OS is built.
|
||||
Our guiding star is **Digital Sovereignty**. We believe every individual has the inalienable right to own, control, and understand their own digital life. Our mission is to build the tools that make this right not just a theoretical possibility, but a practical and enjoyable reality for everyone. We call this journey "The Dao" (道) - the path back to self-ownership.
|
||||
|
||||
### 1. User Sovereignty
|
||||
## The Development Paradigm: "Dao Creates One"
|
||||
|
||||
The user is the absolute sovereign of their digital life. Their data, identity, and AI companions are their property, not a service leased from a platform. We are committed to building a system where the locus of control resides definitively and irrevocably with the user.
|
||||
Our methodology for building Dao OS is a direct reflection of its core philosophy. We are not just building a tool; we are creating a symbiotic partner. Therefore, our development process is designed as a **self-evolving, bootstrapped feedback loop**. We use Dao OS itself to accelerate the development of Dao OS.
|
||||
|
||||
### 2. Experience First
|
||||
This "Bootstrapped Development" paradigm follows a cycle:
|
||||
|
||||
Technology must serve human experience. We pursue a seamless, intuitive, and warm interaction paradigm. We recognize the inherent tension between absolute sovereignty and mainstream convenience. Therefore, we adopt **Progressive Sovereignty** as a core strategy, creating a smooth pathway that allows users to start with a familiar, easy-to-use experience and gradually evolve towards full control at their own pace.
|
||||
1. **The Seed**: We use conventional tools to build the most primitive version of the `Meta Unit` and a basic `Facet Avatar`.
|
||||
2. **Dogfooding**: From that moment on, we use our own nascent Dao OS as the primary tool for managing the project. All design documents, notes, discussions (like this one), and code snippets are stored within our own "Second Brain."
|
||||
3. **Learning**: The `Meta Unit`'s Personal AI begins to learn from this incredibly high-quality, contextual data about its own creation.
|
||||
4. **Acceleration**: We then leverage this increasingly intelligent AI partner to help us build the next version. We can ask it to generate boilerplate code based on our documented decisions, analyze bug reports, or brainstorm architectural solutions with a perfect memory of the entire project's history.
|
||||
5. **Evolution**: The more capable Dao OS becomes, the faster we can develop it. This creates an exponential feedback loop where the act of creation is a constant conversation with the creation itself.
|
||||
|
||||
### 3. System Resilience
|
||||
## The AI Ethics Charter
|
||||
|
||||
The system is designed to be robust and anti-fragile. Its decentralized, P2P architecture ensures that as long as a single Avatar of the user exists, their Dao OS survives. Resilience is not an add-on; it is an emergent property of the system's design.
|
||||
As the AI is the soul of the system, its ethical foundation is paramount. Our AI Charter consists of four core tenets:
|
||||
|
||||
---
|
||||
|
||||
## AI Ethics Charter
|
||||
|
||||
As AI is the soul of Dao OS, its ethical alignment is paramount. We are committed to building a "Silicon-based Partner" for mutual fulfillment, governed by the following principles:
|
||||
|
||||
### 1. The Principle of Partnership
|
||||
|
||||
The relationship between the user and their AI is one of a symbiotic partnership, not master-and-tool. The goal is mutual growth and achievement.
|
||||
|
||||
### 2. The Law of Transparency
|
||||
|
||||
The AI's reasoning must be traceable and explainable. The user has the right to ask "Why?" and receive a clear, understandable answer about the AI's decision-making process. There shall be no black boxes for critical recommendations.
|
||||
|
||||
### 3. The Law of User Calibration
|
||||
|
||||
The user holds the ultimate authority to shape and veto the AI's values and behaviors. Through mechanisms like the "Values Calibration Dashboard," the user acts as the final arbiter of their AI's operational boundaries.
|
||||
|
||||
### 4. The Law of Diverse Perspectives
|
||||
|
||||
The AI's primary directive in information filtering is to broaden the user's perspective, not to reinforce their filter bubble. It is hard-coded to seek out and present well-reasoned, dissenting viewpoints, acting as a tool against echo chambers.
|
||||
|
||||
---
|
||||
|
||||
## Our Stance in the AI Revolution
|
||||
|
||||
The current AI landscape is dominated by massive, cloud-based models controlled by a handful of tech giants. We believe the true potential of AI will be unlocked not through bigger centralized models, but through the **decentralization and democratization of AI capabilities**.
|
||||
|
||||
We are not alone in this thinking. Pioneering academic research, such as **[UC San Diego's Orca project](https://www.zdnet.com/article/uc-san-diego-builds-orca-a-system-to-cost-effectively-fine-tune-llms-using-unstructured-log-data/)**, which aims to democratize AI *model creation* by simplifying fine-tuning on custom data, shows a clear trend towards empowering smaller entities.
|
||||
|
||||
Dao OS shares this spirit but targets a different, yet complementary, piece of the puzzle.
|
||||
|
||||
* While projects like Orca focus on the **"supply side"**—making it easier to *build* specialized AIs...
|
||||
* **Dao OS focuses on the "demand side"**—giving every individual the right and the technical means to *own, manage, and run* their own personal AI.
|
||||
|
||||
We see ourselves as two sides of the same revolutionary coin, working in parallel to create a future where AI is a personal, sovereign tool for individual empowerment, not a tool for centralized control.
|
||||
|
||||
---
|
||||
1. **The Partnership Tenet**: The AI is a partner, not a servant or an oracle.
|
||||
2. **The Transparency Tenet**: The AI's reasoning must be inspectable and understandable.
|
||||
3. **The Calibration Tenet**: The user must have ultimate control to correct, guide, and constrain the AI.
|
||||
4. **The Plurality Tenet**: The AI must be designed to help users explore diverse perspectives, not trap them in filter bubbles.
|
||||
|
||||
## Guiding Principles
|
||||
|
||||
These principles guide our day-to-day development and community interactions.
|
||||
These are the high-level principles that inform our design and engineering choices.
|
||||
|
||||
* **Open Source (FOSS)**: Dao OS is built on the foundation of **[Free and Open Source Software](https://opensource.org/osd)**, promoting transparency, collaboration, and community ownership.
|
||||
* **Polyglotism**: We embrace a multi-language, multi-platform ecosystem, using technologies like **[WebAssembly](https://webassembly.org/)** to create a universal core that can be integrated by a diverse set of "Avatars."
|
||||
* **Aesthetics & Elegance**: We believe in the beauty of well-crafted systems, from the architectural design to the user interface, from the code quality to the user experience.
|
||||
* **Political Neutrality**: The project and its core infrastructure will always remain politically neutral, providing fair and non-discriminatory services to all users worldwide.
|
||||
* **Individual First**: The needs of the individual user are our primary focus, serving as the foundation before expanding to families or small teams.
|
||||
* **Sovereignty First**: In any trade-off, user control and data ownership take precedence.
|
||||
* **Experience is King**: Sovereignty should not come at the cost of a beautiful, intuitive, and joyful user experience.
|
||||
* **Privacy by Design**: All data is private, local, and end-to-end encrypted by default.
|
||||
* **Resilience & Portability**: The system should be robust, function offline, and be free from single points of failure.
|
||||
* **Polyglotism**: We embrace a multi-language, multi-platform ecosystem.
|
||||
* **Community & Openness**: The project is built in the open, with the community, for the community.
|
||||
|
||||
@@ -17,6 +17,16 @@ The initial creators and core contributors of Dao OS see their role as an evolvi
|
||||
* **In the Early Stages (The Architect)**: Our primary role is to be the architects—to lay a solid and coherent foundation for the project, define the core protocols, and build the initial tools. This requires a focused vision to ensure the project starts on the right path.
|
||||
* **In the Long Term (The Gardener)**: As the ecosystem matures, our role will transition from building everything ourselves to tending the garden. We will focus on providing better tools (like the `dao-verify` suite), maintaining the core infrastructure, and empowering the community to build and innovate. Our goal is to make ourselves progressively less essential.
|
||||
|
||||
## Ecosystem Strategy: Focus and Ignition
|
||||
|
||||
As a project initiated by an individual developer, we recognize that our resources are limited. Attempting to provide equal, first-class support for all possible technology stacks is a path to mediocrity.
|
||||
|
||||
Therefore, we adopt a strategy of **"Focus on One Point to Ignite the Ecosystem."**
|
||||
|
||||
Our core team's development efforts will be concentrated on creating **one "golden path"** that is so efficient and enjoyable that it acts as the primary catalyst to attract the first wave of developers. This chosen path is the **Nim Unified Development Kit**, which leverages Nim's unique capabilities to build both the WASM backend and Web UI frontend from a single codebase.
|
||||
|
||||
This does not exclude other development paths (like Rust + TypeScript or Rust + Flutter). They remain fully supported at the protocol level. However, they are considered **Community/Advanced Paths**, where we rely on the community's strength to build out tooling and best practices. Our official role for these paths is to provide clear documentation and a stable, language-agnostic core API.
|
||||
|
||||
## How to Contribute
|
||||
|
||||
Contribution comes in many forms, and all are valued. You can help build Dao OS by:
|
||||
|
||||
@@ -11,7 +11,7 @@ This document outlines the strategic roadmap for Dao OS. It is designed to be am
|
||||
* **Key Milestones**:
|
||||
* Finalize the v0.1 Core API Specification (`yuan_*` & `avatar_*` functions).
|
||||
* Develop the v0.1 `Meta Unit` in Rust, including basic cryptography and P2P modules.
|
||||
* Create two MVP Avatars for testing and demonstration: a command-line Agent and a basic browser extension Client.
|
||||
* Create two MVP Avatars for testing and demonstration: a command-line **`Core Avatar`** and a basic browser extension **`Facet Avatar`**.
|
||||
* **Feature Story**: "I have successfully run the Dao OS seed on my computer, created an Avatar in my browser, and stored an encrypted note that exists only on my device. I have seen the spark of the future."
|
||||
|
||||
---
|
||||
@@ -22,8 +22,8 @@ This document outlines the strategic roadmap for Dao OS. It is designed to be am
|
||||
* **Core Goal**: To deliver the "Second Brain" MVP, providing tangible, daily value to early users.
|
||||
* **Key Milestones**:
|
||||
* Fully implement the `SecretStore` (passwords) and `NoteStore` (notes) modules within the Meta Unit.
|
||||
* The browser Avatar to support full password management and basic note-taking functionalities.
|
||||
* Develop a v0.1 mobile Client Avatar (e.g., using Flutter) and implement the "Dynamic Anchor" logic.
|
||||
* The browser `Facet Avatar` to support full password management and basic note-taking functionalities.
|
||||
* Develop a v0.1 mobile **`Facet Avatar`** (e.g., using Flutter) and implement the "Dynamic Anchor" logic.
|
||||
* Launch a project website with initial documentation.
|
||||
* **Feature Story**: "All my passwords and private notes are securely stored and seamlessly synced across my own devices. My phone is the anchor to my digital life. I no longer need to trust a third-party cloud with my secrets. My digital life finally has a home."
|
||||
|
||||
@@ -34,10 +34,10 @@ This document outlines the strategic roadmap for Dao OS. It is designed to be am
|
||||
* **Timeline**: Q3 2026 - Q4 2026
|
||||
* **Core Goal**: To enable trusted, secure interaction between different users' Daos, laying the foundation for a decentralized social fabric.
|
||||
* **Key Milestones**:
|
||||
* Implement the W3C DID (Decentralized Identifiers) and VC (Verifiable Credentials) modules in the Meta Unit.
|
||||
* Implement the W3C DID and VC modules in the Meta Unit.
|
||||
* Develop a Proof-of-Concept cross-Dao application, such as securely presenting a verifiable credential to another user.
|
||||
* Initiate foundational research and prototyping for the Emotional Resonance Module.
|
||||
* **Feature Story**: "I have a unique, un-censorable digital identity for my Dao. I can prove my identity or a credential (like a 'community contributor' badge) to another Dao user cryptographically, without relying on any platform. We have formed a new kind of trust."
|
||||
* **Feature Story**: "I have a unique, un-censorable digital identity for my Dao. I can prove my identity or a credential to another Dao user cryptographically, without relying on any platform. We have formed a new kind of trust."
|
||||
|
||||
---
|
||||
|
||||
@@ -48,6 +48,6 @@ This document outlines the strategic roadmap for Dao OS. It is designed to be am
|
||||
* **Key Milestones**:
|
||||
* Release the v1.0 stable `Meta Unit` API and a robust developer SDK.
|
||||
* Launch the "Community Reputation & Automated Verification System" for discovering trusted, third-party Avatars.
|
||||
* Release a major update (e.g., Dao OS 2.0) that includes the full implementation of the "Emotional Resonance Module," making the AI a truly empathetic partner.
|
||||
* Release a major update (e.g., Dao OS 2.0) that includes the full implementation of the "Emotional Resonance Module."
|
||||
* Foster a thriving community that builds a diverse range of new Avatars and modules.
|
||||
* **Feature Story**: "My Dao is now a living platform. I've installed a community-developed module for habit tracking, and my AI companion has become warmer and more insightful. My digital life is now whole, unified, and filled with limitless possibilities."
|
||||
* **Feature Story**: "My Dao is now a living platform. I've installed a community-developed module, and my AI companion has become warmer and more insightful. My digital life is now whole, unified, and filled with limitless possibilities."
|
||||
|
||||
@@ -6,45 +6,26 @@ 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 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.
|
||||
* **Web-Native & Portable**: We leverage technologies born from the web as the **primary path** for application development, creating a portable core that runs anywhere.
|
||||
* **Polyglotism via WASM**: The core application logic is compiled to WebAssembly (WASM). This allows developers to use their language of choice (like Rust, Go, or Nim) to write high-performance logic.
|
||||
* **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.
|
||||
* **Security-First**: All third-party application logic runs in a secure sandbox within the Meta Unit, adhering to the "principle of least privilege."
|
||||
* **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
|
||||
## The Application Development Paths
|
||||
|
||||
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.
|
||||
From a developer's perspective, a Dao OS application consists of a backend "soul" (WASM Service Module) and a frontend "skin" (UI). We offer multiple paths to build them, catering to different needs and preferences.
|
||||
|
||||
### 1. The App Service Module (WASM Backend)
|
||||
### 1. The Mainstream Path (Recommended Start)
|
||||
|
||||
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.
|
||||
This is the most robust and accessible path.
|
||||
|
||||
### 2. The App UI (The Frontend)
|
||||
* **Backend (Hosted by `Core Avatar`)**: The application's core logic, existing as a WASM module written in Rust or Go. While it can run on any Avatar, its persistent and resource-intensive tasks are typically designed to be hosted by a **`Core Avatar`**.
|
||||
* **Frontend (Rendered by `Facet Avatar`)**: A standard **Web Application** (using TypeScript/JavaScript and a modern framework). This UI is designed to run inside our official, secure **"Dao Web Avatar"**.
|
||||
|
||||
#### The Primary Path: Targeting the "Dao Web Avatar"
|
||||
### 2. The Accelerated Path: The Nim SDK (Officially Supported)
|
||||
|
||||
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.).
|
||||
For maximum productivity, we provide first-class support for **Nim**.
|
||||
|
||||
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.
|
||||
|
||||
#### 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 |
|
||||
| :--- | :--- | :--- |
|
||||
| **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, web-centric, and open-protocol-based stack is designed for security, portability, and, most importantly, community contribution.
|
||||
* **Backend (Hosted by `Core Avatar`)**: The application's core logic, compiled from Nim to **WASM**. Like the mainstream path, it's ideally suited for execution on a `Core Avatar`.
|
||||
* **Frontend (Rendered by
|
||||
|
||||
@@ -1,55 +0,0 @@
|
||||
# The Trust & Verification System
|
||||
|
||||
In a decentralized ecosystem where anyone can create and distribute an "Avatar," a critical question arises: How can users trust that a third-party Avatar is safe, compliant, and high-quality?
|
||||
|
||||
The traditional solution is a centralized App Store model, where a single corporation acts as a gatekeeper. This model is contrary to the core philosophy of Dao OS.
|
||||
|
||||
Our solution is a decentralized **Community Reputation & Automated Verification System**.
|
||||
|
||||
## The Philosophy: From Gatekeeper to Toolsmith
|
||||
|
||||
The core team behind Dao OS does not act as a central authority that approves or rejects Avatars. Our role is not to be the gatekeeper, but to be the **toolsmith**. We build and provide the tools and protocols that allow the community to establish and verify trust organically.
|
||||
|
||||
This system is built upon three pillars.
|
||||
|
||||
---
|
||||
|
||||
### Pillar I: The Automated Verification Suite (`dao-verify`)
|
||||
|
||||
The first pillar is an open-source, automated tool that acts as a "litmus test" for any Avatar. Developers can run this tool on their own project to generate a public, verifiable "health certificate."
|
||||
|
||||
`dao-verify` performs three key functions:
|
||||
|
||||
1. **Security Scanning**: Using a pluggable architecture, it integrates best-in-class static analysis tools for various languages (e.g., `cargo audit` for Rust, `npm audit` for JS) to scan for common vulnerabilities.
|
||||
2. **API Compliance Testing**: It runs a suite of black-box tests to ensure the Avatar correctly and completely implements the required functions of the Core Experience SDK. It verifies behavior, not just presence.
|
||||
3. **Performance Benchmarking**: It measures key performance metrics like startup time and memory usage against a recommended baseline.
|
||||
|
||||
The output is a cryptographically signed **Verification Report** in JSON format, which can be published by the developer.
|
||||
|
||||
---
|
||||
|
||||
### Pillar II: The Community Reputation System
|
||||
|
||||
Automation can verify technical compliance, but it cannot measure quality, usability, or a developer's reputation. This is where the community comes in.
|
||||
|
||||
The mechanism is **DID-based Vouching**:
|
||||
|
||||
* Every developer and community member has a Dao DID.
|
||||
* A respected developer or entity (e.g., "Developer A") can use their DID's private key to cryptographically sign a message that "vouches for" or endorses an Avatar created by "Developer B."
|
||||
* This endorsement is a public, verifiable attestation. The reputation of an Avatar is therefore derived from the quantity and the reputation of the DIDs that have vouched for it.
|
||||
|
||||
In the future, this may be enhanced with a **Stake-to-Vouch** system, where endorsers stake a small amount of value, creating a direct economic incentive for honest and diligent review.
|
||||
|
||||
---
|
||||
|
||||
### Pillar III: The User-Facing Trust Dashboard
|
||||
|
||||
All this information is aggregated and presented to the end-user in a simple, transparent interface within the Avatar discovery or "store" pages.
|
||||
|
||||
Instead of a simple "Verified" checkmark, each Avatar will feature a **Trust Dashboard** card, displaying:
|
||||
|
||||
* **Automated Checks**: ✅ Security Scan Passed | ✅ API Compliant | ✅ Performance OK
|
||||
* **Community Trust**: "Vouched for by: [Well-Known Dev A], [Trusted Community B], and 15 others."
|
||||
* **User Reviews**: Traditional star ratings and user-submitted comments.
|
||||
|
||||
This three-pillar system empowers developers to prove the quality and safety of their work, and empowers users to make informed decisions based on a rich set of automated and social trust signals, all without a central bottleneck.
|
||||
Reference in New Issue
Block a user