vul-os/kotva

KOTVA 是面向去中心化世界的**窄腰基底**：一个微小且共享的核心—— 包含身份、签名对象、传输、发布/订阅、同步以及基础设施角色—— 许多独立的协议作为轻量级的 **profile** 在其之上进行组合。邮件、商业、工作、 社交、媒体和实时通话都是*同一*窄腰的 profile，而非彼此分离的协议栈。 ## 唯一规则 这是 DMTAP 的传统邮件网关模型——一个可问责的运营商类别，可通过 DNS 更改进行替换，并以自托管作为兜底方案——从邮件推广至整个系统。请参阅 **[DIRECTION.md](DIRECTION.md)** 了解完整原则，并参阅 **[coordinator/CONTRACT.md](coordinator/CONTRACT.md)** 了解每个 coordinator 必须遵守的规则。 ## 布局 | 路径 | 内容说明 | |------|------------| | **`substrate/`** | 窄腰核心：身份、MOTE（签名对象）、传输、PUB（公开对象）、SYNC（多作者 CRDT）、角色与唤醒。 | | **`§00`–`§27`**（根目录） | **DMTAP** —— 邮件 + 消息传递 + 网关 profile，该窄腰的首个也是参考性的 profile。*（将在后续重构中迁移至 `profiles/dmtap-mail/` 下。）* | | **`profiles/tract/`** | **TRACT** —— 商业 profile（报价、购物车、订单、结算、争议）。 | | **`profiles/wrap/`** | **WRAP** —— 工作 profile（任务、派发、交付、里程碑托管）。 | | **`coordinator/`** | coordinator 合约——可问责/可替换/可自托管/可进行 TEE 认证，以及内容可见性属性。 | | **`bindings/`** | KOTVA **采纳**而非重新发明的事物——身份、信誉、支付、存储、争议、媒体传输。请参阅 [bindings/README.md](bindings/README.md)。 | | **`conformance/`** | 一致性套件与测试向量。 | | **`docs/research/`** | 设计背后的研究与依据。 | ## 一句话概述设计 身份即密钥（恢复机制是[采纳](bindings/README.md)的，而非发明的）。一切皆为 **MOTE** —— 一种经过签名、加密且内容寻址的对象。**异步世界**（邮件、聊天、 社交、商业、文件）由 MOTE + PUB + SYNC 组合而成；而**实时世界**（通话、 直播视频）则运行在复用*相同*身份与密钥的并行媒体层面上。金钱使用的是 现有的稳定币，**绝不是新 token**；信任是*质押的现有价值*，绝非凭空铸造。 当一项工作确实需要 coordinator 时——例如撮合、搜索、审核、法律责任—— 该 coordinator 就是一个**可雇佣、可解雇、可自托管的角色**，其形态与 DMTAP 的邮件网关相同，只是经过了推广。 ## Profile 组合原语 每个服务都是同一小套原语的重新排列——这就是为什么“不同的产品” 能够归并为同一个基底的原因： ``` OFFER · MATCH/RESERVE · REPUTATION · ESCROW · ORACLE · DISPUTE · PAY ``` Uber、外卖、预订、拍卖、自由职业和分类信息都是同一套原语， 只是在 MATCH 上应用了不同的**分配规则**（最近 / 最高出价 / 最合适）—— 这是一个引擎，而不是六个。请参阅 [DIRECTION.md](DIRECTION.md)。 ## 状态 `v0.1.0` —— 处于早期并不断演进中。基底、DMTAP 邮件 profile 以及 TRACT/WRAP profile 已制定完毕；**coordinator 合约**和**绑定索引**是目前正在进行的整合 工作。超远期的密码学研究（mixnet、VDF、PQ 信封调优）被隔离在 `research/` 目录中，作为**非规范性**内容，以免在关键路径上耗时使其完美。请参阅 [ROADMAP.md](ROADMAP.md)。 ## 许可证与治理 规范许可证 —— 请参阅 [LICENSE.md](LICENSE.md) 和 [GOVERNANCE.md](GOVERNANCE.md)。版权 由 VulOS (github.com/vul-os) 持有。**目前不存在任何协议 token，未来也不会添加。**