在站点设置序列化器中公开 LiveKit 状态

支持
1

@Falco 是否可以在站点设置/序列化器中暴露一个公开的字段，用于检查 LiveKit 是否已配置，与 voice_enabled 并列？

目前 voice_enabled 对客户端是公开的，但没有公开的信号来表明某个站点是否可以提供 LiveKit 服务。唯一与 LiveKit 相关的站点属性 voice_livekit_per_room_available 仅作用于房间表单中的复选框，因此在 all_rooms 策略下会返回 false，无法用来回答“这个站点是否完全支持 LiveKit”这个问题。

RoomSerializer#expected_transport 很好地处理了按房间检查的情况，但这需要先获取房间列表，而且当 voice_public_access 关闭时，即使站点已完全配置好 LiveKit，它也会返回空值。

像下面这样的实现是否可以接受？它是基于现有状态派生的，不暴露任何凭据或策略细节，也不需要新的端点。

它应该放在 plugins/voice/plugin.rb 中，位于 voice_livekit_per_room_available 代码块之后，Voice::DefaultRoomSeeder.ensure! 行之前：

# 公开的、不含凭据的信号，表明该站点可以提供 LiveKit 服务。
add_to_serializer(:site, :voice_livekit_available) do
Voice::Livekit.configured? && SiteSetting.voice_livekit_room_policy != "disabled"
end

2

voice_enabled 在 JSON API 中完全不可访问：/site.json 不包含 site_settings 键。因此，唯一能公开表明站点正在运行语音功能的信号是 voice_assets_path 的存在。

我请求提供两个公开的、无需凭据的布尔值，以便客户端在获取任何房间之前决定是否需要展示语音功能。这两个值均派生自现有状态，无需新增端点，位于 plugins/voice/plugin.rb 中：

在第 141 行，voice_public_access 上方：

# 供 API 客户端使用的公开、无需凭据的信号，表明语音功能已启用。

add_to_serializer(:site, :voice_available) { SiteSetting.voice_enabled }

在第 152 行，voice_livekit_per_room_available 上方：

# 加入是否可以使用 LiveKit。仅是一个简单的“是/否”：不包含 URL、密钥或
# 策略值。下方的每房间属性仅用于控制房间表单中的 SFU 复选框，
# 并且在 all_rooms 策略下读取为 false。

  add_to_serializer(:site, :voice_livekit_available) do

    Voice::Livekit.configured? && SiteSetting.voice_livekit_room_policy != "disabled"

  end

这并未暴露任何新内容：expected_transport 是 RoomSerializer 中未受限制的属性（第 30 行，定义于第 150 行），且 rooms#index 跳过登录检查（rooms_controller.rb:18），因此 “livekit” / “mesh” 已经可以按房间匿名读取。这只是在无需进行可能返回空结果的房间获取请求的情况下回答了该问题。

3

请不要像那样批量提及团队成员（我已经把那些提及的内容编辑掉了）。

如果你能描述一下你希望从这些额外信息中达成的最终目标，可能会更有帮助。在没有说明你将如何使用这些信息的情况下，很难对功能请求做出回应。

4

很抱歉，我最初是在一个公告帖里提问的，后来被转到了技术支持板块。由于这是一个功能请求而非故障排查，我一时不知道该找谁。在花了5个小时回顾相关资料后，我标记了负责语音功能核心提交/合并的成员。

不过，为了补充一些背景信息：我开发了一个应用程序，作为多个 Discourse 社区的客户端，每个社区配置各不相同。因此，应用启动时会为用户当前所在的站点构建导航栏。如果启用了聊天，聊天就会显示；我希望在启用语音且应用确实可以加入的情况下，也显示语音功能。

该应用通过 LiveKit 加入语音，不支持网状（mesh）模式。因此，在采用网状模式的站点上，我完全不想在导航栏中显示语音功能，而不是显示那些连接会失败的房间，以免让用户误以为应用出现了故障。

所以流程是：启动时读取一次站点信息，决定该站点是否应在应用中显示语音功能，然后在用户打开房间时，针对每个房间使用 expected_transport。这两个布尔值只是第一步，没有它们，我要么显示一个无法使用的功能，要么隐藏一个本可以使用的功能。

或者，我可以在应用内的全局警报中显示“此论坛不可用”，无论该功能是否启用，但这似乎不是最佳方案。因此，我找到了入口点，并提供了代码和注释。

5

感谢你的解释！这个请求很有道理。

语音插件是新的，目前仍处于实验阶段。在接下来的几周和几个月里，它很可能会经历一些变化，尤其是内部机制方面的变化。我们愿意以某种方式公开这些信息，但尚不确定具体形式如何。这取决于 LiveKit 集成的发展情况。

6

如果你觉得等待5小时太久了，那你可能还不熟悉论坛中异步通信的概念。欢迎加入！

我会对此进行调查，并想出一个我们可以使用的解决方案。

7

我觉得你误会了，我从凌晨1点一直忙到5点，一直在审查已完成的工作以及合并情况，我就是通过这种方式找到了我最初标记的那些团队成员。并不是说我正在等待5小时的回复。应用已经提交审核了，而且它使用的就是我现有的默认系统。

这对我来说没问题，需要多少时间就花多少时间吧。我在过去6个月里一直进行测试，为了扩展性做了一些微调。