Re: [xdi] More on merging graphs and the "graph-relative vs. authority-r

Subject: Re: [xdi] More on merging graphs and the "graph-relative vs. authority-relative" issue

On Tue, Nov 26, 2013 at 2:53 AM, Markus Sabadello <markus.sabadello@xdi.org> wrote:

Leaving aside the "big" point for a moment, here are a few smaller comments on the side..

Markus

On Mon, Nov 25, 2013 at 5:52 PM, Drummond Reed <drummond.reed@xdi.org> wrote:

#2: Every Message Is a Merge

The second advantage of keeping an XDI graph as strictly a repository of XDI statements at a network endpoint is that we can very strictly define XDI messaging as a merger of at least two graphs:

The XDI message graph (which itself is a valid XDI graph that can be added to any other XDI graph).
Any graph that is a target of the message.
This logical definition is true even if neither the sending or receiving graphs actually keep a copy of the message (i.e., they do not log messages).

Note that an XDI message that includes a $set operation is a merger of THREE graphs: the message graph, the target graph, and the inner graph that is the object of the $set operation.

In my current implementation, the object of $set can be an inner graph like you say, but it can also just be an address, e.g.

=markus[$msg]!1$do/$set/=markus<+email>

Yes, that's fine. The object XDI address is just a compact form of an XDI statement that would otherwise be in an inner graph. So in effect this is equivalent to:

=markus[$msg]!1$do/$set/(=markus//<+email>)

This very strict definition of XDI messaging has several advantages:
It makes it clear that every XDI message must be a globally unique subgraph. This way it can be added to any target XDI graph without conflict.

But nobody can check or enforce such uniqueness.

In theory you could check on it by querying the target graph. But you're right that enforcement is only through spec compliance.

Should we stop doing [$msg]!1 and always do UUIDs from now on?

You and I just had a long conversation about that - I'll post a separate summary of that. But the short answer is "yes" if the goal is for the message ID to be globally unique.

If uniqueness and message logging are not desired in a particular scenario, would anything be wrong with just doing $msg (entity singleton) instead of the entity collection pattern ?

This subgraph MUST be a subgraph of the XDI authority representing the sender. This makes it unambiguous who is responsible for the message.
It makes it clear that every XDI message, even a $get, is a state change in the target graph. In other words, just receiving the message is a state change—a merger of the message graph with the target graph, against which other rules can be triggered.

This is very theoretical, in practice no actual state change would occur from a $get (unless you log the message).

True.

What would it mean to "trigger rules" in this case?

If the target XDI server was processing events, then the message could be an event trigger.

Messaging processing is semantically precise. Every message is a strict graph merge operation, and a $set message is a second merge of the object inner graph with the target graph.

#4: All Authority is Exerted Via Authority Subgraphs

My final set of throughts about the separation of graphs and authorities is about the implications that all authority in XDI is exerted through authority entities and the subgraphs rooted on them.

As mentioned above, the first implication is that all link contracts MUST be authority-relative, because only an authority can exert control over a link contract.

And an XDI server would enforce this, i.e. an authority can't write a link contract to other parts of the graph?

Yes. And this helps deal with the unbounded $set problem.

The second implication is that one authority can still exert control over whether a second authority can write to an XDI graph by virtue of a link contract in that graph between the first authority and the second. For example (note that all of these examples use cloud names for simplicity):

=drummond$to=markus$from+friend$do/$set/=markus

This link contract gives Markus permission to write to his own authority space in the (=drummond) graph. This includes XDI messages, of course.

A third implication is that public link contracts are just like any other link contract except expressed for the $anon authority.

=drummond$to$anon$from$public$do/$get/=drummond$public...

And a final implication is that "root" link contracts are just like any other link contract except they are self-reflexive:

=drummond$to=drummond$from$do/$all/=drummond

Are you suggesting we use these new patterns for the public and root link contracts?

Yes. But let's explore this.

Would this just be a convention, or would the link contracts not work if they are at a different location of the graph?

I think that these two standard link contracts would need to be at these locations, i.e., following these template patterns. Other link contracts could in theory be at other locations inside an authority subgraph, though I'm guessing that the most common pattern will be to simply have a collection of link contracts directly under the authority root, and then have named singletons that point inside this collection.

=Drummond

Net net: I believe authority-relative link contracts can give us 100% of the control previously expressed via graph-relative link contracts without any of the problems associated with mixing graphs and authorities.

=Drummond

xdi message