I was just trying Delta Chat yesterday and wondering about a WebRTC video call button, too. Right now, I can type something like https://meet.jit.si/WHATEVER, send that, and everyone on the email list will be able to join a WebRTC video call by clicking that link as long as their browser supports WebRTC or they proceed to install the Jitsi Meet app when prompted on iOS and Android.
Why not make a button that does that? A preference could allow the user to enter any Jitsi server. Another preference could allow supporting other types of WebRTC servers. The button could:
Create a random Jitsi conference room link or allow the user to type their own. (Maybe random by default to make it easier?)
Send the link to all recipients
Auto-deep-link into the Jitsi Meet app so you’ll join the video conference room right away.
Is there any advantage to integrating video calling within the Delta chat app versus deep linking to a separate dedicated app like Jitsi Meet? I suppose it would mean one less app to download, but having it separate means you can switch video call providers more easily.
For a first and quick start, I’ld prefer your idea.
The advantage of an own WebRTC channel would be, to transfer the whole chat over this channel as well. And you could do this without audio/video as well.
I’m sorry for paranoia, but usually everything that provided at huge scale as open/free - it is a “mouse trap”. Stun server - it is dependency on 3rd party server(s) that providing stun service for free just to be able to get connections graph and be in control of this graph IMHO.
I really don’t want to be a party pooper, but what the point to duplicate functionality that already exists in Signal ?
Besides of forking Signal’s UI (that used by DeltaChat), you offering to implement the same Signal’s functionality. I probably missed something, but I can’t see any advantage of implementing WebRTC since this technology can not be decentralized and attempts to reinventing things that are already exists and well supported in other apps. Chat isn’t a missile’s control center that requires lightning speed communication, so WebRTC imo won’t bring any advantage to chat application. Real time Video/Audio? It is just a matter of go to https://meet.jit.si on any devices and start communication or use referenced above Signal.
What is uniqueness of your proposal to implement WebRTC, that doesn’t exists in other, well supported apps ?
I see your point. And I’m a friend of doing one thing good as well. So forget about the proposal. I wasn’t aware of meet.jit.si. Maybe some features or plugins to integrate those things soomthly.
indeed, that’s the idea: to make the webrtc server configurable and allow an easy way to share configurations. eg “attach+callprovider” on the sending side and “use callprovider” on the receiving side. This way you can easily offer a service to a chat group, and each member can “use it” (which means setting the webrtc-server settings accordingly) for setting up phone calls with others.
I guess the way to achieve LiveStreaming is to encrypt and to send data from one device, and the others shall receive and decrypt it. For P2P, video calls require “all in one” instead: encrypting, sending <-> receiving, decrypting.
While I think it could be possible for all-time powered devices, e.g. PC systems, it would not be suitable for charged handheld devices now: First, a device driven by a high-end SoC with enough memory to do the tremendous work fast and efficiently is absolutely necessary, still giving other apps enough “air to breathe” and to work acceptable with short UI/UX response times. And second, low power consumption (or a huge battery). Performing such video calls will discharge a battery within a couple of hours using todays high-end technology.
Please do not get me wrong, I would love to see this technology succeed on any device, even for P2P video chats, but the time has not come, yet. For now, a (one way) LiveStreaming solution seems to be a more realistic goal to achieve.
Thanks for such a rich conversation, as I am getting to know the project, I see a lot of value on it!
There is a very simple but useful usecase that is related to the post I did yesterday about local offline networks, that is being able to do a call in between two devices with no intermediaries (no ICE, STUN, TURN, DHT, server of any sorts) by hosting a service that allows for SDP initialization within the app itself.
If the devices are in networks where they can find each other, like:
a local offline network
a VPN
a logical mesh, like yggdrasil
they will be able to just use that for communication.
The upside of doing it this way is that anyone without deltachat can also access the call over a URL that can be hosted in the phone itself, like a mini jitsi meet just for that call. and that requires a little more than just hosting an html on the phone.
Instead of clipboard, SDP can be exchanged via email. RFC 4566 even has a section 3.3 dedicated to publishing SDP offer on WWW and exchanging it via email, reserving application/sdp MIME type.
This is experimental, because some problems remain unsolved:
All platforms need code to do WebRTC. For Desktop it is easy, because it uses Electron, but for Android and iOS something native is needed. Preferably something secure.
Because sending emails is more expensive than signaling over WebSocket, I have to wait until all ICE candidates are collected. Not really a problem, it takes “only” a few seconds, but see the next item.
When users are mobile, they may change their IP during the call. In this case, you need a way to send additional ICE candidates for renegotiation, as described in the section about ICE rollbacks and restarts in MDN. Doing such signaling via email is slow. I have not really explored how this mechanism works, but maybe the problem can be solved by establishing WebRTC data channel in addition to media channel and send ICE candidates over it when you detect that connection is lost. User who has a new IP will still be able to send data to user who has old IP, because data channels are unidirectional, and update its IP. This is how Wireguard and Mosh do roaming, and it should work as long as both clients don’t change their address at the same time.
Users still need to have STUN/TURN server configured within a client. STUN servers normally don’t require authentication, but TURN servers are like an email servers, you need a login and password to use them. And for this to work reliably at least one user is better use TURN so it can be used as a relay if direct connection can’t be established.
I guess that for the offline or local-first mesh networks case the best course of action is to have a local, as simple as it can be, jitsi-like instance, and configure that through the DC config.
My knowledge about WebRTC is limited. But my 2 Rials:
It is possible to form a network of STUN and TURN servers in the same way Bitcoin does which is DNS. This way the problem of these being centeralized will be solved.
On the Internet, and not in a LAN, a working STUN server is always required so that parties could find their place in the network.
In a majority of situations on the Internet or I think at least half of them, a TURN server is required because of NAT.
I believe a majority of users haven’t got an IPv6 therefore you can’t hope for not using TURN server.
WebRTC chats can be added on Desktop as experimental disposable chat.
Last but not the least, WebRTC is NOT the only P2P option and I believe since the apps are native, there are better options.
Jami/Ring is an example of a P2P chat. Could be used for inspiration or integration.
Edit: In Jami, it is P2P but you must enter a reliable bootstrap node. Maybe solve this with DeltaChat solution which is Email?
Edit2: In a LAN, there is UDP broadcast which allows easy data transfer if the network setup allows that as well.