lroellin
commented
6 years ago This would free the client audio/video component (which we think should be WebRTC, see below for reasoning) from a P2P DHT library implementation.
Why WebRTC? We'd rather not implement choosing a codec, encoding/decoding, syncing and other such dreaded tasks ourselves. Modern browsers are perfectly capable of handling these tasks themselves. Assuming the clients are in the same network, we don't need a relay server, that WebRTC usually uses.
Is this still P2P? Yes. The application has to be downloaded once, of course. But then, all code runs on the clients only.
We would rather use this architecture:
Basically, we write a P2P API that's responsible for exchanging connection details between peers. It would consist of an API client, running in a browser, and an API server, running in whatever language would suit. They would communicate over HTTP. This would all run on each client!
The API server would have a DHT library at its disposal, which is joined in a DHT with other P2P servers. The API client would talk to the browser's built in WebRTC component.
Whenever the API client requests a peer's connection details, the server would in turn ask the DHT library. The client then hands this information over to the WebRTC component. The WebRTC component then opens a direct connection to the peer's WebRTC component.