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

Publish a BEP explaining how to add support for WebTorrent #881

Open
wants to merge 4 commits into
base: beps
Choose a base branch
from

Conversation

yciabaud
Copy link
Contributor

@yciabaud yciabaud commented Aug 8, 2016

This PR proposes a BEP document as discussed in #168

I would like to have some feedback on the content and on some changes I made in the messages.
I changed some properties to have a cleaner protocol, if we keep it, we will have to update bittorrent-tracker to fit with this document.

You can view the html output on github: https://github.com/yciabaud/webtorrent/blob/486a94d2b651e7aed86ba27b82e679f5d1d1e700/bep_webrtc.rst

@feross @DiegoRBaquero @bbarrows


{
"announce": "",
"info_hash": "",
Copy link
Contributor Author

@yciabaud yciabaud Aug 8, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I changed the scrape response format from "infoHash" to "info_hash" to be consistent with the other messages.

Copy link

@wI2L wI2L Nov 6, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually I "think" (still not sure) that the response is created here : https://github.com/feross/bittorrent-tracker/blob/master/server.js#L698-L701, and that the "infoHash" field is used as a key in the forEachloop when creating a new entry in files list.

To me, it seems that either for a single or multi scrape request the response will contains a field list where the keys are the info_hash and the value an object with the stats of the related swarm.

@lmatteis
Copy link

lmatteis commented Aug 20, 2016

I'm a bit confused. So trackers supporting this would be able to track IP addresses of "normal" clients and also WebRTC contacts, right? That's cool but if WebRTC tabs can't connect to current BitTorrent client nodes (because most torrent clients don't support WebRTC), what's the point?

@yciabaud
Copy link
Contributor Author

The point of this BEP is to document the process of signalling webrtc peers on a tracker to connect each other.

Aside from the tracker implementation, the clients supporting this would become hybrid clients and could use webrtc to connect to browser clients.

This would help a lot to make bittorrent content available in webtorrent network.

Do you understand now? Do you have an idea to make it clearer for a reader to understand what we are aiming?

@yciabaud
Copy link
Contributor Author

The point is to make clients support webrtc by giving them a standard documentation ;)

@DiegoRBaquero
Copy link
Member

Just read it all. It's very technical to the point of a BEP. Is there any place where I can see the guideline for a BEP?

Looking good @yciabaud

@yciabaud
Copy link
Contributor Author

yciabaud commented Aug 21, 2016

Thank you for reviewing @DiegoRBaquero.
This page details the BEP process: http://www.bittorrent.org/beps/bep_0001.html, some other guidelines can be found in http://www.bittorrent.org/beps/bep_0002.html

@austlane
Copy link

@yciabaud Thanks so much for writing this up. Looks detailed and well done!
I've been following this project for a number of years, hoping feross would do this sooner rather than later.

@yciabaud
Copy link
Contributor Author

Thank you very much @austlane, lets hope we will push that to bittorrent soon!

