szimek / sharedrop

Easy P2P file transfer powered by WebRTC - inspired by Apple AirDrop

Home Page:https://www.sharedrop.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Using without Firebase.

physiii opened this issue · comments

I want to share files P2P within my network and between networks over the internet.

First step in the README for "local" development is to setup a Firebase account. Why stain a good p2p project with some brand name website: Firebase. I see google analytics in here which, okay, I can just cut out, then noticed Firebase is backed by google.

It starts feeling more like a marketing ploy than motives of just making a p2p app.

Can I use this project without signing up to your 3rd party Firebase service?

Hey @physiii !

It starts feeling more like a marketing ploy than motives of just making a p2p app.

It's not a ploy, but pragmatism :) The very first version of it used socket.io, but at the time (2013/2014) Heroku did not support websockets, it was much easier to switch to an external service. Also, back in 2014 Firebase was not owned by Google and it had the best support for user presence.

Can I use this project without signing up to your 3rd party Firebase service?

No, but you can create a fork and replace Firebase with e.g. socket.io. For local use socket.io is enough, but for production use deployments get tricky, as you most likely don't want to disconnect everyone every time you deploy a new version.

The best solution would be to introduce support for different backends via adapters, but it won't happen unless someone else implements it, or Firebase starts charging enormous amounts of money and forces me to do it.

It's not a ploy, but pragmatism :)

Ah okay, I see and apologize for the assumption :)

For my application I can not have a single point of failure. You probably know that the SDP can come from HTTP (including websockets) or any other means of exchanging SDP offer/answer. For testing, I have just been copy-pasting so I guess I would be the signal server in that instance.

My plan is similar to what Bitcoin uses:

  • Store a list of SDP offer/answer from connected and previously connected Peers
  • Have several dozen nodes with public ip and dns's then store those in the source code
  • Use SDP offer/answer from user input

you most likely don't want to disconnect everyone every time you deploy a new version.

Can you explain? Once the signal server establishes the p2p connection it is no longer needed to maintain the connection. So even if you had to restart the signal server it would not disconnect the peers. Only a new connection would be slightly delayed while software restarts but only a few hundred milliseconds. Am I missing something?

You probably know that the SDP can come from HTTP (including websockets) or any other means of exchanging SDP offer/answer.

Yeah, many of the early WebRTC demos used this way to not introduce some kind of signaling server and complicate things even more.

Can you explain? Once the signal server establishes the p2p connection it is no longer needed to maintain the connection.

That's true. However, Sharedrop uses Firebase presence feature to show other devices in the UI. I don't remember what the code does exactly in case someone disconnects from Firebase, but either it only hides the device in UI and the P2P transfer goes on, or it might be closing P2P connection as well, assuming that there's no network anymore. In theory, it could show the other peer as long as the P2P connection is established, even if connection to Firebase is already gone.