0.1.2版协议：用数学替代服务器的新路由方案

一套新协议试图解决一个老问题：没有中心服务器，设备怎么找到彼此？

Namespace Resolution Protocol（命名空间解析协议，简称NRP）v0.1.2版本文档公开了技术细节。它不依赖DNS，不依赖区块链，甚至不需要设备时刻在线。核心思路是把"找服务器"变成"算地址"——用密钥派生替代网络查询。

两层架构：先找命名空间，再找设备

协议把地址解析拆成两个独立阶段。

第一阶段是拓扑层（Topological resolution）：请求方如何在分布式网络中定位到持有目标命名空间的设备。第二阶段是语义层（Semantic resolution）：设备本地解析具体路径，比如wallet.balance。

文档给出的示例地址结构很清晰：

me://jabellae.cleaker.me[surface:iphone]/wallet.balance

三段式分解：先定位命名空间jabellae.cleaker.me，再定位该命名空间下的具体设备surface:iphone，最后在设备本地解析路径/wallet.balance。前两个阶段走NRP协议，最后一个阶段走this.me的本地语义解析。

关键设计：命名空间≠设备

文档反复强调一个区分：命名空间（Namespace）和设备（Surface）是两种东西。

命名空间是语义域，由人类可读的标签标识，比如jabellae.cleaker.me。谁持有该命名空间的根密钥，谁就拥有它。没有中心机构能授予或吊销。

设备是运行环境——iPhone应用、Mac后台进程、浏览器标签页。同一个命名空间可以在多台设备上运行，这些设备共享同一个语义域，但各自提供计算资源。

设备身份通过密钥派生产生：surface_id = hash(namespace_key, surface_name)。注意这里用的是namespace_key（命名空间根密钥）和surface_name（设备名称）的哈希，而非直接传输设备名。只有持有根密钥的人才能派生或验证设备身份。

设备索引：加密存储的动态路由表

设备如何被找到？协议设计了"设备索引"（Surface index）机制。

这是一个加密存储空间，作用是把设备身份（surface_id）映射到当前的网络地址（IP:端口、中继地址、洋葱地址等）。关键点：网络地址不是设备身份，只是"此刻怎么连上它"的临时信息。

索引本身也是加密的，作用域限定在命名空间密钥下。这意味着即使索引数据被同步到公共网络，没有密钥的人也无法读取内容——既看不到有哪些设备，也看不到它们的网络位置。

离线优先的底气从哪来

文档提到this.me已经实现的语义层特性：本地、数学化、基于派生的解析。比如me.get("wallet.balance")可以完全离线执行，不需要查询任何服务器。

NRP补充的是拓扑层能力。两者组合后，完整的地址解析流程可以是：先通过数学派生确定目标设备和它的网络位置（或发现它当前离线），再本地执行语义查询。

这种架构的隐含假设是：命名空间的所有权证明和设备发现，都可以归结为密钥派生和加密索引查询，不需要实时连接中心化的注册表或服务器集群。

一个待观察的协议实验

v0.1.2版本采用CC0协议完全公开，没有商业限制。技术文档的完整度高于一般早期实验项目——分层架构、身份派生公式、索引机制都有明确定义。

对开发者而言，这套协议的价值在于提供了一种"无服务器发现"的替代方案。传统做法是维护一个高可用的注册中心（DNS、服务网格控制平面、区块链命名系统），NRP尝试把发现逻辑下沉到密码学层面。

实际可行性取决于几个未在文档中展开的点：设备索引的同步机制、离线设备的异步消息处理、网络分区时的行为。但这些属于实现细节，协议层只规定了接口和分层边界。

如果你正在设计去中心化应用的基础设施，这份文档值得放进参考清单。它提供了一种思路：把"找东西"的问题转化为"算东西"的问题，用本地计算替代网络往返。