Provide a place for local private key/values or files

[mitar]

I am building an app on top of IPFS. I would need to store some key pairs. I am using IPFS for all my storage needs, but it would be great if I could also store some private key/values or files which I would know only a local instance could access.

For HTTP API, those requests to that API could be allowed only from localhost or something.

[hsanjuan]

I'm not sure I understand why you can't just save them directly to disk from your app. Somehow you want IPFS to have a feature that let's you put on it some content which is never meant to go out of your local disk and can only be read from it. So, just write to disk directly? :)

[Kubuxu]

@mitar probably means in browser

[hsanjuan]

ahhh, what about local storage then?

[mitar]

It can be both, but I agree, I could just store it myself. It just feels cleaner to me if all storage is done by IFPS. In some way an IPFS daemon could be accessed remotely by a web interface, while those private files could be stored alongside with the IPFS daemon.

[whyrusleeping]

@mitar could you provide a use-case-story type thing to illustrate the need better?

[mitar]

So I am developing a blockchain using Intel SGX on top of IPFS. I am using IPFS for storage of blocks and transactions, while a thin layer on top computes consensus. Now, the issue is that for that consensus layer, I have to generate a key pair to be able to use Intel SGX fully. And it should be stored with each peer/node of this blockchain network. So, I cannot store it in IPFS directly, I could store it on the disk myself, but then this nice abstraction layer breaks of IPFS being a distributed disk. :-)

It is not a critical feature. I am just sharing my experiences building an app on top of IPFS.

[jbenet]

This is relates to "Content Distribution Policies" -- we should be able to tell IPFS a policy that allows it to check whether an object should be:

• stored and shown only locally (ie user API but not to Network)
• distributed to the network broadly
• distributed to the network only to users with permission (PKI or bearers of a capability)
• etc.

We've discussed this elsewhere, but right now we dont have a good formal model for this.

@mitar are you interested in working with us in defining these policies? this is a bit of a research problem still because we havent surveyed literature for best ways to do this.

[mitar]

At the moment I am wrapping up my blockchain project (I will send you an e-mail about it), so I reported my experiences of what would make it easier to do, but are not really blocking things, because it is only a demo anyway. This also means that at the moment I sadly do not have time to contribute much more. :-(

But yes, "Content Distribution Policies" sound like a good approach.

[daviddias]

I would need to store some key pairs. I am using IPFS for all my storage needs, but it would be great if I could also store some private key/values or files which I would know only a local instance could access.

Currently, we expose datastore as a kv in js-ipfs. I know that @pgte uses it extensively for some of his projects.

I agree with you @mitar, it is super convenient, but as also mentioned in this thread, it will require ACL at some point, otherwise two apps sharing the same node will cause issues. What is the state of your use case @mitar?

[mitar]

I have finished my implementation, but I store keys for now by myself in my app.

Not sure how we would do ACL, but based on the fact that anyone currently being able to connect to my node through API can pretend to be my node, I think I would not worry about multiple apps stealing private keys: they anyway have an access to oracle (my node) to do things in the name of it, no?

[daviddias]

but based on the fact that anyone currently being able to connect to my node through API can pretend to be my node, I think I would not worry about multiple apps stealing private keys:

If that is the case you would be fine using the datastore API on js-ipfs.

they anyway have an access to oracle (my node) to do things in the name of it, no?

If your ACL is "whoever has access to the node, can change the data", then the ACL is happening outside of IPFS context. That is ok if you are running one node (or multiple) just for your own use. If you had to share that node instance then it would be an issue (the case here is having multiple apps that do not know each other previously and want to save resources by using the same IPFS node instead of spawning multiple).

Seems that you have a solution for your request. Let me know if working on the ACL issue is interesting for you :)

[mitar]

Let me know if working on the ACL issue is interesting for you :)

No time at the moment.