6 ms·

> As long as there is a single party interested in content hosted on IPFS, the "IPFS Network" will persist. I imagine that's one of the reasons why it's not id

by snsr 9y ago

> As long as there is a single party interested in content hosted on IPFS, the "IPFS Network" will persist. I imagine that's one of the reasons why it's not ideal for archival content.

roblabla 9y ago
I don't get why ? It's exactly the same today : you need at least one party to host the data (in this case the archive team). With IPFS however, if more parties wish to host it, it will lighten the load.
- tscs37 9y ago
  There is no incentive to keep data in the network. You can pay pinning services, but what's the point if you're just going to pay someone hosting it? I'd rather have this archived on Siacoin, Storj, Swarm or any other distributed network with actual incentives to keep things around
  - mmjaa 9y ago
    IPFS+Ethereum = incentive. Please do not be so flippant to reject something until you've grok'ed it sufficiently well enough to argue against it. If you have looked at IPFS+Ethereum and found it wanting, I'd love to know what exactly - because from my perspective this is precisely the kind of technology that delivers your stated requirements.
    - tscs37 9y ago
      I've definitely "grok'ed" it. Which is why I find Swarm a better solution. It is literally IPFS+Ethereum with additional support for ENS lookups, deniable storage, redundant storage, etc. This allows for far better privacy and being able to compensate the loss of parts of the file, both features lacking in IPFS itself. The current swarm testnet performs, as per my experience, better than IPFS in terms of bandwidth and latency. http://swarm-gateways.net/bzz:/theswarm.eth/ http://swarm-gateways.net/bzz:/theswarm.eth/
e12e 9y ago
I think ipfs is very interesting, and will hopefully evolve to become a viable archive solution - but that'll only happen once you have a few serious organizations running their own redundant ipfs "intranet" storage networks, with geographical redundancy (or at least good local availability). Then we might see "archive peering" between such organizations. The time horizon of "archival storage" probably starts at a hundred years - that will need some structure to have a likelihood of persisting for so long.
- cyphar 9y ago
  > The time horizon of "archival storage" probably starts at a hundred years - that will need some structure to have a likelihood of persisting for so long. This reminds me of one of the principles of camlistore's data schema, which explicitly says that they made their schemas overly-explicit so that future digital archeologists can re-create the schema purely from examples[1]. It's a shame that camlistore feels more like a very long experiment over a polished and usable backup/archive system. [1]: https://camlistore.org/doc/principles https://camlistore.org/doc/principles ; There used to be a more explicit explanation, but I couldn't find it.

by snsr 9y ago

> As long as there is a single party interested in content hosted on IPFS, the "IPFS Network" will persist. I imagine that's one of the reasons why it's not ideal for archival content.

roblabla 9y ago

I don't get why ? It's exactly the same today : you need at least one party to host the data (in this case the archive team). With IPFS however, if more parties wish to host it, it will lighten the load.

tscs37 9y ago
There is no incentive to keep data in the network. You can pay pinning services, but what's the point if you're just going to pay someone hosting it? I'd rather have this archived on Siacoin, Storj, Swarm or any other distributed network with actual incentives to keep things around
- mmjaa 9y ago
  IPFS+Ethereum = incentive. Please do not be so flippant to reject something until you've grok'ed it sufficiently well enough to argue against it. If you have looked at IPFS+Ethereum and found it wanting, I'd love to know what exactly - because from my perspective this is precisely the kind of technology that delivers your stated requirements.
  - tscs37 9y ago
    I've definitely "grok'ed" it. Which is why I find Swarm a better solution. It is literally IPFS+Ethereum with additional support for ENS lookups, deniable storage, redundant storage, etc. This allows for far better privacy and being able to compensate the loss of parts of the file, both features lacking in IPFS itself. The current swarm testnet performs, as per my experience, better than IPFS in terms of bandwidth and latency. http://swarm-gateways.net/bzz:/theswarm.eth/ http://swarm-gateways.net/bzz:/theswarm.eth/

e12e 9y ago

I think ipfs is very interesting, and will hopefully evolve to become a viable archive solution - but that'll only happen once you have a few serious organizations running their own redundant ipfs "intranet" storage networks, with geographical redundancy (or at least good local availability). Then we might see "archive peering" between such organizations. The time horizon of "archival storage" probably starts at a hundred years - that will need some structure to have a likelihood of persisting for so long.

cyphar 9y ago
> The time horizon of "archival storage" probably starts at a hundred years - that will need some structure to have a likelihood of persisting for so long. This reminds me of one of the principles of camlistore's data schema, which explicitly says that they made their schemas overly-explicit so that future digital archeologists can re-create the schema purely from examples[1]. It's a shame that camlistore feels more like a very long experiment over a polished and usable backup/archive system. [1]: https://camlistore.org/doc/principles https://camlistore.org/doc/principles ; There used to be a more explicit explanation, but I couldn't find it.