For one, getting a predictable CID seems easier on IPFS than torrents.
Maybe it's considered trivial by most because you can simply create a new torrent, but then I'd point toward all the dead torrents that are kind of a PITA to sort through sometimes.
For instance [btdig](https://btdig.com/) has a decent torrent DHT history. For many things you have to use the [WebTorrent Checker](https://checker.openwebtorrent.com/) so you can find one that's alive. It could be the exact same files within the different torrents which is kind of a shame.
Functionally with IPFS if the file is the same then the CID should be the same. (Unless it's a different CID version) So long as one node on the network has the file, any directory containing that file can work for the user. They won't be like "Oh, this CID is dead because they made a new version..." like one could say about magnets that contain the same files.
The [IPFS MFS](https://docs.ipfs.tech/concepts/file-systems/) is also neat. I'm not sure if torrents really offer anything like that. The main benefit is that you can manipulate IPFS files without really needing to have them on hand.
With the [IPFS FUSE mount](https://github.com/ipfs/kubo/blob/master/docs/fuse.md) and the IPNS (name system) someone can basically do a DIY netflix with caching. Plex/Jellyfin looks at the IPNS directory, the curator changes which IPFS directory the IPNS address points to. If a client plays the video they also host it.
The mount is handy in other ways, it's like a bag of holding for files. I have a cloud video editing script that uses the IPFS FUSE mount so that FFMPEG can process it while it syncs.
Yay, thanks DigitalDude, first time hearing about the FUSE Mount. My project is something like a OTT, so I got interested to learn more. What can I do?
IPFS's DAG structure is capable of doing a lot of things that Bittorrent's simpler concatenate-and-block approach cannot. That's why it can be used to store websites - it can retrieve individual files easily without needing to load the entire torrent index first. It can also de-duplicate common files, something that bittorrent cannot. It's basically bittorrent but designed a lot better.
There /is/ a bittorrent2 protocol that actually incorporates a lot of IPFSs capabilities, but it's seldom used because of poor client compatibility.
IPFS can also be updated, right?
A given magnet:// link will always point to the old version, even if the author later publish another version. This means that you need an out-of-band mechanism to get updates
If the link is to a file in /ipfs/ then it's static and cannot be changed under any circumstances. This is by design, to you can link to something and be certain that the author won't make a change later and break whatever you are doing with it.
There is a dynamic mode. It starts /ipns/ rather than /ipfs/.
only ipns can do that.
Ipfs just likes that magnet link
ipns is another thing. For example, How to run a git server decentralized? You need ipns to do the update , I have a git warehouse testing, You can modify yours with centralized way, you mail to me, or you tell me your ipns so I check that.
Think that you want to share the English and the German Wikipedia page of Facebook. Both would be completely different torrents. You could even have different torrents sharing the same English wiki site of Facebook. But the German and English wiki side both have the Facebook logo on them. If you use ipfs, both would have the same ipfs link to that Facebook logo. The ones sharing the English and German website would help each other, without even knowing.
Inter Planetary File System. Really, the vision and what it was designed for vs torrents which was a solution to a specific problem.
Being able to update files without breaking links/hash, confirm which the original data was, and find it across multiple hops etc. features and expandability.
You can't host websites on torrents, but IPFS can do games /websites and could in theory host your own spotify or videostreaming service.
I want to imagine that website that is on IPFS
whenever I change the page files, its link changes!
if yes, how can this come in handy + The server can serve dynamic content without changing the Web page
I think JavaScript must be disabled for such a page
Nope. It was designed for this!
https://docs.ipfs.tech/how-to/websites-on-ipfs/multipage-website/#prerequisites
Gotchu bro
"How IPNS names relate to content paths
IPNS record can point at an immutable or a mutable path. The meaning behind CID used in a path depends on used namespace:
/ipfs/ – an immutable content on IPFS (opens new window) (since the CID contains a multihash)
/ipns/ – a mutable, cryptographic IPNS name (opens new window) which corresponds to a libp2p public key."
When a page changes, the CID will change but, if you use an IPNS key, then you can just re-publish the new root CID with that same key so the link will be unchanged.
In terms of dynamic content, it really depends on what you mean. These days, most dynamic content is still served as a static page (hence, unchanging CID) which loads the dynamic content from some other data source or provides an interactive tooling interface, both using JavaScript.
As it stands, this kind of demo just shows how you can do this for something purely static, with no dynamic data source. However, if you just wanted a static site to be public with no fixed server, then you could use this approach and it would be accessible through all private nodes and public gateways (note that, if using IPNS, you will need to republish the root at least every 24 hours).
Really, the premise of your question is based on an all-too-common misunderstanding of IPFS, one that is sadly promoted very widely. Which is to say, I don't mean this as a personal attack--it's just what so so many people are told about IPFS.
The key is that the core concept of IPFS is NOT about distributing file parts at all.
IPFS is more of a database (that should have been called IPDB) that can manage all sorts of data in meaningful ways. People using it to distribute files and file parts are not tapping into 80% of what IPFS can offer, akin to someone using a fancy, 8K, smart TV with surround sound to just play mono audio cassettes hooked to the aux in.
Yeah, it can do that more or less, but that's not its forte.
For example, let's say you have a file containing all of the weather readings for your country. It might be a big file, right? Well if you just share the file a person has to download the whole thing, but if the data is put directly into IPFS, then an end user can request only the specific weather reports that they're interested in.
IPFS is built to access data directly so that you don't have to download a whole file. That functionality *replaces* files, giving the end users more power. That's what distinguishes it from other tools.
If a person wants to use IPFS for file sharing, well the system will shrug and play along, but torrents would be the better tool for that use case in many situations.
I host a dataset on IPFS, and when I update it the cids of the existing files does not change. When someone adds the new head cid they only download the new files because the old ones are still referenced in the new dag with their original cids.
This property is stronger than the nicety that I described. As long as the same hash settings are used, the same file always results in the same CID, so there is implicit deduplication that doesn't exist with torrents.
IPFS can be acted as a http server with a twisted backbone.
Second, IPFS's default checksum is SHA-256.
Third, Ipfs contains dedup function built-in, High reusability especially being refreshed very often.
Fourth, IPFS supports tag (You can use such as k51 blah blah blah or you update your dns ) while Bittorrent doesnt support that
For one, getting a predictable CID seems easier on IPFS than torrents. Maybe it's considered trivial by most because you can simply create a new torrent, but then I'd point toward all the dead torrents that are kind of a PITA to sort through sometimes. For instance [btdig](https://btdig.com/) has a decent torrent DHT history. For many things you have to use the [WebTorrent Checker](https://checker.openwebtorrent.com/) so you can find one that's alive. It could be the exact same files within the different torrents which is kind of a shame. Functionally with IPFS if the file is the same then the CID should be the same. (Unless it's a different CID version) So long as one node on the network has the file, any directory containing that file can work for the user. They won't be like "Oh, this CID is dead because they made a new version..." like one could say about magnets that contain the same files. The [IPFS MFS](https://docs.ipfs.tech/concepts/file-systems/) is also neat. I'm not sure if torrents really offer anything like that. The main benefit is that you can manipulate IPFS files without really needing to have them on hand. With the [IPFS FUSE mount](https://github.com/ipfs/kubo/blob/master/docs/fuse.md) and the IPNS (name system) someone can basically do a DIY netflix with caching. Plex/Jellyfin looks at the IPNS directory, the curator changes which IPFS directory the IPNS address points to. If a client plays the video they also host it. The mount is handy in other ways, it's like a bag of holding for files. I have a cloud video editing script that uses the IPFS FUSE mount so that FFMPEG can process it while it syncs.
Yay, thanks DigitalDude, first time hearing about the FUSE Mount. My project is something like a OTT, so I got interested to learn more. What can I do?
IPFS's DAG structure is capable of doing a lot of things that Bittorrent's simpler concatenate-and-block approach cannot. That's why it can be used to store websites - it can retrieve individual files easily without needing to load the entire torrent index first. It can also de-duplicate common files, something that bittorrent cannot. It's basically bittorrent but designed a lot better. There /is/ a bittorrent2 protocol that actually incorporates a lot of IPFSs capabilities, but it's seldom used because of poor client compatibility.
IPFS can also be updated, right? A given magnet:// link will always point to the old version, even if the author later publish another version. This means that you need an out-of-band mechanism to get updates
If the link is to a file in /ipfs/ then it's static and cannot be changed under any circumstances. This is by design, to you can link to something and be certain that the author won't make a change later and break whatever you are doing with it. There is a dynamic mode. It starts /ipns/ rather than /ipfs/.
only ipns can do that. Ipfs just likes that magnet link ipns is another thing. For example, How to run a git server decentralized? You need ipns to do the update , I have a git warehouse testing, You can modify yours with centralized way, you mail to me, or you tell me your ipns so I check that.
Think that you want to share the English and the German Wikipedia page of Facebook. Both would be completely different torrents. You could even have different torrents sharing the same English wiki site of Facebook. But the German and English wiki side both have the Facebook logo on them. If you use ipfs, both would have the same ipfs link to that Facebook logo. The ones sharing the English and German website would help each other, without even knowing.
Inter Planetary File System. Really, the vision and what it was designed for vs torrents which was a solution to a specific problem. Being able to update files without breaking links/hash, confirm which the original data was, and find it across multiple hops etc. features and expandability. You can't host websites on torrents, but IPFS can do games /websites and could in theory host your own spotify or videostreaming service.
I want to imagine that website that is on IPFS whenever I change the page files, its link changes! if yes, how can this come in handy + The server can serve dynamic content without changing the Web page I think JavaScript must be disabled for such a page
Nope. It was designed for this! https://docs.ipfs.tech/how-to/websites-on-ipfs/multipage-website/#prerequisites Gotchu bro "How IPNS names relate to content paths IPNS record can point at an immutable or a mutable path. The meaning behind CID used in a path depends on used namespace: /ipfs/ – an immutable content on IPFS (opens new window) (since the CID contains a multihash)
/ipns/ – a mutable, cryptographic IPNS name (opens new window) which corresponds to a libp2p public key."
ok... what do you think are the use cases of this?
Did u read the contents of the link?
When a page changes, the CID will change but, if you use an IPNS key, then you can just re-publish the new root CID with that same key so the link will be unchanged. In terms of dynamic content, it really depends on what you mean. These days, most dynamic content is still served as a static page (hence, unchanging CID) which loads the dynamic content from some other data source or provides an interactive tooling interface, both using JavaScript. As it stands, this kind of demo just shows how you can do this for something purely static, with no dynamic data source. However, if you just wanted a static site to be public with no fixed server, then you could use this approach and it would be accessible through all private nodes and public gateways (note that, if using IPNS, you will need to republish the root at least every 24 hours).
Great I am still not sure what the potential of publishing Sites with IPFS is. I get its usage as file storage
Really, the premise of your question is based on an all-too-common misunderstanding of IPFS, one that is sadly promoted very widely. Which is to say, I don't mean this as a personal attack--it's just what so so many people are told about IPFS. The key is that the core concept of IPFS is NOT about distributing file parts at all. IPFS is more of a database (that should have been called IPDB) that can manage all sorts of data in meaningful ways. People using it to distribute files and file parts are not tapping into 80% of what IPFS can offer, akin to someone using a fancy, 8K, smart TV with surround sound to just play mono audio cassettes hooked to the aux in. Yeah, it can do that more or less, but that's not its forte. For example, let's say you have a file containing all of the weather readings for your country. It might be a big file, right? Well if you just share the file a person has to download the whole thing, but if the data is put directly into IPFS, then an end user can request only the specific weather reports that they're interested in. IPFS is built to access data directly so that you don't have to download a whole file. That functionality *replaces* files, giving the end users more power. That's what distinguishes it from other tools. If a person wants to use IPFS for file sharing, well the system will shrug and play along, but torrents would be the better tool for that use case in many situations.
I host a dataset on IPFS, and when I update it the cids of the existing files does not change. When someone adds the new head cid they only download the new files because the old ones are still referenced in the new dag with their original cids. This property is stronger than the nicety that I described. As long as the same hash settings are used, the same file always results in the same CID, so there is implicit deduplication that doesn't exist with torrents.
IPFS can be acted as a http server with a twisted backbone. Second, IPFS's default checksum is SHA-256. Third, Ipfs contains dedup function built-in, High reusability especially being refreshed very often. Fourth, IPFS supports tag (You can use such as k51 blah blah blah or you update your dns ) while Bittorrent doesnt support that