"With #Uber in trouble again, cities should get behind alternatives that are good for both employees and users"
@mark maybe. I'm a little unclear on how it works. If there is a server, who runs it, on what terms? Can multiple servers federate? If not, is it a P2P app? What communication and encryption protocols does it use?
@mark certainly can be done. After all the #Session folks forked the #Signal apps and rebuilt them to run on the #Loki #blockchain. I'd love to see someone do the same using #Matrix instead of Loki. Not sure how they'd do the voice/video chat, maybe using #Jami protocols? Session doesn't have realtime voice/video anyway.
You mean you've used #VoIP on #Riot, yes? That's a workaround that connects to a centralized server on matrix.org (running #JitsiMeet I believe?), it's not actually federated. So a Signal-on-Matrix fork would have to either set up their own VoIP server (and figure out how to pay for it), or find a decentralized VoIP solution (which is why I suggested Jami).
The first one, built into the spec, which only works for 2 people, so direct conversations, is P2P WebRTC with encryption.
The second one, probably most used, is a jitsi meet instance integrated as a widget.
The third one is a web based mumble client, also integrated as a widget.
Last but not least, there is an MSC (2359) for E2EE conferencing.
> that's a lot better than having all conferencing on the whole network go through the central jitsi instance.
True, but not as good as having all the conferencing going through the client apps (as Jami does), with no dependence on servers. Also, as with the attempt to shoehorn #Jabber chat into #Diaspora, it makes hosting a Matrix server even more of a headache if you also have to stand up a Jitsi Meet stack and duct tape the two together.
> True, but not as good as having all the conferencing going through the client apps (as Jami does), with no dependence on servers.
I disagree. Having a server do stream multiplexing vastly reduces the bandwidth requirements. Conferencing with many participants does not scale when done purely P2P.
> Also [...] it makes hosting a Matrix server even more of a headache if you also have to stand up a Jitsi Meet stack and duct tape the two together.
The new MSC there would not be Jitsi, but something else (with a much smaller scope) instead. Additionally, this would be optional, people don't have to host this, just as they don't have to host TURN servers today (used for the P2P VoIP direct chat thing).
@jcgruenhage OK, so, if I'm #user:domain.foo, and the admin of the domain.foo server doesn't host the VoIP stack or the #TURN server, can I still do voice/ video chat with Riot? If so, how does this work? What is the servers of the users I want to chat with don't host the VoIP/ TURN servers either? The UX fails caused by this sort of situation is one of the things that (AFAIK) killed off the attempt to use XMPP in Diaspora.
> The receiving party doesn't require a TURN server, since the party initiating the call is responsible for setting up the call.
OK, this sounds quite similar to the way Jami handles voice/ video. The difference being that Jami handles conference calls the same way, without the need for anyone to run a VoIP server. It would be amazing if users of Jami and Matrix clients were able to conference with each other.
@strypey @mark The problem is that without some sort of multiplexing, you have to send your own stream to each participant, so it scales linearly. With a multiplexing server, you have to send your own stream once, no matter how many participants there are.
About the question regarding jami: I couldn't find any documentation regarding the architecture of their group calls, so no, I haven't looked at any details there.
Actually I agree with @firstname.lastname@example.org for nowl. For Jami, the master of the conference receives all streams, mix-it together, send the resulting stream to each participant. So the participant only have one stream to send and to receive, but the master needs bandwith. Technically, you can have multiple masters, but there is no protocol for now for the conferences, so the result will be ugly. 1/x
@strypey Anyway, now the future we need:
Receivers should receive datas to separate the incoming stream to be able to mute one of the streams or play one video in big.
You can handle several master, but you need a protocol to describe the conference.
You can choose a master depending some parameters such as the REMB feedback (to detect available bandwith)
For the docs (https://docs.jami.net), Indeed it's missing. Will add a part when I'll have some time
So, yeah, you can handle a conf by only sending your video/audio once to a "master" that will send the video to others. Also, you can have several master to use the bandwith you can, but you will need a peer with some bandwith at some point.
The choice mainly depends on relying on a server or not.
@AmarOk @strypey So tldr on how you handle it at jami is that you choose one conference participant as the master that does the distribution. When no client has can handle that job adequately, the conferencing quality suffers from that. Does the master switch automatically when the situation changes? When someone with a workstation on a gigabit connection joins, where the other participants are on mobile networks, stuff like that. Having servers there to help does make sense in most situations.
@jcgruenhage For now, the person that invites one another is the master. As I described in my second comment, in the future this can be improved with a sort of protocol taking parameters such as REMB feedback (that we already use to auto adapt the video quality depending on the bandwith detected) or get several master for a conference to split the bandwith taken among peers (But it's not implemented yet)
@AmarOk @strypey yeah, in case my previous toot wasn't clear: Having a participant to the distribution means that the distributor can read the streams, which is useful as it can do encoding stuff then and provide low bandwidth stream to some clients. If the distributing peer is a server, you need e2ee to protect the data from that server, so the server can't reencode stuff on the fly to make up for diverse client requirements
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!