3 ms·

IPFS doesn't give you any guarantees about if the content is actually stored anywhere, it however gives you reasonable guarantees that the addresses for that co

IPFS doesn't give you any guarantees about if the content is actually stored anywhere, it however gives you reasonable guarantees that the addresses for that content stay the same. Meaning if somebody finds an old backup tape decades down the road, they can just stuff it back onto IPFS and all the dead links start functioning again. That's something that is impossible with HTTP, as there isn't even a guarantee that the same URL will return the same content when you access it twice. With IPFS anybody can mirror the content and keep it alive as long as they want, they don't have to hope that the server that hosts it right now keeps running. That said, IPFS isn't quite perfect here, as IPFS hashes do not actually point to the content itself, they point to a package that contains the content and depending on how that package was build, the hash will change.

fabianhjr 5y ago
One of the spinouts of IPFS is Multiformats, particularly multihashes. It is a standard to describe hashes and provide interop: https://multiformats.io/multihash/ https://multiformats.io/multihash/ (Or the IPNS dnslink: http://multiformats.io.ipns.localhost:8080/multihash/ http://multiformats.io.ipns.localhost:8080/multihash/ )
- zozbot234 5y ago
  Seems like this pointlessly duplicates the "Naming things with hashes" ni: and nih: URI schemes, standardised as https://tools.ietf.org/html/rfc6920 https://tools.ietf.org/html/rfc6920 . (IPFS actually uses a proprietary "package" representation as parent points out, so there's little harm in it not using ni: URI's. But standard hashes of the underlying resource should use those. "Magnet" links are similarly problematic, but these at least support a few convenience features.)
  - warkdarrior 5y ago
    > Seems like this pointlessly duplicates the "Naming things with hashes" ni: and nih: URI schemes Wow, they have an URI scheme for Not Invented Here. Amazing!
hannasanarion 5y ago
That still requires you to deliberately decide to archive a certain page, which you can do just as easily with http. The SingleFile browser extension will grab everything that's linked to a page and build a locally stored directory with all the dependencies of that page.
- grumbel 5y ago
  > That still requires you to deliberately decide to archive a certain page You don't "archive" a page with IPFS, with IPFS everything you keep a copy of stays available under the same address, that either happens automatically via cache or via a manual 'pin'. That's fundamentally different than what HTTP does. The archive copy you create of a HTTP site is your own personal copy and completely inaccessible to anybody else. Even if you put it online, people would have no clue where to find it. With IPFS the document never leaves the address space and stays accessible to everybody under the same address, no matter who decides to host it. Another important practical difference is that IPFS has native support for directories, so you don't have to try to spider around to try to guess all the URLs, you can just grab the whole directory at once. That in turn also has the nice side effect that .zip archives essentially become irrelevant, as you can just upload the directory itself.

fabianhjr 5y ago

One of the spinouts of IPFS is Multiformats, particularly multihashes. It is a standard to describe hashes and provide interop: https://multiformats.io/multihash/ https://multiformats.io/multihash/ (Or the IPNS dnslink: http://multiformats.io.ipns.localhost:8080/multihash/ http://multiformats.io.ipns.localhost:8080/multihash/ )

zozbot234 5y ago
Seems like this pointlessly duplicates the "Naming things with hashes" ni: and nih: URI schemes, standardised as https://tools.ietf.org/html/rfc6920 https://tools.ietf.org/html/rfc6920 . (IPFS actually uses a proprietary "package" representation as parent points out, so there's little harm in it not using ni: URI's. But standard hashes of the underlying resource should use those. "Magnet" links are similarly problematic, but these at least support a few convenience features.)
- warkdarrior 5y ago
  > Seems like this pointlessly duplicates the "Naming things with hashes" ni: and nih: URI schemes Wow, they have an URI scheme for Not Invented Here. Amazing!

hannasanarion 5y ago

That still requires you to deliberately decide to archive a certain page, which you can do just as easily with http. The SingleFile browser extension will grab everything that's linked to a page and build a locally stored directory with all the dependencies of that page.

grumbel 5y ago
> That still requires you to deliberately decide to archive a certain page You don't "archive" a page with IPFS, with IPFS everything you keep a copy of stays available under the same address, that either happens automatically via cache or via a manual 'pin'. That's fundamentally different than what HTTP does. The archive copy you create of a HTTP site is your own personal copy and completely inaccessible to anybody else. Even if you put it online, people would have no clue where to find it. With IPFS the document never leaves the address space and stays accessible to everybody under the same address, no matter who decides to host it. Another important practical difference is that IPFS has native support for directories, so you don't have to try to spider around to try to guess all the URLs, you can just grab the whole directory at once. That in turn also has the nice side effect that .zip archives essentially become irrelevant, as you can just upload the directory itself.