> Movies are different. Search for a movie on a torrent site and you'll see 4K remux, 1080p, 720p [...]. But no one downloads models like this: anyone who wants DeepSeek-V4.1-Flash-1017 wants the same 48 shards.
But this is exactly the situation for AI models as well. If you look for
DeepSeek-V4.1-Flash-1017 or Qwen3.8-27B on HuggingFace, you'll see many different releases by various people with different quantizations like FP8, Q4_K_M, INT4, abliterated/uncensored models and various versions that are fined tuned or modded in whichever different way. It feels to me exactly like the various different video encodings.
Yes, there is usually a single, official release from the lab that produced the model (or sometimes a handful of different variants), but very frequently this isn't something you can even run on consumer hardware.
Very few users will end up downloading the base model straight from the lab, chief reason being they can't actually use it for inference on consumer hardware. We will end of with the same scenario described for films where lots of competing providers for different quantisations and fine-tunes will dilute the swarm. I can only assume this was written from the perspective of a developer/researcher?
Torrent always made more sense for distributing large static files like models especially ones where specific ones suddenly become popular and need scaling. Huggingface is incentivised to not do that though to keep control.
The main currency the platform has with investors and model creators is download stats. If they hand seeding over to DHT that basically means giving up transparent analytics on purpose and they don't need that.
I feel like if Bittorrent shipped in the browser, either embedded or as an extension and just ran on it's own accord, managing the download and throttling upload & download speed based on my current usage and needs without a lot of tweaking and configuration setup, that would be fine. I know most browsers tried this and gave up on it years ago. But, I'd rather not manage a separate program, having to fiddle with settings and open ports and have it always running in the background using a lot of ram/cpu, it's just a hassle.
But, are big CDNs really struggling to manage people downloading 500+gb models? Is AWS/Cloudflare/Akamai/etc begging for p2p hosting again?
Building BitTorrent into the browser is a bad design. I tried and measured it. It makes the browser even more bloated and busy and less responsive and vulnerable to crashing than it currently is, which is a leap in the wrong direction.
It's much better to run just one BitTorrent client as a separate process, a system service that all other programs can share and access via local http (through a data channel configured by url parameters, and optionally a control channel for monitoring and on-the-fly configuration), not built in and tied to one particular app like the web browser.
That's how Red Swoosh and Bittorrent DNA worked: They acted like a local web server, and any web client could simply open a url and start downloading the content, which would be delivered as it was received. BitTorrent DNA had an option of trying to download the chunks in order as much as possible, so it was better for watching streaming video. But they were competing products, you would not want to run both at once.
The point is that every app knows how to fetch files via http, and doesn't need to know a thing about BitTorrent. So the Red Swoosh or BitTorrent DNA service makes BitTorrent look like http, and you don't have to modify the web browser or link in any native libraries or bloat and degrade any apps.
Akamai acqui-hired Travis Kalanick (yeah that insufferable überbro) and his Red Swoosh app because it was a threat to them, to keep it from cutting into their profits, and unilaterally lowered their prices for TomTom to keep us from using BitTorrent DNA instead.
This is why most web browser tried and abandoned the embedded approach years ago, and why AWS/Cloudflare/Akamai/etc loath to support p2p hosting:
DonHopkins on April 16, 2014 | parent | context | favorite | on: Spotify Starts Shutting Down Its Massive P2P Netwo...
When I worked for TomTom, I developed and tested a system for distributing maps via BitTorrent.
I first looked at Red Swoosh and its Firefox extension, FoxTorrent. It would have been ideal, since we using the xulrunner platform for TomTom Home, but Akamai acquired Red Swoosh, and it vanished without a trace. [1] [2] [3] [4]
TomTom's Maps are perfect for BitTorrent distribution, because they're large (1 Gig and growing) and lots of people in the same region need to download the same map at the same time. And it would have been a wonderful legal and practical example of a legitimate use of BitTorrent to point to when companies like Comcast try tricks like blocking BitTorrent traffic.
I visited BitTorrent in San Francisco, and discussed it with Bram Cohen. Their technology seemed ideal for our purposes (it worked a bit like Red Swoosh / FoxTorrent), and they quoted me a price per gigabyte to distribute content over their BitTorrent DNA network, which was a hell of a lot cheaper than we were paying to Akamai (this was before the made BitTorrent DNA distribution free).
A couple days after that meeting, I stopped by the Akamai booth at the Game Developer Conference in San Francisco, and asked them what their prices were for using the Red Swoosh technology they'd recently acquired. Travis Kalanick, the founder of Red Swoosh, gladly told me about his technology and answered my technical questions. (I had previously been looking at Red Swoosh and FoxTorrent, before it was acquired by Akamai, and it would have been easy to integrate with our xulrunner based product, TomTom Home).
Akamai's sales people refused to quote me a price, despite repeated requests, so I told them the price BitTorrent quoted me, and told them we were ready to start testing as soon as possible, and asked again if they could at least give me a ballpark estimate of how much they would charge for distributing content via Red Swoosh, and when we could start testing. They muttered something about not having come up with a pricing model yet, but that I could get into their beta program, whenever that started, which they also would not state.
I was somewhat skeptical about Akamai's support for Red Swoosh, dedication to P2P technologies, and motivations for acquiring Red Swoosh, since P2P technologies are such a huge threat to their business model. It was getting a lot of attention before they acquired it. I was afraid that they might have just acqui-hired Red Swoosh simply to sweep it under the rug so they didn't have to compete with it. And I was afraid that if and when they finally figured out how to charge for it, it might not be such a great deal after all.
So I went back to Amsterdam, integrated BitTorrent DNA into TomTom Home (the desktop app for managing content and downloading maps on your TomTom device, like iTunes for TomToms instead of iPods, which happened to be implemented on xulrunner (the Mozilla "platform" that Firefox and TomTom Home are build on top of -- which Mozilla eventually lost interest in supporting as a third party application development platform).
It was easy to integrate BitTorrent DNA into TomTom Home, it worked well, and I performed a successful beta test with a bunch of users across the world, to measure how well it worked, how long it took, and how much it would save.
Then I did an analysis of the Akamai logs to figure out how much money we were spending on customers downloading maps, how long it took, where they were downloading them from, and how much money BitTorrent DNA would save us.
For example, Australia would have really benefited, because their connection to the outside world and Akamai coverage was terrible, but their internal connection speed and bandwidth was excellent, and everybody in Australia wants the Australia map, of course.
It turned out that BitTorrent would save TomTom about a million euros the first year, and more each year, since TomTom was distributing larger and larger maps, more frequently by subscription, and of course they hoped to get more customers over time. (See: http://www.sadtrombone.com ...)
But then all of a sudden, out of the blue, Akamai unilaterally lowered the prices they were charging TomTom, saving us a lot of money immediately, presumably to prevent us from switching to BitTorrent (after I had made a bit of a scene at Akamai's GDC booth, in front Travis Kalanick and their sales people, about just having talked Bran Cohen and acquired a quote and beta testing agreement from BitTorrent, and insisted that Akamai tell me what their prices were and when we could start testing -- that may have motivated them to unilaterally lower their prices).
So in the end, TomTom middle management decided to can the BitTorrent project, in spite of the fact that it was the TomTom founder Pieter Geelen's idea in the first place, and he'd been micromanaging the entire project and user interface all along, to make sure it would not just save us money, but also not have a negative impact on usability or customer perception.
There are some important non-technical issues to deal with that Pieter wanted to get right: making it easy to use, setting the defaults right, explaining what it is, getting consent from customers to use their upload bandwidth (since they may have to pay for it, have an upload cap, or want to use it for other ahem purposes), and clearly explaining what benefits customers get from it (not leaving the impression that it's just to benefit TomTom financially, at the expense of the customer), and revealing the possible costs and risks.
We put a lot of effort into that part of it, and I don't think it was going to be a problem. It seems to have worked out all right for WoW and Spotify (in retrospect, up to now).
It was disappointing that TomTom didn't use BitTorrent, but I can certainly understand Akamai's mortal fear of it, and I'm still skeptical that Akamai may have bought it just to sweep it under the rug so they didn't have to compete with it, and didn't really mean to roll it out practically and economically, and develop it to its full potential.
Years later, Akamai now has something called "Akamai NetSession", that may or may not be related to Red Swoosh -- I don't know much about it or how much it costs. Can anyone else comment on that, please? [5]
BitTorrent between TomTom (i.e. mobile) devices? Sounds like a terrible idea. Am I missing something? Users pay good money for upload bandwidth. Far more per megabyte than TomTom would pay to use an ordinary CDN.
DonHopkins on June 9, 2019 | parent [–]
Oh no, not on the device, but the desktop computer you plug it into via USB. So it can download maps while the device isn't connected, over your home internet connection (but probably not your phone), overnight or whenever.
Yes, it was not appropriate for situations where you had to pay for upload bandwidth. We were very careful in designing the gui to disclose the fact that it would use your upload bandwidth, explain the possible costs and benefits, let users opt-in if that was ok with them, monitor the download status, and switch the BitTorrent feature on and off.
TomTom real time traffic prediction system depends on users trusting them enough to opt-in to uploading anonymized trip measurements, so it was very important not to do something that broke their trust by abusing their network connection.
TomTom had an "iTunes-like" desktop content management and device control desktop app called TomTom Home, which was implemented in xulrunner (the underlying framework of Firefox and Thunderbird, kind of a predecessor to Electron for writing cross platform desktop apps in JavaScript with C++ XP/COM plugins).
The first thing I tried was to make an XP/COM plugin out of the LibTorrent library. That worked ok, but the idea of increasing the size and complexity of what was already essentially a web browser with a whole bunch more complex code that does lots of memory allocation and networking all the time, didn't seem like a good design. This was long before Firefox supported multiple processes, so the same app handing bittorrent would bloat the app and degrade the user interface responsiveness.
However RedSwoosh, FoxTorrent and BitTorrent DNA all ran in separate processes that just handled all the BitTorrent stuff, and that you could talk to via https (to stream the file with a special url, and retrieve progress telemetry on another url). And it's incredibly easy to integrate xulrunner or any web browser with those servers via http, so no C++ XP/COM plugin required.
Another issue is that you don't want every application to have its own BitTorrent client built in, or you will trash the network and disk, since otherwise they would compete for resources. It needs to be a centralized a system service, shared by any app that needs it.
BitTorrent DNA worked nicely that way. And it could fall back to the CDN to download at full speed if there weren't enough seeders.
MaxBarraclough on June 9, 2019 | root | parent [–]
> not on the device, but the desktop computer you plug it into via USB
Gotcha.
P2P-with-failover-to-CDN is what Spotify famously used to do.
DHT/torrents and AI have been on a collision course for the last 20 years. Sometimes the correct answer is the simplest one. Except the stakes are much higher now with the power struggle over frontier models.
> Movies are different. Search for a movie on a torrent site and you'll see 4K remux, 1080p, 720p [...]. But no one downloads models like this: anyone who wants DeepSeek-V4.1-Flash-1017 wants the same 48 shards.
But this is exactly the situation for AI models as well. If you look for DeepSeek-V4.1-Flash-1017 or Qwen3.8-27B on HuggingFace, you'll see many different releases by various people with different quantizations like FP8, Q4_K_M, INT4, abliterated/uncensored models and various versions that are fined tuned or modded in whichever different way. It feels to me exactly like the various different video encodings.
Yes, there is usually a single, official release from the lab that produced the model (or sometimes a handful of different variants), but very frequently this isn't something you can even run on consumer hardware.
It's useful only for people that actually do the quantisation or research.
End user will never need pirateface.
not true
many end users would suffer if a low parameter count Qwen got taken down from huggingface because of government regulation
Very few users will end up downloading the base model straight from the lab, chief reason being they can't actually use it for inference on consumer hardware. We will end of with the same scenario described for films where lots of competing providers for different quantisations and fine-tunes will dilute the swarm. I can only assume this was written from the perspective of a developer/researcher?
People are much more likely to need a specific model version than a specific movie version. It's obviously true no matter how you slice it
Torrent always made more sense for distributing large static files like models especially ones where specific ones suddenly become popular and need scaling. Huggingface is incentivised to not do that though to keep control.
Wish they'd at least gone for a hybrid approach
The main currency the platform has with investors and model creators is download stats. If they hand seeding over to DHT that basically means giving up transparent analytics on purpose and they don't need that.
it makes WAY more sense than distributing through one privately owned server
I feel like if Bittorrent shipped in the browser, either embedded or as an extension and just ran on it's own accord, managing the download and throttling upload & download speed based on my current usage and needs without a lot of tweaking and configuration setup, that would be fine. I know most browsers tried this and gave up on it years ago. But, I'd rather not manage a separate program, having to fiddle with settings and open ports and have it always running in the background using a lot of ram/cpu, it's just a hassle.
But, are big CDNs really struggling to manage people downloading 500+gb models? Is AWS/Cloudflare/Akamai/etc begging for p2p hosting again?
I think it's more about getting ahead of open weight model controls
https://webtorrent.io/
Building BitTorrent into the browser is a bad design. I tried and measured it. It makes the browser even more bloated and busy and less responsive and vulnerable to crashing than it currently is, which is a leap in the wrong direction.
It's much better to run just one BitTorrent client as a separate process, a system service that all other programs can share and access via local http (through a data channel configured by url parameters, and optionally a control channel for monitoring and on-the-fly configuration), not built in and tied to one particular app like the web browser.
That's how Red Swoosh and Bittorrent DNA worked: They acted like a local web server, and any web client could simply open a url and start downloading the content, which would be delivered as it was received. BitTorrent DNA had an option of trying to download the chunks in order as much as possible, so it was better for watching streaming video. But they were competing products, you would not want to run both at once.
The point is that every app knows how to fetch files via http, and doesn't need to know a thing about BitTorrent. So the Red Swoosh or BitTorrent DNA service makes BitTorrent look like http, and you don't have to modify the web browser or link in any native libraries or bloat and degrade any apps.
Akamai acqui-hired Travis Kalanick (yeah that insufferable überbro) and his Red Swoosh app because it was a threat to them, to keep it from cutting into their profits, and unilaterally lowered their prices for TomTom to keep us from using BitTorrent DNA instead.
This is why most web browser tried and abandoned the embedded approach years ago, and why AWS/Cloudflare/Akamai/etc loath to support p2p hosting:
https://news.ycombinator.com/item?id=7601083
DonHopkins on April 16, 2014 | parent | context | favorite | on: Spotify Starts Shutting Down Its Massive P2P Netwo...
When I worked for TomTom, I developed and tested a system for distributing maps via BitTorrent.
I first looked at Red Swoosh and its Firefox extension, FoxTorrent. It would have been ideal, since we using the xulrunner platform for TomTom Home, but Akamai acquired Red Swoosh, and it vanished without a trace. [1] [2] [3] [4]
TomTom's Maps are perfect for BitTorrent distribution, because they're large (1 Gig and growing) and lots of people in the same region need to download the same map at the same time. And it would have been a wonderful legal and practical example of a legitimate use of BitTorrent to point to when companies like Comcast try tricks like blocking BitTorrent traffic.
I visited BitTorrent in San Francisco, and discussed it with Bram Cohen. Their technology seemed ideal for our purposes (it worked a bit like Red Swoosh / FoxTorrent), and they quoted me a price per gigabyte to distribute content over their BitTorrent DNA network, which was a hell of a lot cheaper than we were paying to Akamai (this was before the made BitTorrent DNA distribution free).
A couple days after that meeting, I stopped by the Akamai booth at the Game Developer Conference in San Francisco, and asked them what their prices were for using the Red Swoosh technology they'd recently acquired. Travis Kalanick, the founder of Red Swoosh, gladly told me about his technology and answered my technical questions. (I had previously been looking at Red Swoosh and FoxTorrent, before it was acquired by Akamai, and it would have been easy to integrate with our xulrunner based product, TomTom Home).
Akamai's sales people refused to quote me a price, despite repeated requests, so I told them the price BitTorrent quoted me, and told them we were ready to start testing as soon as possible, and asked again if they could at least give me a ballpark estimate of how much they would charge for distributing content via Red Swoosh, and when we could start testing. They muttered something about not having come up with a pricing model yet, but that I could get into their beta program, whenever that started, which they also would not state.
I was somewhat skeptical about Akamai's support for Red Swoosh, dedication to P2P technologies, and motivations for acquiring Red Swoosh, since P2P technologies are such a huge threat to their business model. It was getting a lot of attention before they acquired it. I was afraid that they might have just acqui-hired Red Swoosh simply to sweep it under the rug so they didn't have to compete with it. And I was afraid that if and when they finally figured out how to charge for it, it might not be such a great deal after all.
So I went back to Amsterdam, integrated BitTorrent DNA into TomTom Home (the desktop app for managing content and downloading maps on your TomTom device, like iTunes for TomToms instead of iPods, which happened to be implemented on xulrunner (the Mozilla "platform" that Firefox and TomTom Home are build on top of -- which Mozilla eventually lost interest in supporting as a third party application development platform).
It was easy to integrate BitTorrent DNA into TomTom Home, it worked well, and I performed a successful beta test with a bunch of users across the world, to measure how well it worked, how long it took, and how much it would save.
Then I did an analysis of the Akamai logs to figure out how much money we were spending on customers downloading maps, how long it took, where they were downloading them from, and how much money BitTorrent DNA would save us.
For example, Australia would have really benefited, because their connection to the outside world and Akamai coverage was terrible, but their internal connection speed and bandwidth was excellent, and everybody in Australia wants the Australia map, of course.
It turned out that BitTorrent would save TomTom about a million euros the first year, and more each year, since TomTom was distributing larger and larger maps, more frequently by subscription, and of course they hoped to get more customers over time. (See: http://www.sadtrombone.com ...)
But then all of a sudden, out of the blue, Akamai unilaterally lowered the prices they were charging TomTom, saving us a lot of money immediately, presumably to prevent us from switching to BitTorrent (after I had made a bit of a scene at Akamai's GDC booth, in front Travis Kalanick and their sales people, about just having talked Bran Cohen and acquired a quote and beta testing agreement from BitTorrent, and insisted that Akamai tell me what their prices were and when we could start testing -- that may have motivated them to unilaterally lower their prices).
So in the end, TomTom middle management decided to can the BitTorrent project, in spite of the fact that it was the TomTom founder Pieter Geelen's idea in the first place, and he'd been micromanaging the entire project and user interface all along, to make sure it would not just save us money, but also not have a negative impact on usability or customer perception.
There are some important non-technical issues to deal with that Pieter wanted to get right: making it easy to use, setting the defaults right, explaining what it is, getting consent from customers to use their upload bandwidth (since they may have to pay for it, have an upload cap, or want to use it for other ahem purposes), and clearly explaining what benefits customers get from it (not leaving the impression that it's just to benefit TomTom financially, at the expense of the customer), and revealing the possible costs and risks.
We put a lot of effort into that part of it, and I don't think it was going to be a problem. It seems to have worked out all right for WoW and Spotify (in retrospect, up to now).
It was disappointing that TomTom didn't use BitTorrent, but I can certainly understand Akamai's mortal fear of it, and I'm still skeptical that Akamai may have bought it just to sweep it under the rug so they didn't have to compete with it, and didn't really mean to roll it out practically and economically, and develop it to its full potential.
Years later, Akamai now has something called "Akamai NetSession", that may or may not be related to Red Swoosh -- I don't know much about it or how much it costs. Can anyone else comment on that, please? [5]
[1] https://en.wikipedia.org/wiki/RedSwoosh
[2] http://www.akamai.com/html/about/press/releases/2007/press_0...
[3] http://gigaom.com/2008/05/03/whatever-happened-to-red-swoosh...
[4] http://techcrunch.com/2007/04/12/payday-for-red-swoosh-15-mi...
[5] http://www.akamai.com/client
https://news.ycombinator.com/item?id=20140349
DonHopkins on June 9, 2019 | parent | context | favorite | on: AWS costs every programmer should know
One way to get Akamai to unilaterally lower their bandwidth prices is to threaten to use BitTorrent instead.
https://news.ycombinator.com/item?id=7601083
MaxBarraclough on June 9, 2019 [–]
BitTorrent between TomTom (i.e. mobile) devices? Sounds like a terrible idea. Am I missing something? Users pay good money for upload bandwidth. Far more per megabyte than TomTom would pay to use an ordinary CDN.
DonHopkins on June 9, 2019 | parent [–]
Oh no, not on the device, but the desktop computer you plug it into via USB. So it can download maps while the device isn't connected, over your home internet connection (but probably not your phone), overnight or whenever.
Yes, it was not appropriate for situations where you had to pay for upload bandwidth. We were very careful in designing the gui to disclose the fact that it would use your upload bandwidth, explain the possible costs and benefits, let users opt-in if that was ok with them, monitor the download status, and switch the BitTorrent feature on and off.
TomTom real time traffic prediction system depends on users trusting them enough to opt-in to uploading anonymized trip measurements, so it was very important not to do something that broke their trust by abusing their network connection.
https://web.archive.org/web/20160917081636/https://www.tomto...
TomTom had an "iTunes-like" desktop content management and device control desktop app called TomTom Home, which was implemented in xulrunner (the underlying framework of Firefox and Thunderbird, kind of a predecessor to Electron for writing cross platform desktop apps in JavaScript with C++ XP/COM plugins).
The first thing I tried was to make an XP/COM plugin out of the LibTorrent library. That worked ok, but the idea of increasing the size and complexity of what was already essentially a web browser with a whole bunch more complex code that does lots of memory allocation and networking all the time, didn't seem like a good design. This was long before Firefox supported multiple processes, so the same app handing bittorrent would bloat the app and degrade the user interface responsiveness.
However RedSwoosh, FoxTorrent and BitTorrent DNA all ran in separate processes that just handled all the BitTorrent stuff, and that you could talk to via https (to stream the file with a special url, and retrieve progress telemetry on another url). And it's incredibly easy to integrate xulrunner or any web browser with those servers via http, so no C++ XP/COM plugin required.
Another issue is that you don't want every application to have its own BitTorrent client built in, or you will trash the network and disk, since otherwise they would compete for resources. It needs to be a centralized a system service, shared by any app that needs it.
BitTorrent DNA worked nicely that way. And it could fall back to the CDN to download at full speed if there weren't enough seeders.
MaxBarraclough on June 9, 2019 | root | parent [–]
> not on the device, but the desktop computer you plug it into via USB
Gotcha.
P2P-with-failover-to-CDN is what Spotify famously used to do.
DHT/torrents and AI have been on a collision course for the last 20 years. Sometimes the correct answer is the simplest one. Except the stakes are much higher now with the power struggle over frontier models.
[flagged]
[flagged]
[dead]