Investor revolt and legal dispute delay Filecoin plans(axios.com)
axios.com
Investor revolt and legal dispute delay Filecoin plans
https://www.axios.com/filecoin-blockchain-delay-3b5e6b9a-bcc8-41cf-81cf-563f6cebb2c4.html
120 comments
Filecoin is a great example of raising a lot of money slowing a project down. They did a $200m ICO in 2017 and they still haven't shipped a 1.0, while smaller, much less well funded projects (Sia, Arweave, ...) have made a lot more progress.
It is unsurprising given that the raison d'etre for Filecoin was never the demand for decentralized storage, or backup, or anything else. It was started with the sole purpose of raising money, because of the overwhelming demand for hype-driven investment opportunities that tick the typical checkboxes. And that was delivered perfectly.
Releasing an actual product is more of a side product. If you don't develop or release anything, and just buy yourself Porsches, it's textbook embezzlement. But if you spend the money in a plausible way, you're mostly safe, even if the product turns out a major flop.
Unless you get greedy and start doing too shady stuff, like issuing yourself tokens under the table, that the founders apparently did.
Releasing an actual product is more of a side product. If you don't develop or release anything, and just buy yourself Porsches, it's textbook embezzlement. But if you spend the money in a plausible way, you're mostly safe, even if the product turns out a major flop.
Unless you get greedy and start doing too shady stuff, like issuing yourself tokens under the table, that the founders apparently did.
This isn't true of Protocol Labs. They have already shipped IPFS, which is already in substantial use. Filecoin's testnet is live now, they have not shipped mainnet yet, but it's pretty imminent at this point. There are certainly some ICO scams out there, but I do not believe Filecoin was one of them. I still think $200m was too much, too soon. However, they didn't issue the tokens to themselves under the table. They issued a SAFT agreement for tokens to accredited investors in the United States, abiding by SEC regulations. They allocated 10 percent to investors, 15 percent to themselves, 5 percent to the Filecoin foundation, and 70 percent for Filecoin miners. That was all part of the upfront ICO.
It could turn out to be a flop, but the only people that would lose would be accredited investors who, according to regulations, should know better. I would say Filecoin has at least as good of a chance of succeeding as any ordinary VC investment.
It could turn out to be a flop, but the only people that would lose would be accredited investors who, according to regulations, should know better. I would say Filecoin has at least as good of a chance of succeeding as any ordinary VC investment.
What is the actual IPFS user base besides curiosity traffic and crypto speculators?
IPFS is an independent protocol from Filecoin. It is not a cryptocoin in and of itself. It is an alternative addressing system for content on the web. The idea is that files are organized by their contents (using a cryptographic hash of those contents) rather than by IP address. You can pin content with your own independently run IPFS node using any tech stack of your choosing. You can spin up a website powered by IPFS today and many people are already doing that.
https://ipfs.io/images/ipfs-applications-diagram.png for some examples of applications using IPFS. Visit https://ipfs.io/ for more info.
https://ipfs.io/images/ipfs-applications-diagram.png for some examples of applications using IPFS. Visit https://ipfs.io/ for more info.
Cloudflare also provides a gateway to IPFS [1].
[1] https://blog.cloudflare.com/distributed-web-gateway/
[1] https://blog.cloudflare.com/distributed-web-gateway/
Cloudflare's gateway also does down like 50% of the time. It is hardly reliable. But this isn't so much indicative as a problem with Cloudflare, more than IPFS is completely unreliable
Yeah, they probably did a partnership for extra visibility (Protocol labs could even have paid them to build it, as it increases the perceived value of IPFS and hence Filecoin). It still doesn't tell anything about demand.
Given IPFS is a protocol (think BitTorrent) and doesn't have any kind of token, your accusation that only "crypto speculators" use it outs you as not being particularly charitable here. I think if you look into it you'll find it's pretty useful.
I've personally used it for storing large binaries outside of git. My build process requires using some binaries and fetching them by hash is much better than fetching them from some url.
I've personally used it for storing large binaries outside of git. My build process requires using some binaries and fetching them by hash is much better than fetching them from some url.
File sharing/distributed hosting enthusiasts. You can spend plenty of time with IPFS without ever hearing of Filecoin.
That's curiosity traffic. People who experiment with new exciting tech as it comes out. When new tech is announced, they move on.
This is a good indicator of a technology's novelty, but it has zero correlation with the product/market fit.
This is a good indicator of a technology's novelty, but it has zero correlation with the product/market fit.
It’s been used to prevent denial of service, such as in the Catalina succession vote.
I don't know if you knew this or not, but at one time in the not too distant past, the internet as a whole was a curiosity only used by geeks. And before that, only total nerds in their mom's basement used personal computers.
Yes but from that it does not follow that filecoin will experience the same kind of growth.
Internet = Once curiosity, small, for geeks
Internet = Success
Filecoin = Is curiosity, small, for geeks
Filecoin = SuccessThis shouldn't be down voted, it's an important thing to point out.
IPFS doesn't really have a killer app people actually care about as long as we're not actually interplanetary - the internet connection from any point to another on the planet is generally good enough.
IPFS doesn't really have a killer app people actually care about as long as we're not actually interplanetary - the internet connection from any point to another on the planet is generally good enough.
This Peer to Peer database is one example https://github.com/orbitdb/orbit-db
Here is a subforum dedicated to discussing use cases of IPFS. https://discuss.ipfs.io/c/ecosystem/applications-of-ipfs/16
Here is a subforum dedicated to discussing use cases of IPFS. https://discuss.ipfs.io/c/ecosystem/applications-of-ipfs/16
I host my blog using IPFS.
How do you do this? I'm interested in mirroring my own sites to IPFS.
Here's a tutorial I followed: https://teetotality.blog/posts/how-this-blog-was-made/
It is unsurprising given that the raison d'etre for Filecoin was never the demand for decentralized storage, or backup, or anything else. It was started with the sole purpose of raising money, because of the overwhelming demand for hype-driven investment opportunities that tick the typical checkboxes. And that was delivered perfectly.
I don't understand the basis for this accusation. I thought the reason for Filecoin was essentially to provide an incentive layer to run IPFS nodes. The problem with IPFS was that it largely drew from volunteer efforts and therefore if you want to actually want IPFS to be a high-performing and low cost service you need to provide a market incentive structure to run a node.
I don't understand the basis for this accusation. I thought the reason for Filecoin was essentially to provide an incentive layer to run IPFS nodes. The problem with IPFS was that it largely drew from volunteer efforts and therefore if you want to actually want IPFS to be a high-performing and low cost service you need to provide a market incentive structure to run a node.
Historically, blockchain services have suffered from the situation that their price is pumped up to levels that cannot be justified by any level of adoption. So the resulting incentives are just for speculation and further pump-and-dump cycles instead of actual usage.
[deleted]
But there are already pinning services, conventionally paid by the person wanting to have something pinned.
Of course you can build something super distributed and fractional on top of that. Maybe d.tube and lbry are such things, but the more venture capital is involved the less I tend to trust such efforts.
Of course you can build something super distributed and fractional on top of that. Maybe d.tube and lbry are such things, but the more venture capital is involved the less I tend to trust such efforts.
Paying some pinning service is, architecturally, not much different than paying S3 to store your files.
Filecoin turns file storage into a marketplace, which is a significant improvement. Currently S3 charges a large premium because you wouldn't trust many other people to reliably hold on to your data. I expect this will cause the cost of file storage to plummet.
Your venture capital heuristic is a good one, but I think the rest of what we know about Filecoin overwhelms it.
Filecoin turns file storage into a marketplace, which is a significant improvement. Currently S3 charges a large premium because you wouldn't trust many other people to reliably hold on to your data. I expect this will cause the cost of file storage to plummet.
Your venture capital heuristic is a good one, but I think the rest of what we know about Filecoin overwhelms it.
> Filecoin is a great example of raising a lot of money slowing a project down.
I wouldn't assume the money was the cause of the slowdown.
More likely, raising huge amounts of money was the goal in the first place.
From the article:
> But multiple sources say that a large percentage of those tokens had been unilaterally distributed by CEO Juan Batiz-Benet to himself and early employees for less than a penny each, and that he has continued to make such distributions in the years since.
> Sources also say that no tokens were distributed to shareholders and that it often was difficult to get questions answered.
I wouldn't assume the money was the cause of the slowdown.
More likely, raising huge amounts of money was the goal in the first place.
From the article:
> But multiple sources say that a large percentage of those tokens had been unilaterally distributed by CEO Juan Batiz-Benet to himself and early employees for less than a penny each, and that he has continued to make such distributions in the years since.
> Sources also say that no tokens were distributed to shareholders and that it often was difficult to get questions answered.
There's a good argument to be made that the money made it slower. They hired a TON of engineers at once and after looking at their code, you can tell it's a too-many-cooks situation.
Raising huge amounts of money certainly was the goal but that doesn't mean it couldn't have detrimental effects past their bank accounts.
Raising huge amounts of money certainly was the goal but that doesn't mean it couldn't have detrimental effects past their bank accounts.
Are any of these projects ready for personal backup use, or still experimental?
The chance of "filecoin" or whatever else existing 12 months into the future is astonishingly low. The "completion" rate on ICOs is close to zero.
> "Obviously it could fail and become worthless. But if it works it could be huge, like Google-scale huge, which is why this became so contentious," a different investor explains.
That anybody put money into such a bleak concept is still beyond me.
> "Obviously it could fail and become worthless. But if it works it could be huge, like Google-scale huge, which is why this became so contentious," a different investor explains.
That anybody put money into such a bleak concept is still beyond me.
I can generally agree about random ICOs, but for what it's worth the Filecoin team is world-class distributed systems talent. I wouldn't say this about any other ICO.
(I don't own Filecoin tokens and have nothing to gain by the project being successful, I'm just a fan of that team.)
(I don't own Filecoin tokens and have nothing to gain by the project being successful, I'm just a fan of that team.)
If you're investing in a business venture, the distributed systems talent doesn't matter nearly as much as their ability to build and maintain a successful business without it falling over. If they've got millions USD worth of cash in the bank, they can hire talented engineers, but if they don't have any idea how to run a business no algorithm is going to fix that.
I'm responding to:
> The chance of "filecoin" or whatever else existing 12 months into the future is astonishingly low.
I actually think the chance of Filecoin existing in a year is close to 1. It's not due to a prediction of a wildly successful corporate structure. It's mainly about the tech.
> The chance of "filecoin" or whatever else existing 12 months into the future is astonishingly low.
I actually think the chance of Filecoin existing in a year is close to 1. It's not due to a prediction of a wildly successful corporate structure. It's mainly about the tech.
[deleted]
Seems roughly in like with most startups
I’ve found Sia to be quite good. Their “skynet” system is really cool.
ScPrime has been looking really good too!
Sia (and its Skynet product) have been working great for me for the last 6 months!
Storj, Sia, and a few others minor players are in production. Each have their tradeoffs.
Arweave has a pay once, store forever model where after the initial payment to upload (~$0.005/MB) the file is stored forever on the permaweb. You can get started with some free tokens to play with arweave here:
http://tokens.arweave.org/
I also suggest you check out the latest Arweave x Gitcoin Open Web Incubator Demo Day from last week to see the latest stuff being built. Looking forward to ArDrive, Verto, WeaveID and more.
https://www.youtube.com/watch?v=Slzyw1w5Ric&feature=youtu.be
One further advantage of decentralized UI hosting on Arweave is simply resilience to website outages: https://twitter.com/rleshner/status/1278444807011139585
http://tokens.arweave.org/
I also suggest you check out the latest Arweave x Gitcoin Open Web Incubator Demo Day from last week to see the latest stuff being built. Looking forward to ArDrive, Verto, WeaveID and more.
https://www.youtube.com/watch?v=Slzyw1w5Ric&feature=youtu.be
One further advantage of decentralized UI hosting on Arweave is simply resilience to website outages: https://twitter.com/rleshner/status/1278444807011139585
Interesting that this is 1,000 times the price of B2 per month, so if you're willing to pre-pay for 1,000 months (83 years) of service you get the "rest" for free.
You're not paying for storage. You're paying for permanent, guaranteed immutable, community-programmable storage immune to seizures, platform changes, manipulation, and censorship.
For the right use cases, that's a bargain.
For the right use cases, that's a bargain.
It is only immutable and immune to manipulation while there are enough miners, and there are no hard forks.
While it may look good now, there is a non-zero chance it will disappear within 5 years for some reason or other.
So if your data is really important, better make a backup copy of it somewhere safe, like in B2.
While it may look good now, there is a non-zero chance it will disappear within 5 years for some reason or other.
So if your data is really important, better make a backup copy of it somewhere safe, like in B2.
It would be interesting to know what life is like for a developer on such a team. Is it like a full time job? A demanding one? Less?
? raising a lot of money WAS the project
It seems like there is a lot of hostility toward protocol labs (among others doing stuff with “blockchain”). However, everything they build is free and open source. They’ve gone to considerable length to make their libraries modular and support a multitude of languages.
Libp2p is the best peer-to-peer utility I’m aware of (please share if you know of comparable others). This in it self is a massive undertaking.
Multiformats is brilliant. A few simple tweaks to the way we form address open so many doors.
IPLD is supports json, cbor, protobuffers, git and more. All of which tie together really nicely in to the multiformat addressing and utilized by IPFS.
Literally everything they do is open source and free to use how ever you want. If you find a bug, fix it. If want support for something new, propose it.
Their projects are frustrating sometimes with regard to understanding the nuances of decisions that were made (such as /p2p vs the overloaded /ipfs) but they’re not building pay per use service like AWS S3, they’re building an open source community and they deserve at least a look at their source code before writing them off.
Libp2p is the best peer-to-peer utility I’m aware of (please share if you know of comparable others). This in it self is a massive undertaking.
Multiformats is brilliant. A few simple tweaks to the way we form address open so many doors.
IPLD is supports json, cbor, protobuffers, git and more. All of which tie together really nicely in to the multiformat addressing and utilized by IPFS.
Literally everything they do is open source and free to use how ever you want. If you find a bug, fix it. If want support for something new, propose it.
Their projects are frustrating sometimes with regard to understanding the nuances of decisions that were made (such as /p2p vs the overloaded /ipfs) but they’re not building pay per use service like AWS S3, they’re building an open source community and they deserve at least a look at their source code before writing them off.
What I don't understand about Filecoin is that they advertise it is for "Private data" too, but there are no access control mechanisms and no ability to delete data from the network. (You can "unpin" it, but there's no mechanism in the clients to compel nodes to actively remove content afaik) If I put private data on the Filecoin network, I would like to be able to largely prevent most people from even pulling down the encrypted files. What happens when the encryption guarding those files is found to contain a flaw and gets compromised? If someone has an old copy of the encrypted files, then that data can now be unencrypted. These issues seem to go largely ignored by Filecoin as best as I can tell.
> If I put private data on the Filecoin network, I would like to be able to largely prevent most people from even pulling down the encrypted files.
Isn't that fundamentally impossible? There's nothing preventing someone from setting up an archive site dedicated to storing/serving deleted content.
Isn't that fundamentally impossible? There's nothing preventing someone from setting up an archive site dedicated to storing/serving deleted content.
I think you might not be understanding what I mean. I'd like to be able to use Filecoin as a backend storage that will only serve up data to people in a particular group.
Take the example of a traditional website or web application like Facebook. When I post content I can select who will be able to access that content and there is no way for anyone NOT in the groups I select to pull down that data even in an encrypted form.
If Filecoin operated this way, then there would be no way for anyone to archive the data, because they could not access it in the first place.
Take the example of a traditional website or web application like Facebook. When I post content I can select who will be able to access that content and there is no way for anyone NOT in the groups I select to pull down that data even in an encrypted form.
If Filecoin operated this way, then there would be no way for anyone to archive the data, because they could not access it in the first place.
Right but filecoin isn't a centralized service, it's a decentralized network. Just like how ultimately your facebook post is stored on a server somewhere, stuff you stored using filecoin is stored on a random computer somewhere. At least with facebook there's some central entity that gets to decide where their servers are located and who gets access to them. You don't get that with a decentralized network.
Just because the storage network is decentralized (i.e. I don't get to choose where the files are hosted) doesn't mean that the nodes operating on that network can't be designed to honor a deletion request. For example, Tardigrade (https://tardigrade.io) is an decentralized network that provides an S3-compatible storage layer and also provides a removal command for the client. (https://documentation.tardigrade.io/api-reference/uplink-cli...)
It's not just a decentralized network, it's an open membership decentralized network, i.e. anyone can be a node, and any compatible software can be used to run a node.
What the parent posters are saying is that there's no way to trust that your (encrypted) data won't end up landing on the hard drive of someone who chooses to capture everything that passes through said hard drive.
Whether the node itself keeps the data is kind of immaterial, if there's no technical limitation preventing the owner of the node from keeping your data.
But also, as an open-membership decentralized network, there's also no real way to incentivize node implementations to obey deletion requests.
It's helpful to think about peer-to-peer networks as if every node was programmed from scratch by the person or organization running it, to do exactly and only what that person/organization wants it to do. (Not true, obviously, but the incentives behind there being a free market of p2p node software work out similarly to if it was.)
In such an environment, why would a given node owner want to add a "read a deletion-request log, and actually-delete everything mentioned in it" feature to their node in particular? Especially if they weren't a party with their own private data stored that they were interested in ever deleting, but instead were only on the network to make money hosting other people's stuff; or because they wanted to insert public data sets onto the network?
What the parent posters are saying is that there's no way to trust that your (encrypted) data won't end up landing on the hard drive of someone who chooses to capture everything that passes through said hard drive.
Whether the node itself keeps the data is kind of immaterial, if there's no technical limitation preventing the owner of the node from keeping your data.
But also, as an open-membership decentralized network, there's also no real way to incentivize node implementations to obey deletion requests.
It's helpful to think about peer-to-peer networks as if every node was programmed from scratch by the person or organization running it, to do exactly and only what that person/organization wants it to do. (Not true, obviously, but the incentives behind there being a free market of p2p node software work out similarly to if it was.)
In such an environment, why would a given node owner want to add a "read a deletion-request log, and actually-delete everything mentioned in it" feature to their node in particular? Especially if they weren't a party with their own private data stored that they were interested in ever deleting, but instead were only on the network to make money hosting other people's stuff; or because they wanted to insert public data sets onto the network?
In terms of an incentive, I would say that the node owner would honor the deletion request if the network pays them to do that. If I'm a node operator I don't so much care about the particular data I'm hosting, just what the network is paying for me to do.
The threat model I'm thinking about is a malicious actor requests an IPFS object that he/she knows holds data that is valuable, but that they can not decrypt. They then hold this object for a period of time till at some point they are able to break into it using improved computing power or exploiting some flaw in the implementation.
Now, you raise a good point about Filecoin being an open membership network. In my particular example, the malicious actor could just decide to run an IPFS node and start holding any data that comes to it for future malicious purposes and maybe they start pulling down specific files that they want to target directly. I don't have a solution to this other than to think that having some reputation built into the IPFS node network could help mitigate that risk. You might imagine that nodes with high reputation are trusted and it is harder(requires a lot of time/money) as a node operator to become part of that group. People might decide to only trust the highly reputable nodes with their private data and utilize all nodes for public data.
The threat model I'm thinking about is a malicious actor requests an IPFS object that he/she knows holds data that is valuable, but that they can not decrypt. They then hold this object for a period of time till at some point they are able to break into it using improved computing power or exploiting some flaw in the implementation.
Now, you raise a good point about Filecoin being an open membership network. In my particular example, the malicious actor could just decide to run an IPFS node and start holding any data that comes to it for future malicious purposes and maybe they start pulling down specific files that they want to target directly. I don't have a solution to this other than to think that having some reputation built into the IPFS node network could help mitigate that risk. You might imagine that nodes with high reputation are trusted and it is harder(requires a lot of time/money) as a node operator to become part of that group. People might decide to only trust the highly reputable nodes with their private data and utilize all nodes for public data.
What if they claim publicly to delete your data, accept decentralized payments to delete the data, actually delete that data on the node in the sense that nobody can retrieve the data on the public internet using any official protocols, but routinely take filesystem-snapshots of their servers and the owner browses them offline undetectably at their leisure?
Then 3 years later all the snapshots end up on a torrent site, after you paid that whole time to "delete data".
Then 3 years later all the snapshots end up on a torrent site, after you paid that whole time to "delete data".
Yes, I think that is a risk in the absence of a true "Proof of Deletion". Perhaps though it would be so expensive to maintain a copy of all this data that no one is paying you for that nodes would be incentivized to just perform the actual deletion, since the rewards of keeping the data are unknown and the time horizon for maintaining that data at your own expense is unknown.
You can issue removal commands all you like. There's still no guarantee that the client performs the operation.
I agree, at least afaik there is no way to construct a formal "Proof of Deletion". This risk though I believe exists with even centralized services, so for example if I ask Amazon to delete this blob of data I actually don't know if in fact they did delete it. We all just assume they are doing what they are purporting to do, because if they aren't then there could be significant legal repercussions.
In the Filecoin case, I would still think that it should be possible to guarantee that a particular object is not being actively served by a node on the network at any particular point in time and penalizing nodes (loss of Filecoin) that do not pass this check.
In the Filecoin case, I would still think that it should be possible to guarantee that a particular object is not being actively served by a node on the network at any particular point in time and penalizing nodes (loss of Filecoin) that do not pass this check.
There's just no point. Encrypt the data. Ask the people with access to delete their keys. This way you don't have to make Filecoin more complicated.
I disagree. Again encryption is not the same as not having access at all to the data. If centralized services offer the concept of having access control mechanisms available and we trust them to delete the files, then why not have those same types of mechanisms in place for a decentralized network? Asking people to delete their keys is user hostile and will likely lead to people just not using the service.
> Again encryption is not the same as not having access at all to the data.
Yes, it is. If you delete the keys, nobody has access at all to the data. The ciphertext is irrelevant.
Yes, it is. If you delete the keys, nobody has access at all to the data. The ciphertext is irrelevant.
The ciphertext is irrelevant now, today. That might not always be the case if computing power improves sufficiently to be able to breakthrough that encryption or a flaw in the encryption algorithm (or default parameters being used in a particular implementation) is discovered. At that point, it would be nice to know that even the ciphertext was not exposed.
If your data is so important that it needs to be protected from future theoretical attacks.... what the heck are you doing uploading it to a globally distributed and decentralized platform?!
Said another way: you are trying to fit a centralized-shaped peg into a decentralized-shaped hole... wrong tool for the job.
If your use case does involve this situation somehow (?) then the only real solution is to encrypt it, as others in this thread have pointed out. There is simply no other option in an open-membership P2P network... otherwise the RIAA and MPAA would have long ago crushed BitTorrent.
Said another way: you are trying to fit a centralized-shaped peg into a decentralized-shaped hole... wrong tool for the job.
If your use case does involve this situation somehow (?) then the only real solution is to encrypt it, as others in this thread have pointed out. There is simply no other option in an open-membership P2P network... otherwise the RIAA and MPAA would have long ago crushed BitTorrent.
They're running software that connects to your overlay of the network, no? It doesn't involve human interaction.
When I say "user" here I'm talking about me the service provider being the user of the network. Instead of "user hostile", what I should have said is it "just doesn't solve the problem of access".
The concern I have is about malicious actors being able to access the raw objects held on the Filecoin network. They won't be able to do anything with the encrypted objects immediately, but I don't know that you can claim that will always be the case decades from now.
The concern I have is about malicious actors being able to access the raw objects held on the Filecoin network. They won't be able to do anything with the encrypted objects immediately, but I don't know that you can claim that will always be the case decades from now.
[deleted]
This is the only sane solution.
>In the Filecoin case, I would still think that it should be possible to guarantee that a particular object is not being actively served by a node on the network at any particular point in time and penalizing nodes (loss of Filecoin) that do not pass this check.
But all that would do would be to push people to do it off-network instead.
But all that would do would be to push people to do it off-network instead.
Yes, I agree. It is just a mitigation. At least though it would not be actively available on the main network. The more I think about this, the more I think being able to have some sort of reputation system for node operators would be really valuable.
Ultimately the network will be storing blobs of some kind. You can build whatever encryption structure you want to, on top of that layer.
I'm not sure how you would implement this, since there's no way to provide a proof of deletion. Proof of storage is possible since you can do some operation on the stored data and then provide the result.
However, I assume when a file is "unpinned" in IPFS you stop earning Filecoin for storing it? I'm not sure but I can't imagine why it would be any other way.
However, I assume when a file is "unpinned" in IPFS you stop earning Filecoin for storing it? I'm not sure but I can't imagine why it would be any other way.
So I have read this is why they didn't implement deletion support before. With that said, I would still think that 1) It should be possible to guarantee that a particular object is not being actively served by a node on the network at any particular point in time and 2) If all the node software supports deletion, then even if you couldn't provide a 100% guarantee at least it would provide some mitigation.
Keep in mind also that Filecoin's storage layer is IPFS; and IPFS nodes don't have incentives that are perfectly aligned with those of Filecoin.
There's maybe a reason for the owner of a "Filecoin node" to want to delete data "on the network." But that data ends up stored on many IPFS nodes, some (many?) of those hosted by people who've never even heard of Filecoin, but are just running on the public IPFS network for other reasons (usually the same reasons someone would donate to the Internet Archive, or host a public-access Debian APT mirror.)
When you look up a file "on Filecoin", you're really looking it up from the IPFS network. Filecoin just incentivizes the insertion process. But data inserted "into Filecoin" is now on IPFS. So you have to think about what an IPFS node would (want to) do with your data.
Why would these "pure" IPFS nodes that have your data, care about deleting it in response to requests? That's not what IPFS is "for." These nodes aren't participating in the filesystem-like storage paradigm that Filecoin represents. They're participating in a "content-addressable storage" paradigm. Deletion would be a violation of the ideology that likely motivates them to run their node.
There's maybe a reason for the owner of a "Filecoin node" to want to delete data "on the network." But that data ends up stored on many IPFS nodes, some (many?) of those hosted by people who've never even heard of Filecoin, but are just running on the public IPFS network for other reasons (usually the same reasons someone would donate to the Internet Archive, or host a public-access Debian APT mirror.)
When you look up a file "on Filecoin", you're really looking it up from the IPFS network. Filecoin just incentivizes the insertion process. But data inserted "into Filecoin" is now on IPFS. So you have to think about what an IPFS node would (want to) do with your data.
Why would these "pure" IPFS nodes that have your data, care about deleting it in response to requests? That's not what IPFS is "for." These nodes aren't participating in the filesystem-like storage paradigm that Filecoin represents. They're participating in a "content-addressable storage" paradigm. Deletion would be a violation of the ideology that likely motivates them to run their node.
Yes, I understand that. I have this same issue with using just pure IPFS to store private data. IPFS for public data makes a lot of sense to me. When using IPFS for private data there seems like there is an inherent risk (hopefully only a small risk) that the encryption or its implementation can be broken at some point in the future potentially exposing the content that is hosted on the network. Normally, in this scenario the response is just run your own network of IPFS nodes if you want to restrict access, which is totally reasonable. I'm just expressing my desire to have something like Filecoin, but at the network level have the clients enforce access permissions and honor deletes. I may be the only one though. :)
I think the thing is that, because, as you say, there’s no true “Proof of Deletion” possible, then people who are considering alternatives when implementing a system that has private data, and needs a storage layer, just won’t choose IPFS/Filecoin, since it can’t offer them the same guarantees that e.g. using S3 can.
Using S3 at least means you’re in a contractual relationship with Amazon, who thus has a monetary incentive from all its customers to “do what it says on the tin”, lest they all lose faith in its claims and boycott/switch to some other object-storage provider. Amazon can do this, because it's a single coherent closed-membership hierarchical organization, rather than an open-membership p2p network which people could join for reasons at odds with the network's "designed" incentives.
Without a "Proof of Deletion", adding a deletion-request system to Filecoin would only be a mitigation against ciphertext-recovery at best—something that increases the probability that your file will be fully erased from the network—rather than a true guarantee that the entire system will attempt to achieve an explicit consensus state where the ciphertext has been purged from it.
So, if you're a system architect, why would you choose to store private data on a service (Filecoin) that can only offer a high probability of erasure, rather than one (S3) that can offer a guarantee of non-recovery?
And if it's clear that there's no reason to make that decision in favour of Filecoin, then turn that around: why, as the Filecoin or IPFS node-software authors, would you bother to add this feature, if it would be the game-theoretic dominant strategy for software architects that have this use-case to ignore Filecoin/IPFS in favor of some other solution, with or without the added feature?
-----
All that being said, I'm ignoring a distinction here that's fairly important: there are two types of private data — timely and timeless private data.
• Timeless private data would have just as much value if it was obtained years from now, as it would have if it were obtained today. (Someone's Bitcoin-wallet private keys, for example. Or compromising photos of a politician.)
• Timely private data has high value to its owner upon creation, but that value erodes over time; until, at some point, even the creator themselves doesn't much care if it gets leaked. (Apple's next iPhone design, for example. Or the source code to Super Mario World. Or military intelligence.)
There's actually far more timely private data in the world than timeless private data. And encryption, all by itself, basically solves the protection needs of timely private data. Cryptanalysis seems to only really advance in power alongside Moore's law; so anything encrypted using modern encryption technology, won't be brute-forced for a number of years yet. So you can take your timely private data, encrypt it, and stick a printout of the base64 ciphertext in the public square, if you like. By the time anyone can decrypt it, there'll be no value in doing so.
Filecoin/IPFS works just fine to hold timely private data. And since that's most private data, it actually supports the needs of most system architects just fine.
It's quite the rare use-case that requires decentralized storage of timeless private data. The fact that this type of data is so rare, though, is another strike against IPFS or Filecoin node-software developers being interested in introducing a feature specifically meant to help that use-case. Filecoin/IPFS would still be a non-dominant strategy for the timeless-private-data case, so there'd still be no point; but on top of that, it's a niche-within-a-niche.
Using S3 at least means you’re in a contractual relationship with Amazon, who thus has a monetary incentive from all its customers to “do what it says on the tin”, lest they all lose faith in its claims and boycott/switch to some other object-storage provider. Amazon can do this, because it's a single coherent closed-membership hierarchical organization, rather than an open-membership p2p network which people could join for reasons at odds with the network's "designed" incentives.
Without a "Proof of Deletion", adding a deletion-request system to Filecoin would only be a mitigation against ciphertext-recovery at best—something that increases the probability that your file will be fully erased from the network—rather than a true guarantee that the entire system will attempt to achieve an explicit consensus state where the ciphertext has been purged from it.
So, if you're a system architect, why would you choose to store private data on a service (Filecoin) that can only offer a high probability of erasure, rather than one (S3) that can offer a guarantee of non-recovery?
And if it's clear that there's no reason to make that decision in favour of Filecoin, then turn that around: why, as the Filecoin or IPFS node-software authors, would you bother to add this feature, if it would be the game-theoretic dominant strategy for software architects that have this use-case to ignore Filecoin/IPFS in favor of some other solution, with or without the added feature?
-----
All that being said, I'm ignoring a distinction here that's fairly important: there are two types of private data — timely and timeless private data.
• Timeless private data would have just as much value if it was obtained years from now, as it would have if it were obtained today. (Someone's Bitcoin-wallet private keys, for example. Or compromising photos of a politician.)
• Timely private data has high value to its owner upon creation, but that value erodes over time; until, at some point, even the creator themselves doesn't much care if it gets leaked. (Apple's next iPhone design, for example. Or the source code to Super Mario World. Or military intelligence.)
There's actually far more timely private data in the world than timeless private data. And encryption, all by itself, basically solves the protection needs of timely private data. Cryptanalysis seems to only really advance in power alongside Moore's law; so anything encrypted using modern encryption technology, won't be brute-forced for a number of years yet. So you can take your timely private data, encrypt it, and stick a printout of the base64 ciphertext in the public square, if you like. By the time anyone can decrypt it, there'll be no value in doing so.
Filecoin/IPFS works just fine to hold timely private data. And since that's most private data, it actually supports the needs of most system architects just fine.
It's quite the rare use-case that requires decentralized storage of timeless private data. The fact that this type of data is so rare, though, is another strike against IPFS or Filecoin node-software developers being interested in introducing a feature specifically meant to help that use-case. Filecoin/IPFS would still be a non-dominant strategy for the timeless-private-data case, so there'd still be no point; but on top of that, it's a niche-within-a-niche.
> If I put private data on the Filecoin network, I would like to be able to largely prevent most people from even pulling down the encrypted files.
Why do you want this? The files are encrypted and thus illegible. To anyone without the key they look like random noise.
Why do you want this? The files are encrypted and thus illegible. To anyone without the key they look like random noise.
The same reason people set permissions on their encrypted S3 object blob or you have to login to download any encrypted file from a multitude of applications. As computing power increases and/or as flaws in encryption implementations are discovered, then what is encrypted today might not stay encrypted decades from now.
What sort of adversary do you imagine would carry out an attack like that?
If you're defending against your own government, they already control the network and could hold on to your S3 network traffic until they can decrypt it.
If you're defending against an individual how would they know where to download your file from? I assume the network doesn't broadcast a connection between real life identity and the data you're storing. And if the individual can monitor your physical network, then they can again decrypt the network traffic eventually.
If you're defending against the server hosting your content, they would have to host your old data for years past you stopping the service before they could decrypt the content, which would be a massive investment.
Finally, do you have reason to believe that our current encryption algorithms will be cracked anytime soon? The last big innovation I heard was SHA-1 generating a hash collision in 2017, but even that took thousands of dollars in compute resources, and SHA-1 was known to be defective for a long time before that. I imagine if we use our best algorithms they'll hold up for quite a while longer.
If you're defending against your own government, they already control the network and could hold on to your S3 network traffic until they can decrypt it.
If you're defending against an individual how would they know where to download your file from? I assume the network doesn't broadcast a connection between real life identity and the data you're storing. And if the individual can monitor your physical network, then they can again decrypt the network traffic eventually.
If you're defending against the server hosting your content, they would have to host your old data for years past you stopping the service before they could decrypt the content, which would be a massive investment.
Finally, do you have reason to believe that our current encryption algorithms will be cracked anytime soon? The last big innovation I heard was SHA-1 generating a hash collision in 2017, but even that took thousands of dollars in compute resources, and SHA-1 was known to be defective for a long time before that. I imagine if we use our best algorithms they'll hold up for quite a while longer.
I assume the network doesn't broadcast a connection between real life identity and the data you're storing.
So my understanding is that in the example of a decentralized app that uses Filecoin to store an IPFS object on the network the IPFS object id could be sniffed on the localhost by something like Wireshark. This way an attacker could identify the encrypted objects that are of interest to them and then independently request them from the IPFS network.
In terms of threat, I'm primarily thinking of larger criminal organizations that might target things like files containing SSNs, credit history, etc.
SHA-1 is an example, but my biggest concern comes from the potential of quantum computing to render what we consider secure today obsolete. (https://www.technologyreview.com/2019/05/30/65724/how-a-quan...)
So my understanding is that in the example of a decentralized app that uses Filecoin to store an IPFS object on the network the IPFS object id could be sniffed on the localhost by something like Wireshark. This way an attacker could identify the encrypted objects that are of interest to them and then independently request them from the IPFS network.
In terms of threat, I'm primarily thinking of larger criminal organizations that might target things like files containing SSNs, credit history, etc.
SHA-1 is an example, but my biggest concern comes from the potential of quantum computing to render what we consider secure today obsolete. (https://www.technologyreview.com/2019/05/30/65724/how-a-quan...)
Quantum computing does not defeat modern encryption, as long as you used an algorithm like AES or Threefish to protect your data, you should be safe from the quantum apocalypse. (Other really important things fail though, like digital signatures and ECDH)
This is not a use case anyone serious cares about.
Data retention for ciphertext where the keys, stored and distributed elsewhere, have been deleted/zeroized, is a complete non-issue.
Data retention for ciphertext where the keys, stored and distributed elsewhere, have been deleted/zeroized, is a complete non-issue.
Why is that? I think it is entirely possible that in the future, encryption techniques used today will become compromised as both computing power improves and/or flaws are discovered. If someone is holding ciphertext encrypted with a compromised algorithm, then it could be decrypted.
Basically, how do you know what we are encrypting today, won't be able to have the encryption broken 30 or 50 years from now?
Basically, how do you know what we are encrypting today, won't be able to have the encryption broken 30 or 50 years from now?
You don't, but offline attacks tend to be relatively hard. 3DES is 25 years old now and not an easy target for a casual attacker.
I think the problem here isn't just Filecoin, it's Protocol Labs as a whole. I've been building applications using IPFS for about 3 years now, and the entire time Protocol Labs has dropped the ball at every corner when it comes to the development of IPFS.
Basically any project I've seen started by Protocol Labs ends up a mess of a project so I'm not surprised Filecoin is where it is now. It's quite clear that Protocol Labs is extremely incapable of managing a project of scale.
Basically any project I've seen started by Protocol Labs ends up a mess of a project so I'm not surprised Filecoin is where it is now. It's quite clear that Protocol Labs is extremely incapable of managing a project of scale.
> Protocol Labs has dropped the ball at every corner when it comes to the development of IPFS.
How so? I don't have much experience with IPFS, but I've heard great things about it
How so? I don't have much experience with IPFS, but I've heard great things about it
Primarily due to poor management of the project. The best way to showcase this is through something called "testground".
Testground was an initiative started by Protocol Labs to create a solution that would be used for testing of IPFS at all levels of the protocols, while also giving developers an SDK that can be used to write new testground tests. The reason this was needed is because the before the Testground project was started, the last few releases of go-ipfs (the reference implementation of IPFS) introduced new bugs, and regressions. Why? Primarily because of the poor planning, poor test coverage, and overall poor project management.
So Testground development started and went on for about 5 months until the developer in charge of Testground development makes a post on a GitHub issue (https://github.com/testground/testground/issues/42#issuecomm...)
Tl;dr of that comment? Poor project management lead to a lot of wasted development time on Testground.
Irony of the whole situation aside, if this was an isolated incident it might not be so bad. But it's not an isolated incident, it happens all the time, and with every single project managed by Protocol Labs.
Interestingly enough this latest post from Axios caused me to come out of the woodworks with my own series of posts about how Protocol Labs has failed both IPFS and Filecoin. I briefly detail a few more of the problems here (https://bonedaddy.io/blog/ipfs/posts/failure-ipfs-filecoin-p...)
Testground was an initiative started by Protocol Labs to create a solution that would be used for testing of IPFS at all levels of the protocols, while also giving developers an SDK that can be used to write new testground tests. The reason this was needed is because the before the Testground project was started, the last few releases of go-ipfs (the reference implementation of IPFS) introduced new bugs, and regressions. Why? Primarily because of the poor planning, poor test coverage, and overall poor project management.
So Testground development started and went on for about 5 months until the developer in charge of Testground development makes a post on a GitHub issue (https://github.com/testground/testground/issues/42#issuecomm...)
Tl;dr of that comment? Poor project management lead to a lot of wasted development time on Testground.
Irony of the whole situation aside, if this was an isolated incident it might not be so bad. But it's not an isolated incident, it happens all the time, and with every single project managed by Protocol Labs.
Interestingly enough this latest post from Axios caused me to come out of the woodworks with my own series of posts about how Protocol Labs has failed both IPFS and Filecoin. I briefly detail a few more of the problems here (https://bonedaddy.io/blog/ipfs/posts/failure-ipfs-filecoin-p...)
Skynet is now a viable alternative to IPFS. It has much of the same functionality: upload a file, get a 34 byte link back, and now that link can be retrieved by any Skynet node. It's got support for things like webapps and HLS, and for many use cases it has superior performance (especially for large files).
https://siasky.net to get started
https://siasky.net to get started
Don't forget to mention that you're shilling your own project ;)
Cryptocurrency was invented to remove middlemen and counterparty risk. Yet every week I hear about middlemen and the tokens they control, and the actions they take or don't take that harm their investors... This is the opposite of crypto. By the way, all file storage coin projects are beyond inefficient, because backblaze is always going to win on price due to vertical integration.
Adding a "distributed" network in there is extra points of failure, not less. But in crypto, price tends to not care about actual efficiency or utility at all, and is really just a roulette wheel of ticker symbols. Disclaimer: founded a crypto.
Adding a "distributed" network in there is extra points of failure, not less. But in crypto, price tends to not care about actual efficiency or utility at all, and is really just a roulette wheel of ticker symbols. Disclaimer: founded a crypto.
> But multiple sources say that a large percentage of those tokens had been unilaterally distributed by CEO Juan Batiz-Benet to himself and early employees for less than a penny each, and that he has continued to make such distributions in the years since.
> Sources also say that no tokens were distributed to shareholders and that it often was difficult to get questions answered.
I think this highlights where it's really difficult to be a young founder. Giving your investors news you know they won't want to hear isn't a fun conversation but it's necessary. And the longer you avoid those difficult conversations the harder it is to recover the relationship and the closer you get to running afoul of your duties.
> Sources also say that no tokens were distributed to shareholders and that it often was difficult to get questions answered.
I think this highlights where it's really difficult to be a young founder. Giving your investors news you know they won't want to hear isn't a fun conversation but it's necessary. And the longer you avoid those difficult conversations the harder it is to recover the relationship and the closer you get to running afoul of your duties.
And the more it looks less niave / akward as it does something else.
So how are the economics of decentralized storage solutions supposed to work? They don't have the economy of scale that big providers (eg. aws, google, backblaze) have, but yet they're somehow able to offer the service at a cheaper price?
The idea is that it's a technology to unlock the free space on the hard drives you and I own, which we're currently not monetizing at all. I'm not sure that even that ends up working, but it's not meant to scale indefinitely.
>The idea is that it's a technology to unlock the free space on the hard drives you and I own, which we're currently not monetizing at all
Right now backblaze b2 charges $0.005 (half cent) per GB. This is probably an upper bound on what decentralized storage services can charge. I sampled some computers on bestbuy and found that most of them come with 1TB storage (this excludes computer with SSDs, which have less). This probably translates into 500GB of free space that the average person can rent out, which works out to... $2.5/month. If we factor in a modest electricity consumption of 30W for 24hrs/day, 30 days/month, that's 21.6kWh, or $2.16 in monthly electricity costs (assuming 10 cents per kWh). So best case, you're going to be making $2.84 per month per computer, which doesn't seem worth it. In reality it's probably worse because sia's currently paying $3.68/TB, which works out to a loss of $0.32/month.
Right now backblaze b2 charges $0.005 (half cent) per GB. This is probably an upper bound on what decentralized storage services can charge. I sampled some computers on bestbuy and found that most of them come with 1TB storage (this excludes computer with SSDs, which have less). This probably translates into 500GB of free space that the average person can rent out, which works out to... $2.5/month. If we factor in a modest electricity consumption of 30W for 24hrs/day, 30 days/month, that's 21.6kWh, or $2.16 in monthly electricity costs (assuming 10 cents per kWh). So best case, you're going to be making $2.84 per month per computer, which doesn't seem worth it. In reality it's probably worse because sia's currently paying $3.68/TB, which works out to a loss of $0.32/month.
This line of thought needs to noticed be much more. While I was initially also very excited about distributed/decentralized processing/filesharing systems, this exact type of economic calculation seems to make the existence of many small, personal nodes in such networks unlikely. Even ignoring the electricity and network cost, if the setup and maintenance of such systems takes more than a few minutes per month, it just won't be worth it for the majority of potential providers. They would have to be zero-click installs, daemons in the background, unnoticeable, without requiring any attention from the user, despite issues like moderation.
Makes me wonder how the distribution on other filesharing/torrent networks looks like.
Another line of questioning I have is about the possible effects of this system should it become popular. Cryptocurrency mining caused huge spikes in graphics card prices - will the same apply to high-capacity harddisks, due to people trying to run mini-datacenters for profit?
How much storage will the Filecoin network be able to provide? How would a hypothetical large storage supply interact with pricing models of other providers? And on a more optimistic note, will it enable individuals to develop a new class of programs using lots of storage which aren't possible currently, technically or economically?
Makes me wonder how the distribution on other filesharing/torrent networks looks like.
Another line of questioning I have is about the possible effects of this system should it become popular. Cryptocurrency mining caused huge spikes in graphics card prices - will the same apply to high-capacity harddisks, due to people trying to run mini-datacenters for profit?
How much storage will the Filecoin network be able to provide? How would a hypothetical large storage supply interact with pricing models of other providers? And on a more optimistic note, will it enable individuals to develop a new class of programs using lots of storage which aren't possible currently, technically or economically?
>Makes me wonder how the distribution on other filesharing/torrent networks looks like.
I think the key difference is in filesharing networks, there are tens/hundreds/thousands copies of data, and each peer can jettison the data at any time without penalty. In contrast, storage networks (I'm using sia as an example here) only have three copies (by default), require upfront commitment (6 months by default), and you stand to lose your collateral in the event you delete the data prematurely. The latter two properties exist to counteract the unreliability associated with only having 3 copies if peers can randomly drop out at will.
>will the same apply to high-capacity harddisks, due to people trying to run mini-datacemters for profit?
Theoretically no. Presumably because every gigabyte of storage that's being bought for the storage network, is every gigabyte that someone doesn't have to buy to store their data.
I think the key difference is in filesharing networks, there are tens/hundreds/thousands copies of data, and each peer can jettison the data at any time without penalty. In contrast, storage networks (I'm using sia as an example here) only have three copies (by default), require upfront commitment (6 months by default), and you stand to lose your collateral in the event you delete the data prematurely. The latter two properties exist to counteract the unreliability associated with only having 3 copies if peers can randomly drop out at will.
>will the same apply to high-capacity harddisks, due to people trying to run mini-datacemters for profit?
Theoretically no. Presumably because every gigabyte of storage that's being bought for the storage network, is every gigabyte that someone doesn't have to buy to store their data.
Electricity consumption is important and there’s a wear and tear factor: if it’s not a computer you leave running 24x7, it’ll break sooner and given that SSDs have a duty cycle you’re cutting into the service lifetime of the device. I’m not sure anyone doing this to make a few bucks is going to think that’s worthwhile.
The technology behind Filecoin is very impressive. I can’t wait for the mainnet to be released so I can continue to use S3 as I always have. :)
This project has always felt DOA to me - I can't think of any other possibility than the first adopters for this product being distributers of child porn over just about anything else.
Of course, you don't like it because it's blockchain, so it must be for child porn and criminals.
nope I like some projects, actually, but if you spin up a node you have no control over the content that is stored on your computer.
if you really think the first adopters are going to be sharing cat pics you're being incredibly naive.
if you really think the first adopters are going to be sharing cat pics you're being incredibly naive.
I don't have the expectation that it will be used only for sharing cat pics. Do you only think in extremes? Of course that any permission-less technology will be used for nefarious purposes, among other, but trumpeting the child porn argument immediately shuts down any nuanced discussion.
every file storage system has to deal with child porn eg dropbox, google drive, amazon, fb, etc etc. the advantage is they can easily convert files to hashes and delete and remove content at scale + work with law enforcement to find and arrest distributors.
can filecoin do that? obviously not. the whole point of being decentralized is that that kind of action is not possible. why wouldn't that be incredibly beneficial to any distributor of any type of illegal content that would otherwise be removed from the centralized storage systems?
can filecoin do that? obviously not. the whole point of being decentralized is that that kind of action is not possible. why wouldn't that be incredibly beneficial to any distributor of any type of illegal content that would otherwise be removed from the centralized storage systems?
How does AWS deal with encrypted child porn that sits on their servers? They don't because they have no clue about it. How does Comcast deal with in-transit child porn that passes through their routers? They don't because they don't have a clue about it. The same thing applies to filecoin/ipfs. If you host some encrypted cp files and nobody knows about them, then thats that. If the FBI and subsequently you find out that you have these files, you will remove them and then thats that. Obviously we have to do our best to get rid of cp in our societies but that doesn't mean that we can always solve it technically. Do you also support encryption backdoors? If you do, then I disagree with you but I respect your principled stance.
> If the FBI and subsequently you find out that you have these files, you will remove them and then thats that.
Sorry, what? How do you imagine that works? Wouldn't it actually constitute destruction of evidence, which is a felony?
Sorry, what? How do you imagine that works? Wouldn't it actually constitute destruction of evidence, which is a felony?
That's not what I meant. Liability laws for people/organisations that provide a digital service differ from jurisdiction to jurisdiction, but I would presume that if the FBI identifies that you host some encrypted cp files, without you knowing, you will at least get the benefit of the doubt and be able to prove that you couldn't know they were cp.
In the situation that you somehow get the unique hash for the encrypted CP files before the FBI can tell that you host them, I don't know what would be your legal responsibility. But naively thinking about it, I would expect a good citizen to delete them, therefore not contributing to spreading cp around.
In the situation that you somehow get the unique hash for the encrypted CP files before the FBI can tell that you host them, I don't know what would be your legal responsibility. But naively thinking about it, I would expect a good citizen to delete them, therefore not contributing to spreading cp around.
I'm not sure why exactly you would presume that? If you need to "prove you couldn't know," that happens in court, after you are charged with the very serious crimes and have all electronics you own confiscated.
edit: As to your second paragraph, I'm not a lawyer but I'm pretty sure that would technically be felony destruction of evidence (odds of prosecution being another question entirely).
edit: As to your second paragraph, I'm not a lawyer but I'm pretty sure that would technically be felony destruction of evidence (odds of prosecution being another question entirely).
That doesn’t always happen in court. Indeed the FBI will confiscate your electronics but after their investigation they might decide to press charges or not. I am curious if this situation was tested in court before: storing encrypted files as part of a p2p network, without having the ability to know what’s inside those files. If you are automatically liable for the contents of the files you store, even if they are encrypted and you have no awareness of what’s inside, then it would make p2p networks close to impossible. I would then also wonder how a provider like AWS can have safe harbor, while an individual wouldn’t.
> they might decide to press charges or not
Exactly. In your initial post, you claimed it was a foregone conclusion that they would decline to press charges. And I don't know about you, but having my electronics confiscated for an indeterminate length of time would be more than bad enough. How are you even going to pay your attorney, if you can't do your job without a computer?
I'm pretty sure that in the end, you wouldn't be liable. But you might have to prove it. For example, it's perfectly legal to run a Tor exit node in the US. It's still strongly advised that you don't do it from your home, however.
Exactly. In your initial post, you claimed it was a foregone conclusion that they would decline to press charges. And I don't know about you, but having my electronics confiscated for an indeterminate length of time would be more than bad enough. How are you even going to pay your attorney, if you can't do your job without a computer?
I'm pretty sure that in the end, you wouldn't be liable. But you might have to prove it. For example, it's perfectly legal to run a Tor exit node in the US. It's still strongly advised that you don't do it from your home, however.
I personally don't think that "it would help criminals" is a good argument against any piece of technology nowadays. Distributors of illegal content already have, TOR, torrents, offshore servers and probably hundreds of other custom solutions at their disposal, so yet another distribution network does not seem like a real concern.
I do however see how the fear that one's servers might be used to store CP or equally problematic content could stop Filecoin and similar systems from getting adoption.
I do however see how the fear that one's servers might be used to store CP or equally problematic content could stop Filecoin and similar systems from getting adoption.
[deleted]
None of the blockchain storage projects that I've seen have Freenet-style deniable storage. Given that they leave an audit trail on a public blockchain, they're arguably even less private than S3-style cloud storage. Basically Filecoin et al. look like they're not useful for child porn.
well it's not going to be used to store cat pics
point is there will be illicit content being shared, and why would I want to spin up a node and be roped into some FBI investigation because my computer has bits and pieces of the illicit content they are looking for?
whatever tiny reward they offer isn't worth it
point is there will be illicit content being shared, and why would I want to spin up a node and be roped into some FBI investigation because my computer has bits and pieces of the illicit content they are looking for?
whatever tiny reward they offer isn't worth it
> point is there will be illicit content being shared
You could have just said that, or 'pirated movies', but neither are as inflammatory are they? Instead you chose to make the most offensive assumption you could think up.
You could have just said that, or 'pirated movies', but neither are as inflammatory are they? Instead you chose to make the most offensive assumption you could think up.
It's not about being inflammatory, but about illustrating a key risk - child porn is pretty much unique compared to other illicit content in that possession alone immediately makes you into a felon; it's not a civil issue like pirated movies but a crime, and malicious intent or even knowing about the content is not necessary to make you guilty, unlike pretty much everything else. On the other hand, attempts to distribute child abuse imagery are sufficiently common so as to consider it a real risk, not some unlikely hypothetical issue that's not going to materialize.
So for any service that's going to put random files on an end user device it's very relevant to ask the particular question "how are you going to ensure that child porn does not get put there?", with the explicit focus on child porn - it's acceptable if the service has no solution for pirated movies, because if pirated movies get put on someone's PC without their knowledge, that's not going to them in jail, but for child porn at least some answer is mandatory. For example, at the very minimum, censorship of known bad file hashes, such databases exist - of course, that's circumventable by e.g. encryption, but it would help from the legal perspective.
So for any service that's going to put random files on an end user device it's very relevant to ask the particular question "how are you going to ensure that child porn does not get put there?", with the explicit focus on child porn - it's acceptable if the service has no solution for pirated movies, because if pirated movies get put on someone's PC without their knowledge, that's not going to them in jail, but for child porn at least some answer is mandatory. For example, at the very minimum, censorship of known bad file hashes, such databases exist - of course, that's circumventable by e.g. encryption, but it would help from the legal perspective.
if you really think the earliest adopters of this project are going to be sharing pirated copies of The Avengers over child porn you don't understand anything about the internet and incentives
Have a look at what ipfs actually does. The nodes involved not only don't try to hide/obscure any metadata, they will share it with anyone running a DHT node and your queries will be pretty much public. Ipfs is probably the worst solution for distributing illegal content. The incentives there are actually to use just about anything else.
Why does your understanding of the internet dictates that most early adopters of tech are mentally ill paedophiles?
Paedophilia is not like theft, it's only attractive to a small subset of people.
Paedophilia is not like theft, it's only attractive to a small subset of people.