@Falco サイト設定/シリアライザー内で、voice_enabled と並んで、LiveKit が設定されているかどうかを公開チェックとして公開することは可能でしょうか？
現在、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
voice_enabled は JSON API からまったくアクセスできません。/site.json には site_settings キーが含まれていないためです。つまり、サイト上でボイス機能が有効かどうかを示す唯一の公開シグナルは、voice_assets_path の存在です。
私が求めているのは、クライアントがルームを取得する前にボイス機能を表示すべきかどうかを判断できるようにするための、公開かつ認証情報不要なブール値2つです。両方とも既存の状態から導出され、新しいエンドポイントは必要ありません。plugins/voice/plugin.rb 内での実装は以下の通りです：
141行目、voice_public_access の上に：
#Public, credential-free signals for API clients that voice is enabled.
add_to_serializer(:site, :voice_available) { SiteSetting.voice_enabled }
152行目、voice_livekit_per_room_available の上に：
# Whether joins can use LiveKit at all. A bare yes/no: no URL, key or
# policy value. The per-room attribute below only gates the room form's
# SFU checkbox, and reads false under the all_rooms policy.
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」はすでに各ルームについて匿名で読み取ることができます。これは、空の結果が返ってくる可能性があるルーム取得なしに、その質問に答えるだけです。
david
2026 年 9 月 2 日午前 8:54
3
チームメンバーをまとめて言及しないでください（言及部分を編集して削除しました）。
この追加情報について、最終的な目標を説明してもらえると助かります。情報をどう利用するのかという根拠がなければ、機能リクエストへの回答は難しいです。
ごめんなさい。アナウンススレッドに質問をしてしまったため、サポート部門に回されました。この件はトラブルシューティングではなく機能要望なので、誰に連絡すればいいか分からなくなっていました。過去5時間分をレビューした結果、ボイス機能のコアコミット/マージに関わったメンバーをタグ付けしました。
背景を補足します。私はDiscourseコミュニティ向けのマルチクライアントとして動作するアプリケーションを開発しています。各コミュニティの設定は異なるため、起動時にユーザーがアクセス中のサイトに応じてナビゲーションを構築します。チャットが有効な場合に表示され、ボイスも有効で、かつアプリから実際に参加可能であれば表示されるようにしたいと考えています。
このアプリはLiveKit経由で接続するだけでメッシュ接続に対応していないため、メッシュ環境のサイトでは、接続に失敗するルームを表示してアプリが壊れているように見せるのではなく、ナビゲーションからボイスを完全に除外したいです。
つまり、フローは次のようになります。起動時にサイト情報を一度読み取り、そのサイトに対してアプリにボイスを含めるべきか判断し、ユーザーがルームを開いた時点でルームごとに expected_transport を使用します。2つのブール値は最初のステップに過ぎませんが、これがないと、機能しない機能を表示するか、機能する機能を隠すかのどちらかになります。
あるいは、有効化の有無に関わらず、アプリケーション内のグローバルアラートに「このフォーラムでは利用できません」と表示することも可能ですが、これはより良いアプローチだと考え、エントリポイントを特定し、コードとコメントを提示しました。
pmusaraj
2026 年 9 月 2 日午後 12:30
5
説明ありがとうございます！そのご要望は理にかなっています。
ボイスプラグインは新機能であり、実験的な段階にあります。今後数週間から数ヶ月の間に、特に内部実装において変更が入る可能性が高いです。この情報を何らかの形で公開することには前向きですが、その形式についてはまだ確定していません。LiveKit統合の進化の状況によって決まります。
Falco
2026 年 9 月 2 日午後 12:38
6
5時間待つのは長すぎると思うなら、フォーラムにおける非同期コミュニケーションの概念にまだ慣れていないのかもしれません。ようこそ！
この件を調査し、活用できるソリューションを考案します。
誤解されていると思います。私は午前1時から5時まで起きていて、実施された内容とマージを確認していました。それが元々タグ付けしていたチームメンバーを見つけた理由です。返信を5時間待っているわけではありません。アプリはすでにレビュー用に提出済みで、既存のデフォルトシステムを利用しています。
私としてはそれで構いません。必要なだけ時間を使ってください。私は6ヶ月にわたってテストを行っており、スケーリングにはいくつかの微調整が必要でした。