[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xdi] More on merging graphs and the "graph-relative vs. authority-relative" issue
#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.
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.
- 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.
- 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.
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/=markusThis 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
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]