[Freedombox-discuss] Janus as a video chat service in Freedombox

[Jonas Smedegaard]

Quoting Joseph Nuthalapati (2020-11-27 12:59:47)
> A WebRTC server by itself is not relevant to a FreedomBox user.

A WebRTC webapp by itself is not¹ relevant to a FreedomBox user either.

So let's discuss WebRTC _solutions_ as Fioddor accurately framed it.

I know of these Free video conferencing solutions lightweight enough for 
the FreedomBox project:

 * Webapp "Jangouts"           requires backend "Janus"
 * Webapp "Roomler"            requires backend "Janus"
 * Webapp "tawk.space"         requires backend "Janus"
 * Webapp "multiparty-meeting" requires backend "Mediasoup"
 * Webapp "Nextcloud Talk"     requires backend "Spreed"
 * Webapp "Wire"               requires some custom backend


I also know of these Free video conferencing solutions that I fear is 
too heavy for the FreedomBox project:

 * Webapp "Matrix Synapse" requires backend "Jitsi Videobridge"
 * Webapp "Jitsi Meet"     requires backend "Jitsi Videobridge"
 * Webapp "BigBlueButton"  requires backend "bbb-webrtc-sfu"
 * Webapp "OpenMeetings"   requires some custom backend
 * Webapp "openVidu"       requires backend "Kurento Media Server"
 * Webapp "mConf"          requires backend "Kurento Media Server"

Of the above, the solution looking the the least effort to get into 
FreedomBox quick seems to be the topmost - because janus is already 
packaged and the framework used for Jangout seems the least complex to 
get packaged among the Janus-based solutions.

But I encourage critical view on that.  Please play with the solutions 
and please dive in and package all the various components - it is 
certainly helpful to have experience and competition in this field.


¹ Webapp-only solutions exist but cannot handle sessions with more than 
a few participants, due to how WebRTC works - _efficient_ WebRTC 
requires a central point to "route" and/or "mix" traffic.


> What is the problem that we are trying to solve?
>   People need a privacy-respecting video calling/conferencing solution
> without the fear of their calls being eavesdropped on by the server
> operator.
>   Self-hosting the video-conferencing server solves this problem.
> End-to-end encryption is a plus.
> 
> How does a user expect to use the app?

Excellent question!


> User experience with current video-conferencing solutions takes two forms:
> 
> 1. Call your contact from an IM app.
>   This is similar to a phone call. The client plays a ring tone to alert
> the receiver of the call. Scheduling the call is not required. Let's
> call this use case "unscheduled video calling".
>    Supporting this use case is already in progress in FreedomBox. We
> already have coturn integrated. There is some work remaining to
> automatically setup coturn with Matrix Synapse and ejabberd apps.
> 
> 2. Ask your contact to meet using a meeting URL.
>   Scheduling or communication about the meeting is done using other
> channels. The app doesn't have to maintain contacts or even need a login
> to participate in the video conference. This is the use case of a
> scheduled video conference.
>   FreedomBox currently doesn't have an app in this category. We already
> have coturn server integrated, so we can say that some part of the work
> is already done.

I agree it is sensible to distinguish user experiences like the above.

The first of above I would call "voip" or "internet (video)phone" - 
because registering your end-point ahead of time is mandatory and 
conferencing features are an addon for the most complex of such tools.

Only the second of the above I would call "video conferencing" - because 
multi-party attendance is central to such tools and registering is an 
addon for the most complex of such tools.

So let's here discuss only the second of the above, please.


> From an end-user's perspective, I'd ask questions like the following
> about Janus server:
> 
> 1. Does it have good client apps?
> 2. How user-friendly is it to send a link from [it] to someone
> and ask them to meet?
> 3. Can a mobile-only user use [it] effectively?
> 4. Does it have all the necessary features expected from
> [this solution]? In other words, will people miss Zoom too much?
> 5. Is the [solution] already popular so that my contacts don't
> have a steep learning curve with it?

Great questions to ask (when adapted to talk about solutions).

I think requiring a positive answer to all those questions is setting 
the bar too high, however!

Having a conferencing solution in FreedomBox even if not not beating 
Zoom in features and UX and familiarity is in my opinion better than 
having none.


> In my opinion, a great server application is pretty much useless to a
> FreedomBox user if there are no good clients to use it with.
> But should we integrate yet another good WebRTC server into Debian? Yes,
> absolutely!
> 
> Discussing about Janus in the context of FreedomBox feels like
> discussing about Nginx or Apache. It's only an infrastructure component.

It is not possible to answer your good questions above without taking 
backend into account!

nginx and apache2 both serve web pages well - the choice of either of 
those do not affect user experience.

The same cannot be said for WebRTC backends.


> It doesn't qualify as a FreedomBox app.

No, but a videoconferencing _solution_ does - it involves both backend 
and webapp parts, none of which should be ignored in this discussion.


> coturn might seem like an exception to this rule. But it is only 
> listed as an (advanced) app to allow for manual setups, since it's not 
> fully integrated yet.

I fail to see how coturn is an exception - it is a daemon, not an app.

FreedomBox most visibly contains apps but also contains daemons.

Matrix Synapse is also not an app, but is it an "exception"?!?


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <http://alioth-lists.debian.net/pipermail/freedombox-discuss/attachments/20201127/9e0069fc/attachment-0001.sig>