Re: Questions about link contract processing

[Markus Sabadello]

Hello,

A link contract specifies permissions on an entire subgraph.

So if you have $get permission on =!:uuid:1111#profile#address, then you can $get that address and everything under it.

To update something, you need $set permission.

A link contract can specify as many permissions on as many subgraphs as desired, e.g. you can have both:
(=!:uuid:1111/=!:uuid:2222)$do/$get/=!:uuid:1111#profile#address
(=!:uuid:1111/=!:uuid:2222)$do/$set/=!:uuid:1111#profile#address

Then it will allow $get and $set on that subgraph.

You can also have as many "separate" link contracts as you want and qualify them somehow, e.g.:
(=!:uuid:1111/=!:uuid:2222)#guest$do/$get/=!:uuid:1111#profile#address

$all is simply a shortcut for "all permissions".

Yes with $not$del you should be able to "exclude" a certain permission on a certain subgraph.

Regarding your last question, if you have an entire graph, then you can list all link contracts with LinkContracts.getAllLinkContracts(graph).

This is not very efficient for large graphs, since it simply searches all nodes.

I've been thinking for this reason there should be an "index" of all link contracts in a graph, using a link contract collection at the root with $refs to all the link contracts in the graph, e.g.:

[$do]!:uuid:3525/$ref/(=!:uuid:1111/=!:uuid:1111)$do
[$do]!:uuid:1182/$ref/(=!:uuid:1111/$public)$do
[$do]!:uuid:4637/$ref/(=!:uuid:1111/=!:uuid:2222)$do
[$do]!:uuid:9919/$ref/(=!:uuid:1111/=!:uuid:2222)#chat$do

If this existed, then you could get them all just with a $get on [$do].

I think with the new $connect operation I will also add logic that maintains such an index.

Markus

On Fri, Sep 11, 2015 at 6:41 AM, Ning Zhang <ni...@respectnetwork.net> wrote:

Markus,

I have a few questions about link contracts.

1. Assume that there is a link contract in =!:uuid:1111 to allow =!:uuid:2222 with full access of a subgraph, such as:

(=!:uuid:1111/=!:uuid:2222)$do/$all/=!:uuid:1111#profile$card

2. Suppose =!:uuid:2222 needs to update =!:uuid:1111#profile$card#address, could the XDI message sent by =:uuid:2222 include a more restrictive link contract such as the following?

(=!:uuid:1111/=!:uuid:2222)$do/$get/=!:uuid:1111#profile#address 

or should the link contract be the original one as specified in 1?

3. If there is an additional link contract such as:

(=!:uuid:1111/=!:uuid:2222)$do/$get/=!:uuid:1111#profile$card<#email>

will =!:uuid:1111 allow =!:uuid:to do $get <#email> only?

4. Is the following link contract disable $del operation on email by =!:uuid:2222?

(=!:uuid:1111/=!:uuid:2222)$do/$not$del/=!:uuid:1111#profile$card<#email>

5. Is there a generic way to obtain all link contracts in a XDI graph?

 

Thanks,

-Ning

[=Drummond Reed]

Markus, if you want an index of all the link contracts in the graph, why not:

$do/$is()/(=!:uuid:1111/=!:uuid:1111)
$do/$is()/(=!:uuid:1111/$public)
$do/$is()/(=!:uuid:1111/=!:uuid:2222)
$do/$is()/(=!:uuid:1111/=!:uuid:2222)#chat

--
You received this message because you are subscribed to the Google Groups "XDI2" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xdi2+uns...@googlegroups.com.
To post to this group, send email to xd...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/xdi2/CAJF45PTXu9m5-a1vfa7NHCFwbqN9j%2BkE2K8URbfP0C%3DJe9gQ9g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Markus Sabadello]

Hmm looks very elegant but I think it wouldn't work for link contract collections, e.g. if I had

(=!:uuid:1111/=!:uuid:2222)[$do]@~0
(=!:uuid:1111/=!:uuid:2222)[$do]@~1

But maybe I should use $has ? E.g.:

[$do]/$has/(=!:uuid:1111/=!:uuid:1111)$do
[$do]/$has/(=!:uuid:1111/$public)$do
[$do]/$has/(=!:uuid:1111/=!:uuid:2222)$do@~0
[$do]/$has/(=!:uuid:1111/=!:uuid:2222)$do@~1
[$do]/$has/(=!:uuid:1111/=!:uuid:2222)#chat$do

