"With in trouble again, cities should get behind alternatives that are good for both employees and users"
theguardian.com/commentisfree/

Is there ride-sharing software that can be used by any community of drivers and customers wanting to set up a ?

@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?

I really don't know, @strypey - I just knew of the app's existence; I haven't used it in any way.

There is the suggestion on their website that it's based on #Telegram, whose servers, I believe, are proprietary.

@mark OK, thanks for the tip :) I'll investigate further.

@strypey
I guess if it was forked and rebuilt using #Matrix instead - then it could be run on a taxi company's own servers... Just a thought.

@mark certainly can be done. After all the folks forked the apps and rebuilt them to run on the . I'd love to see someone do the same using instead of Loki. Not sure how they'd do the voice/video chat, maybe using protocols? Session doesn't have realtime voice/video anyway.

@strypey
I've used Voip on #Matrix before, though I don't currently have the function.

@mark
> I've used Voip on before

You mean you've used on , yes? That's a workaround that connects to a centralized server on matrix.org (running 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).

@strypey @mark That is not entirely accurate. There's multiple kinds of VoIP used in the matrix ecosystem right now:

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.

@strypey @mark This last option, the MSC (github.com/matrix-org/matrix-d) would provide E2EE conferencing. It would still rely on a central service for each call, but if every matrix server hosts one of those, your client can choose your own server when starting the call, so that's a lot better than having all conferencing on the whole network go through the central jitsi instance.

Follow

@jcgruenhage
> 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 chat into , 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.

@mark

@strypey @mark

> 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.

@strypey @mark

> 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 :domain.foo, and the admin of the domain.foo server doesn't host the VoIP stack or the 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.
@mark

@strypey @mark That depends on the client. Riot falls back to the TURN server provided by matrix.org if your server doesn't host one. The receiving party doesn't require a TURN server, since the party initiating the call is responsible for setting up the call.

@jcgruenhage
> 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.

@mark

@jcgruenhage the Jami folks would disagree. Have you had a look at how their P2P voice/video chat works?
@mark

@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.

@jcgruenhage
> 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.

Any comment on this @AmarOk ?

@strypey

Actually I agree with @jcgruenhage@chaos.socia 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 (docs.jami.net), Indeed it's missing. Will add a part when I'll have some time

@strypey @jcgruenhage

3/3

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)

@strypey

@jcgruenhage

And I agree, having servers simplify a lot many scenarios, but we don't want to (talking for Jami) and it's possible to work without (just needs more work to develop the solution) It's a choice to make :)

@strypey

@AmarOk @strypey Having one of the conversation participants as the master has the advantage that you don't need e2ee, because they'd receive the contents anyway, so I agree that this also has benefits. It's an interesting space to watch!

@jcgruenhage @strypey everything between two peers is encrypted (TLS1.3 on the control channel - srtp on the media channels). You always needs e2ee for someone outside the call.

@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

@jcgruenhage In that sense, yeah. However, you need at least to sign messages sent by a peer, to avoid the server to send a message instead of you (Any choice will create different problematics :) )@strypey

@AmarOk @strypey Oh, right, in that case the master can't do any of that either, because the client hasn't signed the reencoded stream.. Damn, this really is something where no solution can be perfect, right?

@jcgruenhage Solutions are never perfect, it's more a question of choices and needs.

@strypey

Sign in to participate in the conversation
Mastodon - NZOSS

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!