Re: practical organization next Solid Community phone conf

Quoting Mitzi László (2019-03-06 00:00:11)
> Would you be ok with choosing the call in tool an item agenda so we 
> can have a conversation about it together?

Sorry, I cannot parse above sentence.

If you mean to suggest that you and I make a voice conversation then 
sure, I'd be happy to do that.  It is well past midnight here in Denmark 
now, so let's wait till after I get some sleep - i.e. 7-8 hours from 
now, then I am available online ~12 hours.

> When I downloaded Mumble I got this: 

Sorry, I am only familiar with using Mumble on Debian and Android, where 
you shouldn't "download" but "install from the package manager".


> I’m as heartbroken as you are about having a lack of viable convenient 
> online tools that align with my value set and would love to use Solid 
> chat (asap!). Would be a shame if our interim solution would slow down 
> the building of Solid.

I sure don't want to slow down progress here.  I am likely not the most 
important participant in these meetings, so if my priorities differ from 
those of others then favor their needs over mine!


> There’s a group of students working on Solid chat who talk here 
> https://gitter.im/solid/chat-app <https://gitter.im/solid/chat-app> 
> perhaps you could offer guidance?

Uhmmm, I'd be happy to help, but don't use Gitter.

I am "jonas" on the OFTC.net and also attend a few other irc networks.

I am jonas:matrix.jones.dk on (you guessed it!) Matrix.


> Also, Michiel de Jong is having a go at building a viable Solid Chat 
> app, perhaps you could connect with him and see how to speed things up 
> so we can use Solid Chat for the W3C Solid Community Group calls and 
> online chat.

Most important for our meetings is not wrapping it in Solid, but that it 
scales to 30+ participants!

realtime chat consist of "dialing" and "streaming". A Solid app would 
mostly be about dialing, whereas streaming - Solid or not - will use one 
of three models: mesh, MCU, or SFU.

Mesh is each participant streaming peer-to-peer with each other - 30 
videostreams up and 30 videostreams down - way too much traffic!

MCU is each participant streaming with a central point which recodes and 
mixes the streams - heavy CPU burden on that central server!

SFU is each participant streaming with a central point which routes 
(without mixing) e.g. only the video of the person shouting the loudest.

An MCU can treat each participant specially - e.g. if you have a weird 
system (it crashes when you try run Mumble on it!) so the MCU recognizes 
your special needs and recodes all video spoonfed for you.  Great user 
experience - but expensive in computing power.

An SFU in comparison is efficient but at the cost of relying on 
participants to use highly compliant software.  If you use a weird 
browser spewing out crappy video, then all 29 other participants may 
experience trouble - and it is maybe very difficult to identify that you 
caused the instability.

This is comparable to the difference of renting a room at a hotel for 
holding our meeting, versus borrowing a garage.  The former is 
convenient but expensive, the latter is super cheap and works fine if 
only everyone remember to bring a chair and water bottle themselves.

I recommend that we use an SFU, and that we use an existing tool. These 
are arguably the most prominent Freely licensed SFU projects:

  * Jitsi Meet (beware that "Jitsi" is several different things!)
  * Janus
  * Medooze
  * Kurento
  * Mediasoup
  * Licode

Of those, I recommend the only one currently packaged in Debian: Janus.

I happen to maintain Janus package in Debian, but that's not why I 
recommend it, it is the other way around: I packaged it because to me it 
seems of better quality among them.  Others are free to disagree, but 
then I strongly urge them to back that choice with ensuring that it gets 
packaged for major Free software distributions, as that strongly helps 
easing deployment.  As an example, Jitsi Meet is a big mess of code from 
multiple sources with complex licensing (or at least that is how I see 
it, again others are free to disagree, just back that up with getting it 
into Debian which implies its source is sanely licensed and reliably 
compilable acrose multiple computer architectures).


Sorry, this ended up a way longer email than I intended.  Good night!


 - Jonas

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

 [x] quote me freely  [ ] ask before reusing  [ ] keep private