Etherpad-lite: Solicitud de función: canal de audio

(Tenga en cuenta que no soy un desarrollador de Etherpad, solo un tercero interesado)

Personalmente, creo que integrar el chat de audio en el núcleo de Etherpad es una mala idea.

Si bien soy consciente de que Etherpad es multiplataforma, creo firmemente en la filosofía de Unix de "hacer una cosa y hacerlo bien" .

En mi opinión, la compatibilidad con el chat de audio es una funcionalidad secundaria (es decir, una función de arrastre) para Etherpad y, por lo tanto, no debería ser parte del software principal.

Habiendo dicho eso, ciertamente puedo ver cómo algún tipo de integración de chat de audio podría ser bueno para algunos usuarios. En mi opinión, un complemento para admitir la integración con una (o más) de la gran cantidad de plataformas de chat de audio existentes sería la mejor manera de abordar esto.

Solo mi 2c ...

Hay un trabajo en progreso para integrar Etherpad con BigBlueButton, que es un sistema de conferencias web de código abierto, por lo que proporcionará no solo un canal de audio, sino también canales de video, encuestas, grabaciones, entre otras funciones de colaboración. Ver: https://github.com/bigbluebutton/bigbluebutton/pull/6510

@fcecagno wow, ¡sería genial!

Con respecto a la solicitud de funciones, estoy de acuerdo con @JedMeister , podría ser demasiado para Etherpad. Pero como esto podría ser útil para otros usuarios, sugeriría implementarlo como un complemento, no como una característica principal, por lo que estaría disponible solo para las instancias que realmente quieran brindar esa característica a sus usuarios.

La forma en que CoCalc lo hace es que los archivos de chat y el chat lateral
de cualquier archivo tiene un botón para iniciar un chat de audio o video (antes
aparecer, actualmente usando jit-si).

el nombre "etherpad / lite" (es la segunda parte) debería representar algo.
el murmullo existe y coexiste. Y ya hay un montón de diferentes WebRTS-Solutions disponibles.
Solo otra plataforma (con registro, credenciales, etc.) creará tantos problemas e incluso asustará a los usuarios.
(hasta ahora, el pad era realmente el enfoque de baja tecnología. Si la gente quiere cosas elegantes con el inicio de sesión, ya existen otras plataformas. Pero ahí te quedas atrapado en una discusión de herramientas entre compatibilidad, facilidad de uso, planes de datos móviles, inicios de sesión 2FA, etc. .)

el nombre "etherpad / lite" (es la segunda parte) debería representar algo.

Como "¿Inventemos juntos comprometidos?"

ya hay un montón de diferentes WebRTS-Solutions disponibles.

Permitir que uno de ellos se integre fácilmente es la solución de destino aquí.

Solo otra plataforma (con registro, credenciales, etc.) creará tantos problemas e incluso asustará a los usuarios. (hasta ahora, el pad era realmente el enfoque de baja tecnología. Si la gente quiere cosas elegantes con el inicio de sesión, ya existen otras plataformas. Pero ahí te quedas atrapado en una discusión de herramientas entre compatibilidad, facilidad de uso, planes de datos móviles, inicios de sesión 2FA, etc. .)

¿Por qué asume que agregar un canal de audio debe necesariamente requerir inicios de sesión, registro, 2FA, etc.?
El control de autenticación para la colaboración Etherpad es o al menos debería ser una cuestión completamente independiente.

Desafortunadamente, al no tener un canal de audio directamente en Etherpad, las personas que quieran colaborar juntas _de_ tienen que encontrar _otra_ plataforma y pasar por su proceso de registro / autenticación por separado y además de cualquiera que pueda aplicarse al EtherPad en el que están trabajando. por lo que es menos probable que participen en un esfuerzo de colaboración que podría beneficiarse de sus contribuciones. Si Etherpad admitiera un canal de audio fácil entre los colaboradores actuales que desean usarlo, tal vez menos personas se "espantarían" por la tecnología elegida por sus anfitriones de colaboración.

https://github.com/bit/ep_webrtc/ es la solución para esto.