Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TURN in scope? #1

Open
max-mapper opened this issue Mar 6, 2018 · 4 comments
Open

TURN in scope? #1

max-mapper opened this issue Mar 6, 2018 · 4 comments

Comments

@max-mapper
Copy link

Hey, awesome project :) @mafintosh and I have been talking a while about the need for a TURN style proxy... use case is basically:

  • A and B can't connect directly due to firewall issues
  • C runs a service on a publicly accessible port that donates bandwidth for anyone to use
  • A and B connect via C, but C cannot read their encrypted dat streams. Only the IP addresses/ports of A and B are exposed to C
  • Because its Dat, there can be many A's, B's and C's in a swarm

I was wondering if this use case is close enough to the bridging protocols use case to put into this module. What do you think? (also what do you think @mafintosh?)

@louisgv
Copy link
Member

louisgv commented Mar 7, 2018

@maxogden I was researching the use case you described as well as TURN/STUN setup. Specifically looking at TURN's RFC abstract and there seems to be bunch of them. Got somewhat confused along the road. Can you point me to the relevant RFCs that I should focus on?

Thanks in advance :)

@louisgv
Copy link
Member

louisgv commented Mar 7, 2018

Also, from what I read, TURN could be an independent piece and is mainly depended on by simple-peer of webrtc-swarm for throwing packets through firewalls. Wonder if we could use something like https://github.com/coturn/coturn and just run it as a separate process together with hyperproxy. hyperproxy could def just bring up the subprocess.

Or are you thinking more along the line of implementing TURN within the proxy server?

@max-mapper
Copy link
Author

@louisgv I believe we wouldn't actually use the TURN protocol (or any of the webrtc protocols as they are quite complicated) but would rather roll our own similar thing that is based on the existing dat protocol. @mafintosh I think has a plan for this. I think the main idea of using our own is we can reuse the dat keypair and discovery network that way

@ColdSauce
Copy link
Member

@maxogden Sorry for such a late response, we had spring break this past week. I think that is a really awesome idea but I feel like it might be out of scope of this project.

I think it would be really cool to work on it though, so maybe if nobody has taken on that effort when we're done with this project, we can take that on, too!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants