This is effectively what IPFS is, but IPFS takes it to the next level by using the equivalent of torrent files for subdirectories within the mounted torrent files, so you can "traverse" entire networks of the pretty-much-a-torrent files without first having to download and mount them. And like, you could implement similar functionality here by having torrent files that contain files named .torrent have those files be treated as directories, but at that point IPFS is going to be much more feature complete; even like, if you have some giant file, on IPFS that might be represented by trees of hashes as opposed to merely a giant array of hashes so you can incrementally and efficiently access the parts you need. So like, while this is awesome work, if you find it inspiring, maybe channel that inspiration into learning about IPFS and extending that ecosystem, rather than doubling down on trying to build on torrent files.
How is it "doubling down", they could exist side by side. Your comment kind-of shows the mentality I've seen with the IPFS project before. The IPFS project has doubled down on it's effort of being more "advanced", "innovative" and "efficient" than BitTorrent, losing what actually makes people like torrents and distributed systems.
Unfortunately right now the IPFS project is totally ignoring that it's effectively nothing and takes nothing to the next level. I think what I mentioned before, is the root cause. Zero ounce of compatibility with the existing BT swarm. It is simply a massive amount of wasted potential to ignore the thousands of terabytes of content the torrent system hosts, the work and services provided and spent for the ecosystem. So much could be done that would strengthen both systems at the same time. Just from the IPFS point of view we could right now have embedded resources from torrents, tens of different clients available that could just be CDNs, existing seedboxes strengthening both swarms and probably much more.
That would be the mix of torrents and web people want, not what IPFS is currently. IPFS is basically reinventing the wheel, but throwing out the round part.
Maybe the IPFS project should channel more work on building next to giants rather than doubling down and throwing away everything BT has to offer?
To be clear, I am not involved in the IPFS project and in fact don't like key aspects of the project and think it is doomed to long-term failure when it gets replaced by something better.
That said, the core and pretty fundamental limitation with BitTorrent, however, is that the swarms exist "per torrent", which kind of makes a non-starter for a general purpose filesystem?
As such, I don't quite disagree with what you'd like to see done, but that work should go in IPFS... like, trying to extend the way BitTorrent works "up" to something that works for this use case is going to involve a much more fundamental set of low-level changes than even the WebTorrent shift (which is where I'd argue "if only BitTorrent understood the value of working with existing browser-based systems and opening up powerful use cases they would understand that not doing this is like throwing away the round part of a wheel... etc." ;P WebTorrent is the future of BitTorrent as far as I'm concerned, and anything failing to embrace that is already kind of doomed?...) than the other direction, which is really just "go into IPFS and add a little adapter that lets it work with torrent files (at the fundamental loss of efficiency and awkward lack of resource sharing that such usage implies).
The primary difference I see here is that IPFS is rather centralized in terms of development, it is much much easier for them to write a BT compat layer of some sort than it is for the BT community. A core set of BT is really rather ossified thanks to the amount of implementations out there. Just as an example there are quite a few BEPs out there that implement some features that IPFS has, unfortunately those features haven't gotten any mainstream adoption so far.
> That said, the core and pretty fundamental limitation with BitTorrent, however, is that the swarms exist "per torrent", which kind of makes a non-starter for a general purpose filesystem?
Well, ipfs nodes also tend to pin only certain content. I've seen IPFS links stop working mentioned here on HN even. I see no functional difference in that sense. Content is kept available by those willing to spend resources storing and uploading the specific content.
To address the claimed performance/efficiency problems, IPFS peers could share the same files using IPFS itself, but still also seed them for BT clients.
I totally get though that it wouldn't be super easy to implement, but IMHO the increase in IPFS usefulness, size and resiliency thanks to the integration seems to outweigh the downsides I can see.
Though a while ago I did try sharing the same set of files on two systems by running the two in parallel. It kind-of worked but manually updating the file locations in the torrent client and having an overview became too annoying, it should be built-in. E.g. IPFS sees `x.torrent` and `x`, then assumes `x` is downloadable from BT using that torrent file.
> WebTorrent is the future of BitTorrent as far as I'm concerned, and anything failing to embrace that is already kind of doomed?
What are the current best practices for hosting dynamically updated content on IPFS? Something like a blog that gets updated once a day or a Hacker News clone that gets multiple updates per minute. Last time I checked it was DNS, has something changed sice then?
HN is too frequently updated, but for blogs or personal web pages it's okay. You can either use IPNS or update a DNS record each time you update your content. I chose the latter as years of experiences proved it more robust than IPNS (also, my registrar provides a very simple API that I can use to automatically update the appropriate DNS record, so this is done by the same Python script that update my IPFSite).
The downside is that hosting an IPFS node is quite heavy on the network. I have a reasonably good connection at home (a bit less than 1MB/s up, a bit more than 10MB/s down) and if I run the IPFS daemon locally I can't really use my internet connection for anything else. I used to rent a little VPS for that, but now I use the free-tier of temporal.cloud and it is sufficient for my usage.
Something that's as dynamic as HN seems to me like a bad fit for IPFS. A blog seems fine for it; I make my own blog accessible through IPFS.
DNS seems like the best and currently most popular option for letting you have an address with an update-able IPFS link. The nice thing about using DNS is that you can use the same address for people accessing via IPFS and people accessing via standard browsers.
I've had a breif look at IPFS, but not enough to say anything with any amount of confidence. That said, the thing that immediately put me off was that everything seemed to want to be browser based, like starting some service that makes a local web server that acts as a GUI - there was even a chrome extension that tried to make this easy for you.
A feature that might exist, but I haven't discovered, that would make IPFS more appealing to me, would be a way to mount the IPFS like it were an FTP server, and navigate it with whatever file manager you prefer and not have to worry about managing the backend stuff.
Given the other reply to your comment was someone who seriously thinks IPFS's core feature--being able to be used as a filesystem--doesn't exist, I guess I'll have to go with "better onboarding documentation" ;P.
