DM 默认 pairing
陌生人先拿临时码排队，批准后才能私聊触发。
Channels 导读
Nextcloud Talk 接入：先装插件，再配 bot，最后管好私信权限
当前发行版已内置插件，旧版或自定义安装需手动装。关键步骤是创建 bot 并设置 webhook，注意 bot 不能主动发私信，且 webhook 必须能被网关访问。私信默认需要配对审批，可改为开放模式，但 allowFrom 只认用户 ID 不认显示名。
先讲这一页到底在解决什么
Nextcloud Talk 接入：先装插件，再配 bot，最后管好私信权限
当前发行版已内置插件，旧版或自定义安装需手动装。关键步骤是创建 bot 并设置 webhook，注意 bot 不能主动发私信，且 webhook 必须能被网关访问。私信默认需要配对审批，可改为开放模式，但 allowFrom 只认用户 ID 不认显示名。
第一站
🤖 首先不是 OpenClaw 自己造 bot，而是让 Nextcloud 先发给你一只官方 bot
这就是那条 occ talk:bot:install 命令的含义。
./occ talk:bot:install \"OpenClaw\" \"<shared-secret>\" \"<webhook-url>\"像在 Nextcloud 服务器后台正式注册一只名叫 OpenClaw 的 bot，并告诉它以后把消息送去哪扇门。
shared-secret像 bot 和 OpenClaw 之间约定的暗号，少了它别人也能伪装 bot 来投递。
Room settings 里启用
像房间管理员还得点头说“这只 bot 可以进这间房”。
🎈 一句话
Nextcloud Talk 这条路，是“先在云盘楼里养 bot，再把它接到 OpenClaw”。
第二站
🚪 DM 和 rooms 也是两种门，不要混
这条路默认也很保守。
rooms 默认 allowlist
房间默认不是谁都能让它开口，得在白名单里。
mention gating 仍然在
就算房间被允许，通常也还是更像被点名才答。
媒体是 URL-only
像它不会帮你直接搬大文件包裹，只会把文件地址递过去。
第三站
🔍 “DM 和 room 在 payload 里分不清”那句提醒，意思是：如果你想更准确认房间类型，就得再给它一副 API 眼镜
这就是 apiUser 和 apiPassword 的作用。
😵 默认 payload 不够细
有些 webhook 包裹本身不会直接告诉你“这是 DM 还是房间”。
apiUser + apiPassword像给 OpenClaw 一副额外眼镜，它可以再去服务器里查清这间房到底是什么类型。
webhookPublicUrl如果前面还有代理，这就像明确告诉 bot：“别看内部门牌，看外面公众能到达的那张门牌。”
🎈 收尾一句
Nextcloud Talk 这页最像“公司内网 bot 接入”，不是大众聊天 app 的傻瓜式绑定。