@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ヶ月にわたってテストを行っており、スケーリングにはいくつかの微調整が必要でした。
Falco
2026 年 9 月 3 日午後 2:43
8
実際には、あなたがまさにその通りだったのです。公式 API はまさにこのように呼び出しを行い、パースしています。
curl https://meta.discourse.org/voice/rooms.json -s | jq '.rooms[] | {name: .name, transport: .expected_transport}'
これにより、ピアルームのトランスポートが取得できます。
voice_public_access という設定は存在しません。何を言っているのですか？
もちろん、rooms.json への API 呼び出しには認証を使用し、現在のユーザーがアクセスできるルームのみを取得できるようにする必要があります。
plugin.rb の 144 行目を確認していました。ここではサイトシリアライザーに追加されており、lib/voice/guardian_extension.rb の 16 行目の Guardian#voice_public_access? がバックエンドとして機能しています。設定ではないものを設定だと思い込んでいたため、私のミスです。
rooms.json への指摘、ありがとうございます。expected_transport を伴う認証済み呼び出しが、私が欠落していた部分でした。
私が知りたいのは、サイトペイロードにおいて、そのサイトが LiveKit を提供できるかどうかです。ルームのトランスポートからそれがわかります。available_for? は per_room の下で room.livekit_enabled を返します（lib/voice/livekit.rb の 26 行目）、そして expected_transport はピンを最初に返します（room_serializer.rb の 150 行目）。メッシュフォールバック後も同様です（rooms_controller.rb の 169 行目）。
@Falco ローカルインスタンスでさらにテストしてみます。
別件ですが、voice_allowed_groups はクライアントに対してどこかで公開されていますか？ また、expected_transport は、リスト内でルームごとに LiveKit とメッシュを区別するために意図された方法ですか？ メッシュルームを非表示にして、利用可能な場合は LiveKit のルームのみを表示したいのですが、それらを区別する方法が見当たりません。
Falco
2026 年 9 月 3 日午後 4:15
11
いいえ。それを公開すると、情報漏洩の境界線上にある行為になります。現在のユーザーは、自分自身の権限についてのみ知る必要があります。
はい、100%です。
expected_transport を使用してください。