Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The BitTorrent Protocol Specification v2

bittorrent.org

Post reply on HN
Print view View original

81–90 of 114 posts

Re: The BitTorrent Protocol Specification v2

#81

Post by redm »

I just don't see this technology ever going mainstream. I first deployed this type of application in 2003. It was named Redswoosh and did effectively the same thing as BitTorrent, just in a closed client. I was also a very early adopter of BitTorrent using it personally.

Users hated it for general use, even when downloading big files. 1) They didn't like having to install/run some special software to download a file. 2) They didn't like the effects of uploading to others and it slowing down the connections.

Consumer networks are asymmetric having far more download capacity in upload capacity. This makes sense since 1) most users download and want to use the available bandwidth for faster downloads, and 2) it prevents commercial applications on consumer circuits. This is far from ideal for applications like BitTorrent.

I'm not saying there isn't an application for this technology, I'm saying all the good applications don't want to ask the users to pay for distribution to other users. Thus it's relegated to mostly piracy, open source, etc.

Bittorrent Inc. has been trying to commercialize this for a decade now, I just don't see it happening. If there was anyone who could commercialize it, it was Travis Kalnik, and while he exited for 20m, he was very lucky, (and happy) to get out of that market.

Re: The BitTorrent Protocol Specification v2

#82

Post by Piskvorrr »

Klathmon wrote: post #74
boyce wrote: post #46

Earlier quoted context omitted.

I'd love to see a p2p wikipedia and a p2p twitter alternative Moving bittorrent away from it's present image could be achieved by making p2p useful beyond bluray rips

Personally I really truly believe that once you can make a torrent client in javascript that runs directly in the browser without any plugins or gateways/tunnels that you will see it explode. Developers will code it into their download pages, decentralized systems like a p2p wikipedia will be possible and always accessible by anyone with a browser.

You will see it explode indeed (where "it" means "the browser" and "explode" means "tab gets throttled and/or crashes"). I understand the motivations for everything-in-a-browser, but this approach has major externalities - e.g. the client's power, both as in CPU and as in battery.

Re: The BitTorrent Protocol Specification v2

#83

Post by boyce »

Klathmon wrote: post #74
boyce wrote: post #46

Earlier quoted context omitted.

I'd love to see a p2p wikipedia and a p2p twitter alternative Moving bittorrent away from it's present image could be achieved by making p2p useful beyond bluray rips

Personally I really truly believe that once you can make a torrent client in javascript that runs directly in the browser without any plugins or gateways/tunnels that you will see it explode. Developers will code it into their download pages, decentralized systems like a p2p wikipedia will be possible and always accessible by anyone with a browser.

Yes please, someone do this

Re: The BitTorrent Protocol Specification v2

#84

Post by Klathmon »

lqdc13 wrote: post #80
Klathmon wrote: post #74

Earlier quoted context omitted.

Personally I really truly believe that once you can make a torrent client in javascript that runs directly in the browser without any plugins or gateways/tunnels that you will see it explode. Developers will code it into their download pages, decentralized systems like a p2p wikipedia will be possible and always accessible by anyone with a browser.

https://webtorrent.io/

sadly I believe that relies on special software bridges or gateways to talk to "true bittorrent networks".

Re: The BitTorrent Protocol Specification v2

#85

Post by Klathmon »

Piskvorrr wrote: post #82
Klathmon wrote: post #74

Earlier quoted context omitted.

Personally I really truly believe that once you can make a torrent client in javascript that runs directly in the browser without any plugins or gateways/tunnels that you will see it explode. Developers will code it into their download pages, decentralized systems like a p2p wikipedia will be possible and always accessible by anyone with a browser.

You will see it explode indeed (where "it" means "the browser" and "explode" means "tab gets throttled and/or crashes"). I understand the motivations for everything-in-a-browser, but this approach has major externalities - e.g. the client's power, both as in CPU and as in battery.

Something like a torrent network is a bunch of IO with some processing which fits perfectly with javascript. WebAssembly might be able to get around some of the performance issues in specific areas (like some of the more complicated hashing stuff) if there are some, but it's more than possible to write performant code in javsacript.

Re: The BitTorrent Protocol Specification v2

#86

Post by aninhumer »

the8472 wrote: post #10
jzelinskie wrote: post #6

This update to the spec is a modest change that's largely a preemptive reaction to SHA1 being broken; large portions of BitTorrent are designed around the 20-byte length of a SHA1 checksum. They've decided to move forward with SHA256 truncated to 20 bytes to avoid incompatibilities with existing infrastructure such as the Mainline DHT. Beyond the hashing algorithm, some important additions that were previously propos…

