-
Notifications
You must be signed in to change notification settings - Fork 5
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
Comments
@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 :) |
Also, from what I read, TURN could be an independent piece and is mainly depended on by Or are you thinking more along the line of implementing TURN within the proxy server? |
@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 |
@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! |
Hey, awesome project :) @mafintosh and I have been talking a while about the need for a TURN style proxy... use case is basically:
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?)
The text was updated successfully, but these errors were encountered: