如何配对 OpenHuman iOS 伴侣应用扫码建立加密通道并在设备上撤销配对【免费下载链接】openhumanOpenHuman is an open source personal AI for Mac, Windows and Linux — local-first memory, agent orchestration, and deep research.项目地址: https://gitcode.com/GitHub_Trending/op/openhuman这篇文章解决一个具体任务把 iPhone 上的 OpenHuman iOS Companion 与桌面上正在运行的 OpenHuman 配对让手机通过端到端加密通道访问桌面核心并在需要时从桌面端撤销这台设备。适用前提来自项目文档iOS 客户端目前标注为Experimental / non-shipping它不是随桌面产品发布的正式部分API、通信格式和配对流程可能随时变化升级后可能强制重新配对另外端到端配对依赖 tinyhumans 后端的tunnel:register/tunnel:connect/tunnel:frameSocket.IO 协议文档明确指出在后端实现该协议并部署之前端到端配对无法工作。先理解整体分工桌面核心始终是数据与逻辑的唯一来源source of truth手机只是一个瘦客户端——它不运行自己的 agent只是把请求转发给核心并渲染结果。配对由核心的 Rustdevices域代理完成后端只转发不透明帧看不到明文。配对前的检查项在扫码之前确认以下文档明确给出的条件否则配对流程走不通桌面上已运行 OpenHuman且 Settings → Devices 面板可用配对入口就在这里。后端已支持 tunnel 协议。架构文档中写明tinyhumansai/backend#709实现tunnel:register/tunnel:connect/tunnel:frame协议在该 PR 合并并部署之前端到端配对不能工作。手机需要能打开openhuman://pair?...深链由 iOS 客户端处理并具备网络可达后端的条件。文档同时说明了配对成功后设备的三种传输策略LAN HTTP同一局域网内直连最快、Tunnel经后端 Socket.IO 中继的 E2E 加密帧跨网络时的默认回退、Cloud HTTPkind: cloud的 profile在 LAN 与 tunnel 都不可达时使用。对已配对设备TransportManager会让 LAN 与 tunnel 竞争2 秒 LAN 超时谁先响应openhuman.ping就用谁。发起配对桌面端生成二维码操作路径在桌面应用的Settings → Devices面板中打开配对弹窗对应实现见 PairPhoneModal。打开弹窗后界面自动执行以下步骤读者无需手工调用 RPC但了解内部调用有助于排错调用openhuman.devices_create_pairing返回会话字段channel_id、pairing_token、core_pubkey、rpc_url可为空、expires_at。用这些字段拼出二维码内容——一个openhuman://pair?cid...pt...cpk...rpc...exp...深链cid通道 idpt一次性配对 token在后端以哈希形式落盘只能使用一次cpk核心侧 X25519 公钥rpc可选的 LAN 直连地址存在时才写入exp过期时间Unix 秒。弹窗开始每 2 秒轮询一次openhuman.devices_list检测该channel_id是否已出现在未撤销设备列表中一旦发现判定握手完成并显示成功随后自动关闭弹窗。二维码有效期很短客户端在exp过后即拒绝该码后端执行的实际 TTL 约 10 分钟界面按分钟数提示剩余时间。如果超时弹窗会切换到过期状态点击Generate new code重新走一遍devices_create_pairing即可——token 是一次性的旧码不能复用。手机侧完成握手用手机 OpenHuman 客户端扫描桌面上的二维码后文档描述的流程是手机解析深链自行生成一个新的 X25519 密钥对设备私钥不落桌面端。手机以role: client携带配对 token 连接后端中继tunnel:connect后端消费该一次性 token 并返回手机侧的sessionToken。双方经tunnel:frame完成 X25519 密钥协商静态 DH 加上每会话的临时密钥对提供前向保密再用 HKDF-SHA256 派生出两个方向独立的 32 字节子密钥info 标签分别为openhuman-tunnel/v1/c2s与openhuman-tunnel/v1/s2c帧加密采用 XChaCha20-Poly1305线格式为version(0x02) || nonce(24) || ciphertexttag并有针对最近 128 个 nonce 的滑动窗口防重放。这些原语来自 src/openhuman/security/devices/crypto.rs。核心侧持久化PairedDevice并发出DevicePaired事件。这些加密细节的意义是机密性与完整性完全保留在两端后端只是盲转发器。静态 DH 借助二维码的出处来认证对端临时 DH 保证即使静态私钥日后泄露也解不开历史流量。验证配对是否成功文档给出的成功判据是明确的配对弹窗轮询到设备出现后弹窗切换为成功状态显示设备标签与channel_id摘要前 8 位…后 6 位3 秒后自动关闭。设备列表已配对设备会出现在桌面Settings → Devices中带在线/离线圆点。在线状态来自实时的tunnel:peer-statuspeer_online标志文档特别指出在线状态从不落盘所以离线不代表设备被撤销。持久化位置核心把设备写入 SQLite{workspace_dir}/devices/devices.db的paired_devices表包含通道 id、标签、设备公钥、核心会话 token 的 SHA-256 哈希和时间戳核心的 X25519 私钥经 OS keyring 的SecretStore加密存储重启后仍可完成握手。一个需要注意的边界旧版单密钥version0x01帧格式会被显式拒绝并提示 re-pair required也就是说核心升级后旧设备需要重新扫码配对而不是自动恢复。出站帧上限 64 KB。在设备上撤销配对撤销同样在桌面Settings → Devices面板中针对目标设备执行内部对应devices_revoke调用。它的行为文档写得很清楚软删除该设备记录拆掉该通道的全部内存态与 tunnel 状态发出DeviceRevoked事件。一个当前局限要在撤销前知道撤销目前只发生在本地一侧——后端通道会靠配对 token 的 TTL 自然过期后端侧的撤销端点被标注为后续工作follow-up。也就是说撤销后手机无法再经 tunnel 接入但通道在后端的彻底消失依赖 TTL 到期而不是立即删除。日常查看可用设备时devices_list只返回未撤销的设备并叠加实时在线标志因此撤销后的设备不会继续出现在列表里。限制与边界整个 iOS 客户端是开发者预览API、线格式、配对流程都可能无公告地变化升级可能强制重新配对。端到端配对依赖后端 tunnel 协议落地未部署前该路径不可用LAN 场景的传输策略选择逻辑仍在客户端内但配对本身走的是中继流程。文档中还标注了一个 TODOiOS 侧对称会话密钥迁移到 Keychain 以支持重启持久化属于尚未完成的项说明手机侧重启后的密钥持久化行为可能不完整。语音输入PTT 听写走设备端 Apple Speech 框架音频不离开设备如果配对的主要目的是用语音可参考 Voice 文档数据与密钥处理可参考 Privacy Security。完成配对后下一步的实际动作就是在 Devices 面板确认设备在线圆点为在线并在手机上发起一次请求验证核心能响应当设备不再受信任时用 Devices 面板的撤销入口移除它并理解后端通道按 TTL 自然过期这一现状。【免费下载链接】openhumanOpenHuman is an open source personal AI for Mac, Windows and Linux — local-first memory, agent orchestration, and deep research.项目地址: https://gitcode.com/GitHub_Trending/op/openhuman创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考