-
Notifications
You must be signed in to change notification settings - Fork 11
Private/personal use of ipfs? #4
Comments
Currently, we cannot guarantee that other nodes cannot connect to you, (we are planning on having such a feature). The best you can do currently is set all your nodes to bootstrap to eachother (and not our public bootstrap nodes) and hope that nobody else does an 'ipfs swarm connect' on your peer. |
this is a feature-set we care about supporting though, so we'll build facilities to let users make it easier to easily organize private networks. One easy hack you might try right now is to firewall your nodes off-- i.e. only allow traffic you want to allow.
we still need to do an example (see ipfs-inactive/examples#3) but poke at
Yeah ACLs + capabilities will be part of ipfs-- this is a bit low on our PQ right now though-- (feel free to take a stab at it though-- i can lift up specs around this if you want to) |
👍 to this. I have been looking for a durable long-term data storage system for a long time, and ipfs seems perfect. I would love to be able to setup a private system with a couple of servers and a local copy. |
👍 to this |
You might want to also check out Camlistore, which is similar to IPFS in many ways, and designed from the ground up as a personal storage system. |
@harlantwood Thank you! I will give Camlistore a try. |
Would it make sense to for me to encrypt personal files and store them on the public IPFS? That seems simpler to me, since I'd want all my computers connected to the public IPFS anyway. Also since layering an encrypted filesystem on top of IPFS wouldn't require any changes to the IPFS code. Or would this be risky or inefficient somehow? |
It doesn't seem like it should be an issue. It just add an extra layer of complexity. I have already stored some smallish encrypted backups over IPFS. |
Yep, that works fine, and the way i store + move personal files. We'll have native encryption modes later on, but we've some more pressing things to do at the moment. |
So I assume you can add an encrypted sparsebundle to IPFS, right? In the end (in a Unix sense & from the "outside") it's just a directory with files in it. But would it need an ipns entry if I add stuff to its volume or edit files on it? The sparsebundle directory contents will change (at the very least some added files), and then the parent hash will also change, correct? But is there a way to make another node pin the sparsebundle? If I simply add the sparsebundle, it'll just stay local, as far as I can gather. If I collaborate on a project, for example, my colleagues will pin my sparsebundle to their ipfs node, and then they can start working on its volume's contents, when finished, update the ipns etc. But what if it's just a sparsebundle for my own private stuff? Nobody knows about it, ergo nobody will pin & seed it, i.e. there's no actual backup of my data in the IPFS swarm. Or am I missing something? |
This issue was moved to https://discuss.ipfs.io/t/private-personal-use-of-ipfs/350 |
Have anyone thought for a moment about possible implications of storing encrypted content on a permanent network filesystem like IPFS? You have "versioning" available by default and currently selected crypto may work well, but what about the future? what if currently strong crypto algorithms are being considered weak and easily hackable/decryptable in the future? you won't be able to remove your "encrypted", but weakened content from IPFS, per design. How would you protect yourself from information leakage from such - say - containers encrypted with then-weakened algorithms to begin with? |
Thought about this too. As for quantum computers, see this post on asymmetric vs. symmetric algorithms. So SHA-512 (and probably even SHA-256) is still safe, and a DMG with AES-256 encryption still offers the same protection as one with AES-128 today. As for some additional security, I thought about maybe splitting files at a random point before adding it to the IPFS, so e.g. you first encrypt a DMG or archive as strongly as possible, then split it into at least two parts, then add those two parts to the IPFS. Only you, the originator, or a trusted person will know that those two IPFS hashes belong together. Question is if there is some record kept on when an object was added to the IPFS by which node, and if that record is public. If so, then such a method probably wouldn't work. But if it's an option, you could probably also build it into ipfs, e.g. as |
Then you could also extend as |
@marcxm @JayBrown we have decommissioned the ipfs/FAQ repo and moved everything to discuss.ipfs.io this issue was closed an moved to https://discuss.ipfs.io/t/private-personal-use-of-ipfs/350. If you post you comments there they will be seen by more people. |
Copied the posts over into the other forum. |
If I'm not mistaken, resolving ipfs/kubo#1972 (swarm address whitelist) will basically allow you to use ipfs privately. |
@futpib thank you! |
Also there is Private Network feature: ipfs/kubo#3397 (comment) |
There's a reference to using ipfs as a personal filesytem. Does this mean the go-implementation supports setting up a private swarm?
Can I run ipfs on my server with a few tb of disk at a hosting provider, and on my home-server in order to have two mirrors, and additionally on my workstation for pushing data (use my personal swarm as backup, with the benefit of local caching)? Can I do this easily, and still know that my data is secure (in transit etc)?
Are there any way to secure an ipfs daemon, only allowing a select few to access the data? Is there a scaleable way to do this (eg: groups/ACLs, rather than "list of keys")?
The text was updated successfully, but these errors were encountered: