> * I want to have my photo library on IPFS and add to it from anywhere.
I personally wouldn't keep my private photos on a public network, but everyone is different. You should be able to do this today, maybe you're saying that the client software for doing this is missing? Because the protocol would support it, but I'm not aware of any clients that would help you with this.
> * I want to be able to share anything on IPFS, and if someone else has already uploaded it for the upload to be instant.
You don't really "upload" anything to IPFS, ever, that's not how the protocol works. You "provide" something and then if someone requests it, you upload it directly to them. So in that way, "uploads" are already instant if the content already exists on the other node.
> * I want all the storage on my phone/laptop/whatever permanently full of other peoples stuff, earning me credits to store my own data.
> * I want my stuff reed-solomon encoded with lots of other data, so that in case of a failure of a chunk of the network, my data is still recoverable.
These are both "solved" by Filecoin rather than IPFS, although you can solve the second one by yourself with IPFS by just running multiple nodes you yourself own. But the whole incentive part is (rightly) part of Filecoin rather than IPFS.
> * I want the network to be fast and reliable with excellent sharding of data and minimal hotspotting.
> I personally wouldn't keep my private photos on a public network, but everyone is different.
IPFS needs transparent encryption yesterday. I tried to start a discussion and even made a rough design but they don't seem interested.
They have added some basic protection where a node won't serve content to another node without knowing the CID but this isn't the same level of security as E2EE.
I think the encryption key should be transmitted with the CID but separable. So that you can pin data with just the raw CID but share data easily with CID+key.
You could already add E2EE encryption yourself, just encrypt the content before you hash it and share the hash?
Still, I wouldn't want anything I want to be private to be on a public network, be it IPFS, S3 or the internet at large. Who knows when the encryption will be broken? Simply too little benefits compared to the massive drawback in case the encryption doesn't hold in the future.
Yes, but having it be disjointed from the protocol adds friction. You can't just browse the files using native tools and gateways. I think it would be great to be built-in.
In fact I would argue that all data should be encrypted. But by default it could be encrypted with its own hash or similar so that it can still be deduplicated but has strong protection from people who don't already know the content (or hash) and can be pinned on untrusted nodes. This would resemble the Google Docs "public link" sharing. The only downside would be slight CPU overhead and longer keys.
I'm surprised that nobody talks about content-addressed encryption with IPFS. It would be the perfect fit for IPFS. Content-addressed encryption uses the hash of the content as the encryption key. Which means don't need to transmit an extra key. And that anybody who has the original hash can access the encrypted version.
> Yeah, I think content-addressed encryption is a good default. It means that anything you add is only accessible to those you share it with.
My first thought about that is a problem around how hashes gets passed around. When you add something to IPFS, it "provides" the resulting hash to the DHT (the submission article goes more into this), so other nodes know how to get it. If you then use the same hash for encrypting the content, it's basically as worth as using no key, as other nodes already know the hash because your node told them about it.
So, lets not provide the hash when you add it then? But then the whole content-discovery part falls apart, how are nodes supposed to find the content if no one knows who has what hash?
In the end, it sounds like a simple idea, but I'm not sure it'd provide value on a public network like IPFS.
You use different hashes for discovery and encryption.
One method is use HASH(0 || content) for discovery and HASH(1 || content) for encryption.
You could also use HASH(content) for encryption and HASH(HASH(content)) for discovery.
(Talk to a real cryptographer to ensure that this is both theoretically sound and robust against likely algorithm vulnerabilities)
As long as you can't go from the discovery key to the encryption key you should be fine.
IIRC this is already done. I think they do something like HASH(CID) for publishing on the network, but before the data is sent to the node they have to prove that they know CID. This provides protocol-level protection this content-based encryption. (Although it has downsides such as not being able to store encrypted data on untrusted nodes)
> I personally wouldn't keep my private photos on a public network, but everyone is different.
Well, that's exactly the problem, isn't it? IPFS could be extremely useful for local and private storage, as it provides a network file system with proper directories, an optional HTTP interface, content addresses and an fuse implementation to mount it on Linux, along with automatic distribution and caching of the data. Those are all excellent features that I haven't really seen in any other system.
But the actual support for local or private hosting is basically non-existent. On IPFS everything is public all the time. The whole thing is way to much focused on being a globally spread protocol, while it neglects the benefits it could provide on the local PC, by just being a file format.
What I am missing is something like Git build in top of IPFS hashes. Something that allows me to manage my files on my local PC without any of the networking, but with the content addressing. Something that allows me to quickly publish them to a wider audience if I desire, but doesn't force me to. Or even just something I can use as a way to access my local files via content address instead of filename.
> You don't really "upload" anything to IPFS, ever, that's not how the protocol works. You "provide" something and then if someone requests it, you upload it directly to them.
This model should be changed... I should be able to just send something to the network, having other users store it for me, and come fetch it back later.
The whole idea that I am constantly online 'pinning' files is a bad one. The whole idea that I must store the specific files I want to make available to others is also a bad one. The network protocol should mix file data beyond recognition, and the exact data on my hard drive should have little correlation to the data I specifically am sharing with others.
That particular thing is one of the fundamentals of the protocol. If you want something else, then IPFS really isn't what you're looking for. If that model is what expected from reading the landing page, then I guess the landing page doesn't clearly communicate how it works.
What you're asking for is a bit like asking Bittorrent to suddenly change their model to a model where people can push data onto other nodes.
If that is truly what you want, probably something like Freenet (https://en.wikipedia.org/wiki/Freenet) would be more suitable, as it's highly unlikely IPFS would change the protocol in such a major way.
But that model also sucks. People have to contribute a pool of storage to the network, and data is spread through it by uploads and usage. It's extremely prone to losing data especially with big files, and it's low capacity because content needs a lot of duplication to actually be reliably retrievable.
And if nobody wants it for long enough it'll fall off the network entirely.
> * I want to be able to mount / as IPFS and know that I can boot linux from anywhere.
A starting point: https://github.com/magik6k/netboot.ipfs
> * I want to have my photo library on IPFS and add to it from anywhere.
I personally wouldn't keep my private photos on a public network, but everyone is different. You should be able to do this today, maybe you're saying that the client software for doing this is missing? Because the protocol would support it, but I'm not aware of any clients that would help you with this.
> * I want to be able to share anything on IPFS, and if someone else has already uploaded it for the upload to be instant.
You don't really "upload" anything to IPFS, ever, that's not how the protocol works. You "provide" something and then if someone requests it, you upload it directly to them. So in that way, "uploads" are already instant if the content already exists on the other node.
> * I want all the storage on my phone/laptop/whatever permanently full of other peoples stuff, earning me credits to store my own data.
> * I want my stuff reed-solomon encoded with lots of other data, so that in case of a failure of a chunk of the network, my data is still recoverable.
These are both "solved" by Filecoin rather than IPFS, although you can solve the second one by yourself with IPFS by just running multiple nodes you yourself own. But the whole incentive part is (rightly) part of Filecoin rather than IPFS.
> * I want the network to be fast and reliable with excellent sharding of data and minimal hotspotting.
You and me both :)