To view this discussion on the web visit https://groups.google.com/d/msgid/xdi2/CAAjunnZo-z91iG01eUbVyANHEhgS1f5dPgT6PyNuVcOtyxaKnA%40mail.gmail.com.

[=Drummond Reed]

That's funny. When I first read your original message, my reaction to seeing "index" was to think "$has". So I wrote that up. Then I considered it and thought that $is() was even more compact.

But you're right. $has should work. What's especially interesting is that you put the $has relation on a collection. I would not have thought of that, i.e., I would have done:

$do/$has/...

But [$do]/$has...enables the collection to be a "virtual collection", i.e., the collection can include members outside of the context tree of the actual collection, but they all have to be instances of $do (which is not true of $do/$has...).

Nice.

To view this discussion on the web visit https://groups.google.com/d/msgid/xdi2/CAJF45PQCrHo9mHKc1RyY4%3D9rN8Hs-AxuSSOfPsyx703NJ0qXjQ%40mail.gmail.com.

[Markus Sabadello]

Yes the message just needs to specify the link contract XDI address (including the $do), e.g.
(=!:uuid:1111/=!:uuid:2222)$do

If you have $get and a $not$get permission on exactly the same address, then the $not$get will "win", i.e. not allowed.

Markus

On Fri, Sep 11, 2015 at 5:01 PM, Ning Zhang <ni...@respectnetwork.net> wrote:

Markus,

Thanks for the reply.

For using a link contract, the message needs just specify the link contract XDI address, such as:

(=!:uuid:1111/=!:uuid:2222)

regardless which sub-graph it needs to access. Is this connect?

Also, what will happen if there are conflicting link contracts, such as the following?

(=!:uuid:1111/=!:uuid:2222)$do/$get/=!:uuid:1111#profile#address

(=!:uuid:1111/=!:uuid:2222)$do/$not$get/=!:uuid:1111#profile#address

Thanks,

-Ning

[=Drummond Reed]

Ning, just to note in your example below of the link contract address that needs to be referenced by the $do statement in the XDI message, it's not enough to specify the inner graph. You have to specify which $do context in the inner graph. In other words, the reference

(=!:uuid:1111/=!:uuid:2222)

is not enough. It needs to be at least:

(=!:uuid:1111/=!:uuid:2222)$do

Which is the root link contract of that inner graph. Or it could be any more specific link contract, e.g.:

(=!:uuid:1111/=!:uuid:2222)#friend$do

=D

--
You received this message because you are subscribed to the Google Groups "XDI2" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xdi2+uns...@googlegroups.com.
To post to this group, send email to xd...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/xdi2/CAJF45PR_%3DF4h9KTB2siuS%3DBxjkE%3D5JTi934cMhpLZ%3DTgBGYv9Q%40mail.gmail.com.

[Markus Sabadello]

I'd just be careful with the term "root link contract".

We usually use this term for a link contract that gives you full access to your own graph, e.g.

(=!:uuid:1111/=!:uuid:1111)$do/$all/

Or for other "full access" scenarios such as in a parent/child relationship.

So I'm not sure if we should call the link contract in Ning's example a "root link contract".

Even though it's directly under the inner root of the relationship, it may only have limited permissions.

Maybe call it the "default" or "unqualified" or "standard" link contract for that particular relationship?

Markus

To view this discussion on the web visit https://groups.google.com/d/msgid/xdi2/CAAjunnYg8pxx%2Bmt4H%3DUBxxZMmnqVx_LVHvY9-kqiTJCEcX297g%40mail.gmail.com.

[=Drummond Reed]

Since it is at the inner root level, should we call it the "relationship root link contract"?

To view this discussion on the web visit https://groups.google.com/d/msgid/xdi2/CAJF45PRMCvvy5c7d%3DVG6Bf0TrJUbOv31vRQFSJvFZSCjuDujbw%40mail.gmail.com.

[Markus Sabadello]

Don't know, I would avoid the term "root" altogether here, we've really been using it to mean "full access"..

Markus

To view this discussion on the web visit https://groups.google.com/d/msgid/xdi2/CAAjunnZsXic36u_A2%3DoPptFPJ_ww_-7TCdDtLMzMxv%2BG%3DjBY4w%40mail.gmail.com.