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.