> The value of token will appreciate over time whereas the price of storage will keep getting cheaper.
That's not a given, however, and it's not just raw storage but also network bandwidth and operator time which all require regular ongoing payments. Expecting newcomers to pay for the early adopters' storage in perpetuity is tricky because you need high demand for an otherwise useless token but there's a limit on the price for most users in the form of all of the competing options, which are currently faster and more reliable.
> It's simpler than s3 in many aspects so I'm not sure you would need a system administrator. Everyone can run a node and things are replicated many times over. The failover model is to look for the next node. There are no API, security, access, etc consideration to be maintained at the node level.
It's not that simple: anyone running much storage will need to spend time replacing failed drives, managing their bandwidth relative to demand, etc. That time needs to be paid for. Massive replication is necessary to deal with the reduced node reliability but that means the network needs to pay for considerably more storage in total than, say, Amazon does and adds significant scaling issues managing all of those extra nodes with more frequent status changes.
This has been tried a number of times before and it always founders due to being slower and less reliable, with considerably more complicated software required to deal with all of those issues which the competitors don't have. It's possible that this will be more successful but I think it's really important to look at how the market pressures have consistently gone in the other direction. Amazon didn't end up with exabytes of storage in S3 because it started there — people migrated their data there because it was faster, cheaper, and easier to have it there — and that is a competitive challenge for a replacement trying to build on nodes which aren't maintained with comparable levels of service.
Thanks — I’m trying to keep an open mind here but it often feels like there’s a lot of history which people could benefit from. I’m not terribly old but I’ve seen a few iterations of these ideas crash on the {freeloader,abuse} rocks so I’ve been reconsidering whether my earlier enthusiasm was more a mirage than practical.
That's not a given, however, and it's not just raw storage but also network bandwidth and operator time which all require regular ongoing payments. Expecting newcomers to pay for the early adopters' storage in perpetuity is tricky because you need high demand for an otherwise useless token but there's a limit on the price for most users in the form of all of the competing options, which are currently faster and more reliable.
> It's simpler than s3 in many aspects so I'm not sure you would need a system administrator. Everyone can run a node and things are replicated many times over. The failover model is to look for the next node. There are no API, security, access, etc consideration to be maintained at the node level.
It's not that simple: anyone running much storage will need to spend time replacing failed drives, managing their bandwidth relative to demand, etc. That time needs to be paid for. Massive replication is necessary to deal with the reduced node reliability but that means the network needs to pay for considerably more storage in total than, say, Amazon does and adds significant scaling issues managing all of those extra nodes with more frequent status changes.
This has been tried a number of times before and it always founders due to being slower and less reliable, with considerably more complicated software required to deal with all of those issues which the competitors don't have. It's possible that this will be more successful but I think it's really important to look at how the market pressures have consistently gone in the other direction. Amazon didn't end up with exabytes of storage in S3 because it started there — people migrated their data there because it was faster, cheaper, and easier to have it there — and that is a competitive challenge for a replacement trying to build on nodes which aren't maintained with comparable levels of service.