Вывод статуса 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 в форме комнаты
# и возвращает false при политике all_rooms.

  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

Приношу извинения за то, что задал вопрос в анонсе. Меня перенаправили в поддержку, из-за чего я не понимал, к кому обращаться, поскольку это скорее запрос на новую функцию, а не решение технической проблемы. После пяти часов изучения истории я отметил участников, внесших основные изменения (коммиты/слияния) в код голосового чата.

Тем не менее, чтобы дать немного контекста: у меня есть приложение, которое работает как мультиклиент для сообществ Discourse, каждое из которых настроено по-разному. При запуске оно строит навигацию для того сайта, на котором находится пользователь. Чат появляется, если он включен, и я хотел бы, чтобы голосовой чат появлялся, если он включен и к нему действительно можно подключиться из приложения.

Приложение подключается через LiveKit и не поддерживает mesh-сети, поэтому на сайтах с mesh-сетью я хочу полностью исключить голосовой чат из навигации, а не показывать комнаты, которые не смогут подключиться, создавая впечатление, что приложение сломано.

Таким образом, логика следующая: один раз при запуске прочитать информацию о сайте, решить, должен ли голосовой чат присутствовать в приложении для этого сайта, а затем, когда пользователь откроет комнату, использовать expected_transport для каждой комнаты. Эти два булевых значения — лишь первый шаг, и без них я либо показываю функцию, которая не может работать, либо скрываю ту, которая может.

В качестве альтернативы я мог бы отобразить сообщение «Недоступно на этом форуме» в глобальном уведомлении внутри приложения независимо от того, включена функция или нет, но этот подход показался мне более правильным, поэтому я определил точку входа и предоставил код с комментариями.

5

Спасибо за объяснение! Запрос имеет смысл.

Голосовой плагин новый и находится в экспериментальной стадии. В ближайшие недели и месяцы он, скорее всего, будет изменён. В первую очередь внутренние изменения. Мы открыты к тому, чтобы каким-то образом предоставить эту информацию, но пока не можем точно сказать, в какой форме. Всё зависит от того, как будет развиваться интеграция с LiveKit.

6

Если вам кажется, что 5 часов — это слишком долго ждать, возможно, вы не знакомы с концепцией асинхронной коммуникации на форумах. Добро пожаловать!

Я разберусь с этим и предложим решение, которое мы сможем использовать.

7

Я думаю, ты меня неправильно понял. Я был на связи с 1 до 5 утра, проверяя то, что было сделано, и слияния (merges), именно так я и нашел тех членов команды, которых изначально отметил. Это не значит, что я жду ответа 5 часов. Приложение уже отправлено на проверку, и оно использует систему по умолчанию, которая у меня уже есть.

Мне это подходит, занимайтесь этим столько времени, сколько нужно. Я проводил тестирование в течение 6 месяцев, потребовалась некоторая тонкая настройка для масштабирования.