@Falco É possível expor um check público nas configurações do site/serializer para verificar se o LiveKit está configurado, ao lado de voice_enabled?
Atualmente, voice_enabled é exposto ao cliente, mas não há um sinal público indicando se um site pode fornecer LiveKit. O único atributo do site relacionado ao LiveKit, voice_livekit_per_room_available, é limitado à caixa de seleção do formulário de sala, portanto, retorna false sob a política all_rooms e não pode ser usado para responder à pergunta “este site usa LiveKit de alguma forma?”.
RoomSerializer#expected_transport cobre bem o caso por sala, mas isso requer buscar as salas primeiro, e ele retorna vazio quando voice_public_access está desativado, mesmo em um site onde o LiveKit está totalmente configurado.
Algo assim seria aceitável? Ele é derivado do estado existente, não expõe credenciais nem detalhes de política e não precisa de um novo endpoint.
Ele ficaria em plugins/voice/plugin.rb, após o bloco voice_livekit_per_room_available e logo antes da linha Voice::DefaultRoomSeeder.ensure!:
# Sinal público, sem credenciais, de que o site pode fornecer LiveKit de alguma forma. add_to_serializer(:site, :voice_livekit_available) do Voice::Livekit.configured? && SiteSetting.voice_livekit_room_policy != "disabled" end
voice_enabled não é acessível pela API JSON de forma alguma: /site.json não contém a chave site_settings. Portanto, o único sinal público de que a voz está ativa em um site é a presença de voice_assets_path.
O que estou pedindo são dois booleanos públicos, sem necessidade de credenciais, para que um cliente possa decidir se deve exibir a voz antes de buscar qualquer sala. Ambos são derivados de um estado existente e não exigem nenhum novo endpoint, em plugins/voice/plugin.rb:
Na linha 141, acima de voice_public_access:
#Sinais públicos, sem credenciais, para clientes da API de que a voz está habilitada.
add_to_serializer(:site, :voice_available) { SiteSetting.voice_enabled }
Na linha 152, acima de voice_livekit_per_room_available:
# Se as conexões podem usar o LiveKit. Uma resposta simples de sim/não: sem URL, chave ou
# valor de política. O atributo por sala abaixo apenas controla a caixa de seleção do SFU
# no formulário da sala e lê false sob a política all_rooms.
add_to_serializer(:site, :voice_livekit_available) do
Voice::Livekit.configured? && SiteSetting.voice_livekit_room_policy != "disabled"
end
Isso não expõe nada de novo: expected_transport é um atributo não controlado no RoomSerializer (linha 30, definido na 150) e rooms#index ignora o login (rooms_controller.rb:18), então “livekit” / “mesh” já é legível anonimamente por sala. Isso apenas responde a isso sem uma busca de sala que pode retornar vazia.
Por favor, não mencione membros da equipe em massa desse jeito (eu removi as menções).
Pode ajudar se você descrever qual é o seu objetivo final para essas informações extras. É difícil responder a uma solicitação de funcionalidade sem nenhuma justificativa para o que você pretende fazer com essas informações.
Peço desculpas por ter feito uma pergunta em um anúncio e ter sido redirecionado para o suporte, o que me deixou sem saber com quem falar, já que se trata de uma solicitação de recurso e não de solução de problemas. Após revisar o histórico por cerca de 5 horas, marquei os membros responsáveis pelo commit/merge principal do recurso de voz.
No entanto, para dar mais contexto: tenho um aplicativo que atua como um cliente multiplataforma para comunidades do Discourse, cada uma configurada de forma diferente. Assim, ao iniciar, ele constrói a navegação para o site em que o usuário está. O chat aparece se estiver habilitado, e eu gostaria que a voz aparecesse se estiver habilitada e realmente acessível pelo aplicativo.
O aplicativo se conecta via LiveKit e não suporta mesh, então, em um site que usa mesh, prefiro excluir completamente a voz da navegação, em vez de exibir salas que falharão ao tentar se conectar, dando a impressão de que o aplicativo está com defeito.
Portanto, o fluxo é o seguinte: ler as informações do site uma vez na inicialização, decidir se a voz deve fazer parte do aplicativo para aquele site e, em seguida, usar expected_transport para cada sala quando o usuário a abrir. Os dois valores booleanos são apenas o primeiro passo, e sem eles, ou exibo um recurso que não funciona, ou oculto um que funciona.
Alternativamente, posso exibir a mensagem “Não disponível neste fórum” em um alerta global dentro do aplicativo, independentemente de estar habilitado ou não, mas essa abordagem me pareceu melhor, então identifiquei o ponto de entrada e forneci o código e os comentários.
Obrigado pela explicação! A solicitação faz sentido.
O plugin de voz é novo e está em estado experimental. Provavelmente passará por alterações nas próximas semanas e meses. Especialmente mudanças internas. Estamos abertos a expor essas informações de alguma forma, mas ainda não podemos ter certeza de qual será esse formato. Depende de como a integração com o LiveKit evoluirá.
Acho que você se enganou. Eu estava acordado das 1h às 5h da manhã revisando o que foi feito e os merges, e foi assim que encontrei os membros da equipe que marquei originalmente. Não é que eu esteja esperando uma resposta por 5 horas. O aplicativo já foi enviado para revisão e está utilizando o sistema padrão que eu já tenho.
Isso está bem para mim, leve o tempo que precisar. Fiz meus testes ao longo de 6 meses, levou algum ajuste fino para a escalabilidade.