Updating Torrents Via Feed URL(bittorrent.org)
bittorrent.org
Updating Torrents Via Feed URL
http://www.bittorrent.org/beps/bep_0039.html
14 comments
I would find this very useful for downloading TV episodes of currently running shows. You could have a single torrent for a TV show, and all new episodes would download automatically.
My current method involves some hacked together RSS feeds and regexs that are less than ideal.
My current method involves some hacked together RSS feeds and regexs that are less than ideal.
I imagine that there are private trackers that solve this problem with hand-checked RSS feeds (although I still just manually search for/download the episodes).
You could check out http://tvshowsapp.com/
Or Sickbeard.
does this service work for you? My feed never downloads anything.
it works great with http://put.io for me
ezrss was nice, but nowadays I always see 503 - Service Unavailable.
Just use sickbeard, so much easier. :-).
As cool as this is, isn't it a rather glaring security risk? Who is to say that the embedded URL isn't malicious? Or a nefarious tracking link inserted by RIAA/MPAA/whatever?
Besides, isn't this rather old news? The page is dated October 2012...
Besides, isn't this rather old news? The page is dated October 2012...
The BEP suggests that torrents that do this should include a public key in the original torrent, and then the update must be signed with the corresponding private key. So the idea is if you trusted the original you should trust the update.
Well, it doesn't seem like a well known concept (and it was new to me that torrents can do such a thing).
How is the proposed concept in any way less secure than the given model? You already have to trust the source that the file is the promised one and not a infected, and you already have to trust your peers not to log your ip and sue you. An update-url shouldn't change much.
How is the proposed concept in any way less secure than the given model? You already have to trust the source that the file is the promised one and not a infected, and you already have to trust your peers not to log your ip and sue you. An update-url shouldn't change much.
Afaict, you don't actually need to be downloading the content in order to check for updates and the signing is not mandatory ("should be signed" not "must be signed"). Don't the content providers already pose as peers and even share (sometimes corrupted) torrents in order to track down infringement? The feed could even be legitimate in and of itself, even when signed, but still pass on user information to a centralised server.
I'm no security expert and it's quite possible that it's all quite safe, but to my layman's eyes it seems there's substantial potential for abuse, especially to unsuspecting users.
I'm no security expert and it's quite possible that it's all quite safe, but to my layman's eyes it seems there's substantial potential for abuse, especially to unsuspecting users.
I'm not sure why this needs to be solved in the bittorent protocol itself. It would be easy to build a solution on top of bittorrent.
Many clients already support downloading from RSS feeds for instance. It would be nice to have a decentralized way of handling that kind of periodic contents but if I understand TFA correctly the proposal embeds an URL for the updates, so it's centralized as well?
If that's the case I don't see the advantage over RSS. I'm a firm believer in the unix philosophy of having one tool do one thing and do it well.
Many clients already support downloading from RSS feeds for instance. It would be nice to have a decentralized way of handling that kind of periodic contents but if I understand TFA correctly the proposal embeds an URL for the updates, so it's centralized as well?
If that's the case I don't see the advantage over RSS. I'm a firm believer in the unix philosophy of having one tool do one thing and do it well.
Maybe it's easier to formally standardize a feature like this if it becomes a part of the protocol.
How will that work with magnets?
magnet => torrent => update_url => new torrent (bis)?
magnet => torrent => update_url => new torrent (bis)?
The security implications of this are staggering. Or am I missing something?
The torrents are signed so you can use a reputation model just like now.
[deleted](1)
This definitely has some potential for abuse through bait and switch schemes. When you go to the torrent download page and see that no one has reported it as being fake or malicious, you feel safe in downloading it. Then, once it has got sufficient downloads, you send something out that is more malicious. Of course, a quick visual scan would make it easy to detect outliers in cases like TV shows (you would expect each download to be roughly the same file type and size, with a consistent naming pattern).
I designed (any many others did too) something similar in like 2004 to 2005. Several Public Access TV stations used it to sync content between themselves, and AFAIK it is still in use.
Do you already know Bitlove http://bitlove.org? It turns classic podcast RSS feeds into torrentified podcast feeds.
Cool, but please make sure you torrent safely: http://www.greycoder.com/?p=5799
"If a response with a 200 status and a valid torrent file is recieved, the client should download that torrent."
This isn't possible in this order, right?
This isn't possible in this order, right?
and my dreams become reality!
1: create a torrent for every package on archlinux using bep 39.
2: sign them with maintainers keys
3: ???
4: PROFIT!!!
[1] http://forum.deluge-torrent.org/viewtopic.php?f=8&t=45839