IPLD resolver with access control

Help
,
1

I’m playing around building something like a distributed file system on top of IPLD, using js-ipfs.

Within this system, the objects look something like this…

{
    "Folder1": {
        "canRead":["publicKey1", "publicKey2"],
        "files":[
            "Folder2": {
                "canRead":["publicKey2"],
                "files":[
                    "cat.jpg": {
                        "link": {"/": "/ipfs/QmUmg7BZC1YP1ca66rRtWKxpXp77WgVHrnv263JtDuvs2k"},
                         "canRead":[ ],
                    }
                ]
            }
        ],    
    }
}

…where access to cat.jpg will be garanted only if the requester provides a valid signature for one of the keys within canRead for all of its parent parent objects (folders).

I’m trying to wrap my head around on what’s the best way to implement it.

I was trying to creatae a new IPLD resolver that handles the authentication, but that requires to modify the resolver functions signatures, to include the the requester authentication data.

Alternatively I could create gateway layer on top of IPLD that takes care of it, but it seems less elegant, and judging by the examples on the IPLD readme like following, it seems you guys have thought about permissioned access already.

{
    "files": {
        "cat.jpg": { 
        "link": {"/": "/ipfs/QmUmg7BZC1YP1ca66rRtWKxpXp77WgVHrnv263JtDuvs2k"},  
        "mode": 0755, <---THIS
        "owner": "jbenet"
        }
    }
}

Any suggestion on how should I do this?

Thanks! :slight_smile:

1 Like
2

I think putting it into the resolver (now called just js-ipld) would make sense. Couldn’t you just the options objects and add your own custom stuff there?

For your use case, would it make sense to have an optional callback function that is called on every node that is traversed? That function should then be able to signal “go on” or “abort”.

3

Using the options object and the callback function makes a lot of sense, but I’m not sure how to go about it…

I was trying to add a new resolver by using the API.

ipfs._ipld.support.add(multicodec, newResolver, util)

But this newResolver does not have acces to the options object.
Plus it forces me to add a new multicodec (although I just want to use the existing dag-cbor… so I was removing it and adding a modified version :confused: )

It seems that the resolvers are just meant to deal with the data structure itself and not logic.

If that’s the case, do I have to fork js-ipld ? Or there is a an API that I’m missing?

4

Btw @vmx , I’ve been digging into Noise Search. It looks awesome!
I got very excited because seems to fit very well with this file-system I’m dealing with.

The Query Language also looks very ideal for my purpose, which needs to be powerful but user-friendly :slight_smile:

  • Somewhere you mention that you like to integrate it with IPLD. What is the status of that?
  • I’m guessing that this integration basically means to be able to fetch and traverse IPLD links?
  • Regarding my original question about permissioned resolution? Would it make sense to use Noise itself instead of an IPLD resolver, and extend it to deal with the authentication?

I will probably bug you more about it once I get my hands dirty…

5

Thanks for digging deeper into this.

You are right that the options are not passed into the format implementations. Though I think it would be a good idea to have that. The interface for resolving is specified here: https://github.com/ipld/interface-ipld-format/tree/0ea0ec73769fde7b54b022d61d94d32cf4f63dc6#resolverresolvebinaryblob-path-callback

So I think it would make sense to add add options there, which would them have a property called ctx (or any better name) which can take any data coming from js-ipld which was passed in as options.ctx. Would you mind opening an issue on interface-ipld-format for this?

Adding a new multicodec makes sense to me as it really is some specific CBOR, which contains auth information and has logic to verify it. Though I’m not 100% sure, so i"m happy to discuss it.

As mentioned above, having a way to also express some logic like this within the format implementations makes sense.

As making all this work nicely will take some time, I’d start with a quick and dirty fork of js-ipld (especially to find the problems in the details), but would help us making this part of the main js-ipld.

2 Likes
6

Thanks, that was the intention.

Looking into IPLD+Noise is even part of my plans for this quarter. Though it’s lower priority then other stuff, but I really want to get to it.

That would be cool, but no. Noise will just index the JSON representation of whatever is in there.

I would do it in IPLD. I haven’t even thought about authentication in Noise. That’s a difficult problem for indexes. It surely would be cool, but I have no clue if or when that would happen in Noise.

Sure, I’m always keen to see people using Noise.

1 Like
7

Thanks for the fast feedback, super helpful!

Issue opened here

I need explore a little more since I’m not sure what approach to take still.
I do need something like Noise for complex queries. And I’m not sure if I can make it compatible with IPLD.

At the same time the structure I’m trying to represent is not a proper Merkle Dag, since it keeps mutating every time the user modifies a leave.
Basically I have a single huge IPLD CID that represents the whole user file-system, and only the leaves have IPLD links. Maybe I should just use plain JS object and only use IPLD to resolve the leaves?

8

For the time being I can just use a modified dag-cbor. Everything is very experimental and it does not make sense to to waste keys.

That said, maybe it makes sense to have a multicodec “experimental key”, so anyone who is playing around can use, without having to add it into the table.

Again, thanks for the ideas! :slight_smile:

9

I’m not sure what you mean with “plain JS objects”, but you can use IPLD also as a blob/key-value storage for your JSON.

10

@xavivives Did you built what you mentioned here?

11

I abandoned that particular matter, but is still subject of my interest and I will likely put focus back on it soon. If you resolve it, I’ll appreciate if you update this post.

Both Textile Threads and Ceramic Network have some sort of access control system on top of IPLD, depending on your use-case it make work for you.

1 Like