Is there any sensible study on those system's energy consumption?
Filecoin, StorJ and the problem with decentralized storage (2019)
31–40 of 123 posts
Re: Filecoin, StorJ and the problem with decentralized storage (2019)
#32One important property of decentralized storage is that it prevents data monopolies. For example, if you host your web app on Sia Skynet, then users own their data instead of being locked in by the app developer. It also enables a model where different apps can easily access the same data. The data is in the "cloud", but still owned by the user.
You could implement the same Solid-style model using centralized storage or you could implement lock-in on top of decentralized storage. It's mostly orthogonal.
Re: Filecoin, StorJ and the problem with decentralized storage (2019)
#33One important property of decentralized storage is that it prevents data monopolies. For example, if you host your web app on Sia Skynet, then users own their data instead of being locked in by the app developer. It also enables a model where different apps can easily access the same data. The data is in the "cloud", but still owned by the user.
I think that this paper is more about file storage, not web apps.
And for file storage, there are no data monopolies already. Take for example AWS S3 storage -- there are multiple providers (AWS, Backblaze or local Minio) and many, many clients in all sorts of languages.
Re: Filecoin, StorJ and the problem with decentralized storage (2019)
#34Earlier quoted context omitted.
Sure it can provide an SLA. The code is the SLA. And is available for all to examine. Via opensource. And governance allows the community to change terms/accept code... moving forward.
That's pretty hand-wavy. Anyone can read the published code, but you can't read the code being run by each individual entity in the network. Any individual might change their server to not make the stored data available to those paying for the storage. It's not _likely_, as that would negate the usefulness of the whole system if it became an issue, and therefore negate the cash flow into the system. Ultimately what's…
What if the system had 2 kinds of nodes, storage nodes, and then verification nodes. The storage nodes, store the data. The verification nodes, hit the storage nodes and verify the data is there and available. If the storage node fails a verification attempt, the storage node pays a fee. After a certain amount of failures, it is banned from the network.
Disclaimer: I have no idea how these systems currently work.
Re: Filecoin, StorJ and the problem with decentralized storage (2019)
#35One important property of decentralized storage is that it prevents data monopolies. For example, if you host your web app on Sia Skynet, then users own their data instead of being locked in by the app developer. It also enables a model where different apps can easily access the same data. The data is in the "cloud", but still owned by the user.
Do you know why Sia is overlooked so often? I see a lot of shills on forums and the founder seems to tweet bitterly about Filecoin, but folks seem optimistic about the tech. So what am I missing that makes Sia not get adoption vs. Filecoin?
The Sia team has let down customers for other tangential projects, and Sia has weaker guarantees than Filecoin. It’s been out a long time now and they have failed to address some core scaling and redundancy concerns. I wouldn’t say it’s bad, but it’s seeming more like maidsafe - never got enough traction and now the interest is on filecoin and arweave.
Re: Filecoin, StorJ and the problem with decentralized storage (2019)
#36Economies of scale in the cloud have one thing going for them: massive reliability.
As someone responsible for my company's data, I cannot make a sound argument to convince management (or myself) to use anything but Amazon S3 (or Google or Microsoft) cloud. The data is simply too important to trust to a smaller entity.
Maybe coin storage can boost Storj's reputation. And I certainly favor decentralization for Crypto.
Re: Filecoin, StorJ and the problem with decentralized storage (2019)
#37Earlier quoted context omitted.
That's pretty hand-wavy. Anyone can read the published code, but you can't read the code being run by each individual entity in the network. Any individual might change their server to not make the stored data available to those paying for the storage. It's not _likely_, as that would negate the usefulness of the whole system if it became an issue, and therefore negate the cash flow into the system. Ultimately what's…
What if the system had 2 kinds of nodes, storage nodes, and then verification nodes. The storage nodes, store the data. The verification nodes, hit the storage nodes and verify the data is there and available. If the storage node fails a verification attempt, the storage node pays a fee. After a certain amount of failures, it is banned from the network. Disclaimer: I have no idea how these systems currently work.
This is basically how decentralized storage works except you can't really ban anyone so a storage provider will lose their deposit if they fail verification. As the article says, this forces storage providers to lock up capital and even that is no guarantee since there may be situations where losing the deposit is actually cheaper than staying in business.
Re: Filecoin, StorJ and the problem with decentralized storage (2019)
#38Is there any sensible study on those system's energy consumption?
Given that public clouds are ruthlessly optimized for efficiency and they don't have to perform trustless proof of anything, it's virtually certain that decentralized storage is less efficient in every way than centralized.
Re: Filecoin, StorJ and the problem with decentralized storage (2019)
#39One important property of decentralized storage is that it prevents data monopolies. For example, if you host your web app on Sia Skynet, then users own their data instead of being locked in by the app developer. It also enables a model where different apps can easily access the same data. The data is in the "cloud", but still owned by the user.
Do you know why Sia is overlooked so often? I see a lot of shills on forums and the founder seems to tweet bitterly about Filecoin, but folks seem optimistic about the tech. So what am I missing that makes Sia not get adoption vs. Filecoin?
Likewise with ScPrime (https://scpri.me) which is like Sia but focused on B2B data storage and is changing to PoS instead of PoW to be more environmentally friendly.
Re: Filecoin, StorJ and the problem with decentralized storage (2019)
#40Economies of scale in the cloud have one thing going for them: massive reliability. As someone responsible for my company's data, I cannot make a sound argument to convince management (or myself) to use anything but Amazon S3 (or Google or Microsoft) cloud. The data is simply too important to trust to a smaller entity. Maybe coin storage can boost Storj's reputation. And I certainly favor decentralization for Crypto.
So granted the durability and availability is better than centralized solutions, you'd go with the distributed/decentralized solution?
If that's the case, I think you could argue that open source and distributed solutions are much easier to make more reliable than centralized solutions. With a centralized solution, you're stuck with trusting their reliability or implement some reusable API (or use some 3rd party's API that abstract that away, introducing more error surface) so you can also store the data in multiple places with the same API.
Or, you can just use a open source decentralized solutions and run it locally geographically, hosted on dedicated servers and "in the cloud" (meaning other users who host it) with the same API without really caring about _where_ the files are, just _which_ files you need.
And that's the beauty of content-addressable networks like many of these are. It doesn't really matter where the data is as long as you know what data you need. That makes it easier to provide reliability for yourself, not harder.
Once you dig down in the details and compare them both carefully, I think you can make sound arguments both ways, it's not as black & white as you make it. Ultimately it depends on one's use case.