Etherpad-lite: Solicitação de recurso: canal de áudio

(Observe que não sou um desenvolvedor Etherpad - apenas um terceiro interessado)

Pessoalmente, acho que integrar o bate-papo com áudio no núcleo do Etherpad é uma má ideia.

Embora esteja ciente de que o Etherpad é multiplataforma, acredito piamente na filosofia Unix de "fazer uma coisa e fazê-la bem" .

Em minha opinião, o suporte para bate-papo com áudio não é uma funcionalidade central (ou seja, recurso creep) para Etherpad e, portanto, não deve fazer parte do software central.

Dito isso, posso certamente ver como algum tipo de integração de bate-papo com áudio pode ser bom para alguns usuários. IMO, um plugin para oferecer suporte à integração com uma (ou mais) das inúmeras plataformas de chat de áudio existentes seria a melhor maneira de abordar isso.

Só meu 2c ...

Há um trabalho em andamento para integrar o Etherpad com o BigBlueButton, que é um sistema de webconferência de código aberto, para fornecer não apenas um canal de áudio, mas também canais de vídeo, enquetes, gravações, entre outros recursos de colaboração. Veja: https://github.com/bigbluebutton/bigbluebutton/pull/6510

@fcecagno uau, isso seria demais !!

Em relação à solicitação de recurso, concordo com @JedMeister , pode ser demais para o Etherpad fazer. Mas como isso pode ser útil para outros usuários, sugiro implementá-lo como um plug-in, não um recurso principal, de modo que esteja disponível apenas para as instâncias que realmente desejam fornecer esse recurso para seus usuários.

A maneira como o CoCalc faz isso é que os arquivos de bate-papo e o bate-papo
de qualquer arquivo tem um botão para iniciar um chat de vídeo ou áudio (anteriormente usando
aparecer, atualmente usando jit-si).

o nome "etherpad / lite" (é a segunda parte) deve significar algo.
murmúrio existe e coexiste. E já existem inúmeras soluções WebRTS diferentes disponíveis.
Apenas outra plataforma (com registro, credenciais, etc.) criará muitos problemas e até mesmo assustará os usuários.
(até agora, o pad era realmente a abordagem de baixa tecnologia. Se as pessoas querem coisas elegantes com login, já existem outras plataformas. Mas aí você fica preso em uma discussão de ferramentas entre compatibilidade, facilidade de uso, planos de dados móveis, logins 2FA etc. .)

o nome "etherpad / lite" (é a segunda parte) deve significar algo.

Tipo "vamos inventar juntos noivos?"

já existem inúmeras soluções WebRTS diferentes disponíveis.

Permitir que um deles seja facilmente integrado é a solução alvo aqui.

Apenas outra plataforma (com registro, credenciais, etc.) criará muitos problemas e até mesmo assustará os usuários. (até agora, o pad era realmente a abordagem de baixa tecnologia. Se as pessoas querem coisas elegantes com login, já existem outras plataformas. Mas aí você fica preso em uma discussão de ferramentas entre compatibilidade, facilidade de uso, planos de dados móveis, logins 2FA etc. .)

Por que você presume que adicionar um canal de áudio deve necessariamente exigir logins, registro, 2FA, etc.?
O controle de autenticação para colaboração Etherpad é ou pelo menos deveria ser uma questão completamente independente.

Infelizmente, por não ter um canal de áudio diretamente no Etherpad, as pessoas que desejam colaborar juntas _do_ têm que encontrar _uma outra_ plataforma e passar por seu processo de registro / autenticação separadamente e além de qualquer que possa se aplicar ao EtherPad em que estão trabalhando, portanto, é menos provável que participem de um esforço colaborativo que possa se beneficiar de suas contribuições. Se o Etherpad suportasse um canal de áudio fácil entre os colaboradores atuais que desejam usá-lo, talvez menos pessoas ficassem "assustadas" com a tecnologia escolhida por seus hosts de colaboração.

https://github.com/bit/ep_webrtc/ é a solução para isso.