{
"action": "error"
"message": ""
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I changed the error response message for it to look like the other messages like in other beps.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tbh, I think that both failure reason and an extra error field are necesseray. The first one wpuld stay for legacy reasons and would be used only for Bittorrent protocol related failures (either announce or scrape) while another extra field (or object, with code/message ?) could describe a signalling error.

@wI2L
Copy link

wI2L commented Oct 11, 2016

@yciabaud Just to clarify, is this BEP based on the actual implementation ? I couldn't find the error message you describe in the source code of the bittorrent-tracker project, instead it send back a failure reason key.

@yciabaud
Copy link
Contributor Author

@wI2L I made some changes that I have commented inline in this PR. You are right, ATM the errors are labelled with failure reason.

I changed a bit some of the payloads too, all changes are inline commented.

@wI2L
Copy link

wI2L commented Oct 11, 2016

@yciabaud Ok. I have added comments on some.
While reading the source of bittorrent-tracker I have noticed the use of common.hexToBinary (for info_hash) and I am not sure of how to interpret that. Like I have mentionned it in our mail exchanges, the "type" of each field could be described.
Also, the websocket protocol describes binary and text messages. it may be necessary to define what kind of messages are supposed to be sent and read ?

EDIT: Messages are text, but encoding of info_hash and peer_id fields is binary. What is the reason behind that? This should be mentionned in the BEP.

"uploaded": 0,
"downloaded": 0,
"left": 0,
"event": "",
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Analyzing a bit the payloads from wss://tracker.openwebtorrent.com/, this field is not present for announce done at regular intervals. However, for consistency with the BT protocol it should be mentionned that a missing event, or an event that is represented by an empty string is one of those made at regular intervals.

"offer_id": "",
"peer_id": "",
"to_peer_id": "",
"answer": ""
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

answer is an object with the fields type and sdp.

@yciabaud
Copy link
Contributor Author

Thanks @wI2L for these reviews, I agree that the types of the fields must be added to the BEP.
I will try to find a moment to work again on this.

@wI2L
Copy link

wI2L commented Oct 12, 2016

np @yciabaud
Also, I was wondering if the BEP should indicates how a BitTorrent tracker answer to a Webclient before the connection is actually upgraded to the Websocket protocol, in case of errors.
A standard tracker send back a bencoded dict with a failure reason key, with status code 200.

--------
The websocket tracker uses JSON payloads reflecting the HTTP request parameters
and an additionnal action property used to switch between announce and other
actions (ex. scrape). If the announce URL of the torrent contains the ws or wss

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I STRONGLY recommend that we formally drop support for insecure websockets. It's almost 2017, there is no reason to introduce a potential security vulnerability or vector for surveillance. Especially with Let's Encrypt available for free, there is simply no excuse for running an insecure public service. WebRTC itself already disallows insecure connections, we should incorporate that momentum into this BEP.

I suggest we change this explicitly disallow 'ws' and only allow 'wss' here.


{
"ih1": {
"announce": "",
Copy link

@wI2L wI2L Nov 6, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

scrape response::

{
"announce": "",
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@DiegoRBaquero
Copy link
Member

Is there anything missing so this can be sent?

@wI2L
Copy link

wI2L commented May 24, 2017

@DiegoRBaquero Depends, would you like with @feross and @yciabaud to address my proposals I have made in the PR here: yciabaud#1
There is two ideas, publish a document that describes the actual state of the protocol, which could be done by finishing/polishing the original draft of @yciabaud or discuss furthermore about the changes I intoduced in favor of a more comprehensive protocol.

@stale stale bot added the stale label May 3, 2018
@webtorrent webtorrent deleted a comment from stale bot May 3, 2018
@stale stale bot removed the stale label May 3, 2018
@stale
Copy link

stale bot commented Aug 2, 2018

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

@stale stale bot added the stale label Aug 2, 2018
@rom1504
Copy link
Member

rom1504 commented Aug 3, 2018

Why is this blocked ? It seems important for webtorrent and isn't most of the work already done ?

@stale stale bot removed the stale label Aug 3, 2018
@stale stale bot added the stale label Nov 1, 2018
@stale stale bot closed this Nov 8, 2018
@DiegoRBaquero DiegoRBaquero reopened this Nov 8, 2018
@stale stale bot removed the stale label Nov 8, 2018
@webtorrent webtorrent deleted a comment from stale bot Nov 8, 2018
@stale
Copy link

stale bot commented Feb 6, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

@stale stale bot added the stale label Feb 6, 2019
@stale stale bot closed this Feb 13, 2019
@lock lock bot locked as resolved and limited conversation to collaborators May 14, 2019
@webtorrent webtorrent unlocked this conversation Aug 3, 2019
@feross
Copy link
Member

feross commented Aug 3, 2019

Unlocking and re-opening this.

@feross feross reopened this Aug 3, 2019
@stale stale bot removed the stale label Aug 3, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Aug 3, 2019
@feross feross added the meta label Aug 3, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

9 participants