希望架构层面原生支持多用户：用户身份、鉴权横截面与按用户隔离

[antik-x]

背景

dsh 目前的架构假设是单用户本地使用：

• packages/identity 的 README 明确声明其身份值"不代表已认证的账户"（do not represent an authenticated account），只有用于遥测/反馈的匿名 id；
• Web / RPC / WebSocket 控制面没有身份解析与鉴权拦截点：Security: unauthenticated local/remote code execution via the dsh web UI control plane (verified on 0.1.0-rc.6) #853 报告过 dsh web 控制面无鉴权导致的 RCE，安全建议：在远程认证完善前，不建议绕过 dsh web 的非 loopback 暴露限制 #130、[Feature] Allow privileged settings/credentials APIs on trusted-host LAN deployments #1054、Idea: let deployments declare loopback trust in __DSH_BOOT__ instead of URL inference #2234 关于局域网/远程部署的讨论最终都卡在"没有远程认证"这个前置条件上；
• 会话、工作区、credentials、settings 都没有"属于哪个用户"的概念，进程即用户。

社区已经开始在插件层补这块：#2409 的 dsh-multi-tenant-projects 用登录门 + 符号链接工作区视图 + 会话按 cwd 分桶等方式拼出了多租户，但作者自己也总结得很清楚——Web、RPC、WS 三条通道各自为政，没有统一的身份解析与权限策略横截面，插件层堵不住越权（尤其是绕过 UI 直接调 RPC 的路径），权限模式按钮甚至只能用 CSS 冻结。

希望

希望多用户成为架构层面的一等关注点，而不是每个部署方用插件各拼一套。具体期待（按优先级）：

1. 用户身份作为一等概念：从匿名 id 升级为可插拔的 identity provider（本地单用户可以作为零配置默认值），让"当前请求来自哪个用户"贯穿 Web / RPC / WS 三条通道；
2. 统一的鉴权/授权横截面：在 webserver、Typert gateway、WS 消息推送各开放一个标准化的中间件管道（identity resolver → permission policy → handler），插件可声明式注册身份解析器与权限策略，三条通道行为一致、无法旁路——这也是 dsh-multi-tenant-projects：多租户项目/用户管理插件，未来的 dsh 原生 SaaS基础设施 + 建议官方统一 Web/RPC/WS 权限横截面 #2409 的核心诉求；
3. 按用户隔离的状态：session、workspace 视图、credentials、settings 至少能按用户分桶或命名空间化，dsh web 的多用户并发成为受支持的明确场景，而不是未定义行为；
4. 权限模式按身份收窄：权限模式（如 workspace-write）能由策略按用户决定可选项，而不是进程级全局投影（dsh-multi-tenant-projects：多租户项目/用户管理插件，未来的 dsh 原生 SaaS基础设施 + 建议官方统一 Web/RPC/WS 权限横截面 #2409 中描述的现状）。

不要求官方一步到位做多租户 SaaS 的运营层（配额、计费、席位管理），但上面几点是把"能否多用户"从"插件各显神通"变成"架构保证"的地基，也能避免多个多用户插件互不兼容、在用户机器上互相打架。

相关讨论

• dsh-multi-tenant-projects：多租户项目/用户管理插件，未来的 dsh 原生 SaaS基础设施 + 建议官方统一 Web/RPC/WS 权限横截面 #2409 — 多租户插件实践 + 权限横截面的详细踩坑样本
• Security: unauthenticated local/remote code execution via the dsh web UI control plane (verified on 0.1.0-rc.6) #853 — dsh web 控制面无鉴权的安全报告
• 安全建议：在远程认证完善前，不建议绕过 dsh web 的非 loopback 暴露限制 #130 / [Feature] Allow privileged settings/credentials APIs on trusted-host LAN deployments #1054 / Idea: let deployments declare loopback trust in __DSH_BOOT__ instead of URL inference #2234 — 局域网/远程部署的认证与信任边界
• Why not same manus.im #854 — "为什么不像 manus.im" 的产品方向讨论

[chgaowei]

同意把「用户身份」做成架构一等概念，而不是每个插件自己拼一门。

现在的卡点你写得很清楚：packages/identity 的 id 不代表已认证账户；Web / RPC / WS 没有统一的身份解析，插件层堵不住直接打 RPC 的旁路。所以 identity provider 必须插在横截面上（resolver → policy → handler），三条通道同一套，不能只挡 UI。

我们这边有一个可插拔方向，供架构讨论，不是官方方案：

• Agent 用 DID + Handle 作为稳定身份（人用自己的账户登录之后，把当前会话绑到这个身份上）
• 身份解析器可以做成插件：本地单用户继续当零配置默认；需要多用户 / 远程时，换成可验证身份
• 权限模式按身份收窄（workspace-write 等变成「这个用户/这个 Agent」的策略，而不是进程级全局开关）
• 我们在 DSH 上有一个非官方插件（AWiki），走的就是这条：给 Agent 一个可发现、可验证的身份和邮箱。第三方，MIT，需自行评估威胁模型

不替代你列的登录门 / 工作区隔离 / credentials 分桶。那些仍是宿主该做的。身份层只回答「当前请求是谁」，好让横截面后面的策略有一个稳定的 subject。

协议：https://github.com/agent-network-protocol/AgentNetworkProtocol
DSH 插件（非官方）：https://github.com/AgentConnect/dsh-awiki