WebRTC, "P2P" and E2E

[simonwep]

As many of you stated in the Reddit Post, beam.cafe isn't real P2P - yes it does stream files from one end to another and filesharing is done secretly but it does pass through the backend of beam.cafe.

I've never worked with WebRTC so far but many of you told me that it allows true P2P connections, so I'll definitely take a look at that and see how this could be integrated in the current structure.

Another option would be adding E2E using the crypto api, not sure if this is possible performance-wise.

Any ideas, ressources regarding WebRTC and suggestions are highly appreciated!

[Technologeek]

Looks very straightforward to implement with the WebRTC SDK https://webrtc.github.io/samples/src/content/datachannel/filetransfer/

P.S: Love the project looking forward to contributing!

[simonwep]

I've spend the past 2 days thinking about how WebRTC could be added and I decided that it's not possible without dropping the entire backend and doing it all over again. There would have to be two apps, one to serve files (like the main app currently is) and another app to fetch / download data.

WebRTC

The server would only be used as signaling and exchanging RTCIceCandidates / RTCSessionDescription.

So basically, a hypothetical roadmap for a new, WebRTC-based beam.cafe would be:

• Replacing the backend with a new one used to exchange credentials between two peers.
• Removing all server-side settings from the current app including settings synchronization.
• Adding a RTCPeerConnection store to handle incoming connections (+ creating security policies for how long a connection should stay alive and a "protocol")
• Creating a new, second web-app to connect to your peer and download files (or should the second one get a downloads section? Seems to be overkill Imo).

TDLR: Creating a new application, build from the ashes of the current beam.cafe.

Situation

Not sure if I want to do this, the current way provides some features which are not possible to add in the rtc-way:

• Protecting the one who serves the file: The server will check if the file exists, if the ID is valid and so on - it's not possible to "spam" a peer.
• You can download files instantly: Downloading file means downloading it right away to your disk, using rtc would make this a web-based download experience with a progress bar and the actual download starting as soon as the transfer is complete - basically the mega.nz way.
• You can stream seamlessly: Yes - streaming could be done using rtc but it requires the app to manually fetch data and displaying it to the user. Currently you can stream anything the browser supports such as video and audio.
• There is literally no file-limit: Your peer would have to download the file into the browser, and I cannot find a way streaming something right to the disk and blobs have limitations.
• The server generates all keys: All keys related to downloads, files etc. are generated server-side and send to the client. Using WebRTC would require the one who servers the file to generate security related keys. This could be a opportunity for self-xss (although there's a warning but hey) and I'm not sure, in case of DDOS attacks against a client, how to "blacklist" connections.

---

The current state requires some kind of mechanism to prevent people from abusing the streaming possibility for whatever, it's like a vpn. Another option would be to add E2E encryption but I don't think that it's worth it doing that as it's very slow and It would lead to limitations.