-
Notifications
You must be signed in to change notification settings - Fork 11
Is it possible to store private objects in ipfs without encrypting them? #181
Comments
tl;dr check out peergos :) https://github.com/Peergos/Peergos Rule of thumb: data added to IPFS generally isn't private, unless you 1) encrypt it, or 2) never connect your node to the network. The former will be a part of IPFS itself in the near future, the latter is currently brittle and needs better support for ensuring you really don't connect. For fetching, you usually need to know the respective hash. Because of the way content routing in IPFS currently works though, it's possible to write a tool that listens for so-called "provider records". Everytime you add something to IPFS, your node becomes a provider of that thing, and broadcasts the hashes it provides to the network, so that other nodes can respond to queries for the location of these. |
Oh sorry, I just realized you asked explicitly for "without encryption". What I wrote about provider records is still relevant I think. About having your own network:
Note that if you get connected to the public network once, nodes will remember your address, and under certain circumstances keep connecting to you. You can mitigate this by changing the port or address IPFS listens on (see 2). |
There's a pretty cool proposal for private networks here btw: ipfs/notes#146 |
Thanks! Leaving this open for record, I suppose someone with tag-setting abilities should add tag |
Great, obliged! |
This issue has been moved to https://discuss.ipfs.io/t/is-it-possible-to-store-private-objects-in-ipfs-without-encrypting-them/460. |
In order to fetch an ipfs object, one needs a hash. Does this hash sometimes leak to other nodes who didn't know it beforehand, or can one rely on the fact that in order to fetch an object one has to know the hash in some way?
Along the same idea, is it possible to store data pinned in an ipns record privately, if the ipns record is kept private? (this question assumes the ongoing work on using an ipns key different from the node ip is complete)
The text was updated successfully, but these errors were encountered: