Twilio releases open source video conferencing apps for iOS, Android and web

Post by jakear » Fri, Mar 13, 2020, 6:37 PM UTC

jka wrote: post #13

These are open source clients for a proprietary backend, which are no doubt still useful in a number of circumstances. If you are comfortable with a more proprietary stack, then Google Hangouts / Zoom / others are likely to provide a better supported user experience. If you would prefer a more libre end-to-end experience then Jitsi Meet may be an attractive alternative.

Post by jka » Fri, Mar 13, 2020, 6:48 PM UTC

jakear wrote: post #21

jka wrote: post #13

These are open source clients for a proprietary backend, which are no doubt still useful in a number of circumstances. If you are comfortable with a more proprietary stack, then Google Hangouts / Zoom / others are likely to provide a better supported user experience. If you would prefer a more libre end-to-end experience then Jitsi Meet may be an attractive alternative.

Even RMS has no problems with using open source frontends to proprietary services. The reasoning is: if you can audit and modify the way you talk to the service to ensure you arent revealing any information you'd rather not, why do you care if the service itself is OSS, proprietary, or some dude in Qubec handcrafting TLS packets?

Post by ethanwillis » Fri, Mar 13, 2020, 6:59 PM UTC

rahimnathwani wrote: post #16

Someone wrote: post #12

Earlier quoted context omitted.

But they are open source (Apache licensed), so that can be changed. Potentially, one could make a fork that can use either one’s own backend or Twillio’s, while Twillio’s own can only use Twillio’s.

Is it trivial to write a backend that will replace the functionality in Twilio's backend?

Post by mendelmaleh » Fri, Mar 13, 2020, 7:06 PM UTC

jakear wrote: post #21

jka wrote: post #13

These are open source clients for a proprietary backend, which are no doubt still useful in a number of circumstances. If you are comfortable with a more proprietary stack, then Google Hangouts / Zoom / others are likely to provide a better supported user experience. If you would prefer a more libre end-to-end experience then Jitsi Meet may be an attractive alternative.

Even RMS has no problems with using open source frontends to proprietary services. The reasoning is: if you can audit and modify the way you talk to the service to ensure you arent revealing any information you'd rather not, why do you care if the service itself is OSS, proprietary, or some dude in Qubec handcrafting TLS packets?

Post by giancarlostoro » Fri, Mar 13, 2020, 7:15 PM UTC

jakear wrote: post #26

jka wrote: post #23

Earlier quoted context omitted.

That doesn't sound like him :) Do you have a reference/quote for that, out of interest? In the past it seems like he's been skeptical[0] of providing user data to third-party services. [0] - https://www.theguardian.com/technology/2008/sep/29/cloud.com...

This was from a private email exchange, but you can look at how he's soliciting a FOSS Google Docs client as evidence that he'd be fine with a FOSS interface to a proprietary service. Additionally, https://www.gnu.org/philosophy/javascript-trap.html makes no mention of proprietary backends being harmful to user freedom, only obfuscated (unauditable) frontend code.