The DHT BEPs specify a network that is only barely related to the bittorrent core protocol, they can already be used independently, and some people do. > I feel like trackers were largely overlooked in this update, but I'm biased because I work on a popular tracker. Yes, we did not pay much attention to trackers, but BEP52 basically seized the opportunity to do some incompatible changes we always wanted to do anyway…

>The DHT BEPs specify a network that is only barely related to the bittorrent core protocol

Yeah, if I remember correctly bittorrent DHT ultimately just maps 20 byte hashes to peer-lists (IP + port pairs). It's obviously designed to be convenient for bittorrent swarm discovery, but nothing about it limits it to bittorrent usage. Indeed, I'm surprised it's not more widely exploited for p2p bootstrapping.

Re: The BitTorrent Protocol Specification v2

#87

Post by wongarsu »

boyce wrote: post #68
fps_doug wrote: post #63

Earlier quoted context omitted.

I liked how the old Opera included a bittorrent client. It was the only browser that did, and felt like it was actually the way it was meant to be used. But nobody got it. You had warez kiddies left and right complaining how it sucked compared to Azureus and later µTorrent which had bazillions of features to tweak and max out their connection, or saying it was useless because their favorite ALT did not whitelist Oper…

I think there's still potential to steer BT in a more exciting direction if there was the will to from those involved. More quality software projects using it to download by default. Bring the trust back, shake off the reputation for just being trojan-infested cracks. There's plenty of things besides piracy people could be doing with torrents and related tech and it seems like such a waste of an idea. A Linux package…

Updates for large software (mostly games) is often distributed via BT. But it's mostly invisible to the end user because the client just does it transparently.

Re: The BitTorrent Protocol Specification v2

#88

Post by wongarsu »

ue_ wrote: post #77
Klathmon wrote: post #71

I have to admit, BitTorrent is one of the things I took for granted. I never really thought about the details of how it works, or the really really impressive feats that were accomplished to get it to work. I knew it was a really good technology, but reading this and the comments here puts it on a whole other level. Why isn't this technology talked about more? Why are blockchains the big "thing" right now with people…

I wanted to implement a distribured imageboard over bittorrent but I quickly realised it's hard to add data after the initial publication, and further to verify it, and the nature of trackers may make it prone to censorship. So I gave up.

Distributing the images/posts via bittorrent and the relations between them in the DHT might be the way to go with such a project.

On the other hand, the an uncensorable imageboard would profit from the verifiable timestamping of a blockchain, with just the images distributed via a bittorrent-like mechanism. That also gives you a decent anti-spam mechanism (you can post in exchange for mining blocks, similar to the original idea of hash-cash)

Re: The BitTorrent Protocol Specification v2

#89

Post by cesarb »

fps_doug wrote: post #63
boyce wrote: post #46

Earlier quoted context omitted.

I'd love to see a p2p wikipedia and a p2p twitter alternative Moving bittorrent away from it's present image could be achieved by making p2p useful beyond bluray rips

I liked how the old Opera included a bittorrent client. It was the only browser that did, and felt like it was actually the way it was meant to be used. But nobody got it. You had warez kiddies left and right complaining how it sucked compared to Azureus and later µTorrent which had bazillions of features to tweak and max out their connection, or saying it was useless because their favorite ALT did not whitelist Oper…

Also, the original Bittorrent client looked like an Internet Explorer file download dialog. The download experience was nearly identical: you clicked on a download link, and a download dialog with a progress bar opened up. Behind the scenes, the torrent file MIME type was registered to the Bittorrent client, so it was downloading the torrent file and launching the Bittorrent client, while a normal download showed the download dialog directly, but the user didn't have to be aware of these details.

So yes, it's the way it was originally meant to be used.

Re: The BitTorrent Protocol Specification v2

#90

Post by wongarsu »

Klathmon wrote: post #71

I have to admit, BitTorrent is one of the things I took for granted. I never really thought about the details of how it works, or the really really impressive feats that were accomplished to get it to work. I knew it was a really good technology, but reading this and the comments here puts it on a whole other level. Why isn't this technology talked about more? Why are blockchains the big "thing" right now with people…

BitTorrent is "just" exchanging files via a p2p connection. It's kind of useful, a lot of projects use it in one way or another, but it's unlikely to be instrumental for "the next big thing".

The BitTorrent DHT is great for storing and exchanging metadata, but a DHT is not something most people associate with BitTorrent (Bitcoin also has uses a DHT (for client discovery), as do countless other services).

Blockchain technology on the other hand offers verifiable distributed timestamping (with ok-ish resolution). That has much wider applicability than just payment tracking (which is essentially all bitcoin does), which is why there's plenty of people exploring what's possible.

Post reply on HN