WebRTC for communicating

Are you using something like the jitsi Meet SDK in you app? It says the TURN server can be configured.

Here is some debian discussion about running a (decentral) TURN server behind a NAT https://salsa.debian.org/freedombox-team/plinth/issues/685

And it will ruin two important unique features: everybody with an email can take part in conversation, all messages are in your email folder.

If we would do it we would only do it opportunistically anyway to increase message delivery speed. So it wouldn’t affect that feature. So no worries :wink:

1 Like

If all received messages ends up in DeltaChat folder, than it’s cool! )

That’s my idea.


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:

  1. Create a random Jitsi conference room link or allow the user to type their own. (Maybe random by default to make it easier?)
  2. Send the link to all recipients
  3. 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.

1 Like

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 ?

1 Like

Hello Alex,

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.


You could give the user the choice to choose another STUN server, which sounds pretty decentralized to me.

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.

Hm, maybe the goal could be even higher - i.e. no servers at all, but just purely decentralized video conferencing.

Guys from PeerTube seem to be trying to implement it - see my comment Video chat integration .

1 Like

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.

Best, Gerry

Hi all!

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.

You can check the boilerplate for this here: https://github.com/cjb/serverless-webrtc

Would that be something you would be interested in exploring?


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.

1 Like

Delta Chat currently has integration with Jitsi Meet and basicWebRTC.

I did an experiment inspired by Serverless WebRTC: https://git.sr.ht/~link2xt/webrtc-clipboard-call It is basically the same but the code is written from scratch without all the cruft required to support older browsers. All the code is in ~200 lines long index.tsx. I wrote this at the time when we explored various approaches to WebRTC calls for DC, as a proof of concept.

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.

Thanks for such an extensive response.

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.

Would dig more and get back to you all.

Ref. my comment about the recent [WebRTC-related] developments in NextCloud Talk over in this issue:

What about IPv6 support? It’s becoming more and more widespread.
With IPv6, STUN / TURN not longer needed in most cases.