This page discusses the use of XRI syntax for peer-to-peer addressing in self-rooted, self-organizing communities.
Contents
Introduction
XRI syntax provides support for four types of root authorities:
- The IP address registry.
- DNS name registries.
- XRI global context symbol (GCS) registries.
- Global cross-references, which can be to any identifier that a community agrees to use as its root.
This page is about how the fourth option can be used to support peer-to-peer addressing, and how the four models can be mixed.
Bootstrapping from URIs or IP Addresses into XRIs
The following techique (suggested by Loren West, http://public.xdi.org/=Loren) illustrates how an XRI cross-reference can be used as an XRI authority (the first segment of an XRI) to discover the XRID for an addressing community, i.e., bootstrap up to the abstract XRI level from the concrete IP or URI level.
xri://(http://community-root-resolver.org)/...
This approach requires only the simple convention in an XRI resolver that if the first subsegment of the XRI authority is a cross-reference, and if that cross-reference is an http or https URI, that the resolver should request the XRID for that community from that URI. In other words, in the example above, the resolver would request the XRID for "(http://community-root-resolver.org)" from http://community-root-resolver.org.
Because URI syntax also supports IP addresses, the same technique will work there too. In other words, you could request the XRID for "(123.45.6.78)" from http://123.45.6.78.
Resolving Conflicts Between Independent Roots
The question has been asked, "What if two or more independent communities ignore the above advice to use a globally unique cross-reference as their root and instead choose conflicting relative identifiers to represent their root? How could these communities resolve that conflict and begin to safely cross-resolve XRIs?"
An example would be two communities who both choose the relative i-number !1000 as their root XRI. Under this root i-number, all other i-numbers would be unique, but because they both use the same root i-number, there could be an infinite number of collisions. For example, there would be no way to distinguish the following two XRIs that are identical in both communities:
Community A xri://!1000/!1234 Community B xri://!1000/!1234
The solution is for the two communities to federate by each establishing a unique i-number relative to another shared root, then cross-referencing their existing community i-numbers in this new shared context.
For example, if Community A and Community B agreed to use the new shared context root !1111, and establish that relative to this new root Community A would be !1111!A and Community B would be !1111!B, both communities can now reference all their existing XRIs in this new shared context without any collisions. For example:
Community A xri://!1111!A/!1000/!1234 Community B xri://!1111!B/!1000/!1234
Note that in this example, because the existing root i-numbers were relative, they could be merged directly below the new shared root. Had the two communities used a global i-number for their roots instead (for example, if they had both declared that their root was the global i-number !!1000), then decided to federate, XRI syntax would require the current i-numbers to appear as cross-references, as shown below:
Community A xri://!1111!A/(!!1000/!1234) Community B xri://!1111!B/(!!1000/!1234)
Q&A: Changes to Registries and Address Books
What changes would have to be made to the registries and/or people's address books? --FenLabalme
Each community root registry would need to add an entry recognizing the new shared root and its own identifier under the shared root. (In XDI universal graph terms, this would mean adding a synonym to the current logical root resource node and a backref to the new shared root node.)
Updating address books in each community could be an organic process. The first phase would not be to update the address books themselves but rather the community resolvers used by the address books. Each community resolver would continue referencing its own default root for unqualified addresses (addresses that do not use the new shared context), but would begin recognizing qualified addresses in the other community.
The second phase would be for the address books to be updated by adding XRI synonyms for every unqualified community entry. This would allow the same resource to be recognized both as an unqualified and a qualified community address. The community could slowly migrate over to using qualified addresses (like migrating from 5-digit to 9-digit zip codes) until the address books were updated.
Q&A: Collisions
Let's suppose that I have registered an i-number !!1002/!1234 Someone else, either unknowingly or by malicious design has created another global registry, and in it has registered the same i-number !!1002/!1234. When I receive a request for, say, data exchange, from !!1002/!1234, how can I be sure that it's the !!1002/!1234 in registry 1 that we're talking about? =vg
Resolvers are "married" to addressing communities. Just as each of us individually, when we hear a word, decide its meaning inside our own heads (or, if we don't know what it means, decide which dictionary or authority we will consult for the answer), every resolver is told by the authority responsible for configuring it what addressing communities it is part of. With an XRI resolver, this is accomplished by configuring it with the root XRIDs for each addressing community in which it will participate.
So any conflict between communities must be resolved at the resolvers. This can be done easily if the configuration authority follows the simple rule that no two root XRIDs may conflict. If that rule is in place, the problem described here is not technically possible. The fact that another resolver asks you, as an XRI authority, to resolve "!!1002/!1234" means that that other resolver has already made the trust decision that you are the authority it trusts for the answer. You simply respond with the XRID for the authority that YOU have registered as "!!1002", and your job as an authority is done.
So the only way the "Alternic" problem is possible is for another authority (competing or malicious) to get XRI resolvers to ask them as an XRI authority rather than you. And the only solution currently available to assist with that problem is XRI trusted resolution, in which the root XRIDs use certificates.
Status Note on the Topics Below
The balance of the content is currently questions posted by Fen Labalme regarding the use of p2p i-numbers with the Identity Commons i-broker code. They refer to XRI addressing examples at http://xrixdi.idcommons.net/moin.cgi/EgsInumberPolicies. THESE EXAMPLES ARE OUT OF DATE, so they appear here only for historical purposes.
Questions RE: I-numbers for Community Registries/Registrars
In the process of packaging the code so that it was possible for someone else to run it, I created an i-broker on my home machine. This pointed to a couple of problems that we need to solve for interoperability.
Each registrar needs to have a unique i-number. Right now, the 2idi global registrar has the i-number !!1002, and people get assigned i-numbers relative to this, e.g. =Fen has the i-number =!(!!1002/!1000.12b9)
New global registrars can follow the same procedure, after having been given a global i-number (e.g., !!1003)
But even after reading (note: I did not say fully understanding) the above I have several questions:
- What does a community registrar's i-number look like?
(note that sections 6 and 8 appear to have conflicting i-number values for @planetwork)
- A community gets an i-number in the space of the global registry under which is is registered.
so if @planetwork is @!(!!1002/!1000.8765) would @planetwork*jim be @!(!!1002/!1000.8765)/!90ab.cdef ?
what would @planetwork*jim*work look like?
what would @planetwork*jim/work look like?
what would @planetwork*jim/(+work) look like?
what if jim wanted to alias his @planetwork name to his global i-number =!(!!1002/!1000.2345)?
- A community gets an i-number in the space of the global registry under which is is registered.
- When developers pull down a copy of the i-broker with local registry capability, they will be creating their own unique number space. In order to keep it unique - and compatible - there should be a global mechanism for assigning them i-numbers. How can this be done, and what would the i-numbers look like?
when I created an i-broker on my home machine, I chose !!1002/1001 as my i-number. Does this look right?
Discussion:
Every new i-broker - and I expect there to be thousands within the next year - will have a local "community" registry available for use. This registry must have a unique identification number, which it can get from any "rooted" "parent" i-broker.
- by "parent" I mean that the i-number received by the "child" i-broker would be delegated under the parent's namespace.
- by "rooted" I mean that the parent has a proper i-number with a path to a known global registry.
I envision a "signup" page where one can go and get a unique i-number. 2idi would host the first one, but every i-broker should be able to create their own. Heck, every owner of an i-number ought to be able to generate an infinite number of i-numbers under their unique i-number space.
There are other options, too, as an i-broker in a P2P community might choose a unique MD5 or (better) SHA1 hash key as their cross-referenced root, e.g. (xriroot.a0fc532fd0508590e1b5ccb02bdf5d3366590200). But I'd like to stick with the rooted version for now and determine how these "child" i-numbers are formed. The current example is:
parent
i-number
2idi.com
!!1002
2idi.fen.net
!!1002/1001
Finally, there's the concept of segmenting spaces, e.g., having a number space used only for internal testing, such as the 10.x.x.x IP number space is used only for internal networks. Any ideas about this are welcome.
XRI Alternative Transport
Discussion regarding Addressing and/or Link layer concerns on non-TCP/IP networks
Freenet
Some ideas from moving data with FreeMail on FreeNet might be of use. Communication is possible even without a direct link.
The FreeMailDocs provide more information. I think the addressing scheme needs to be changed to reduce dependence on the particular network involved but the Rts/CtsProtocol may prove useful.
Could my MailSite contain my XRI resources and provide interaction, selectively exchanging information with others in an anonymous fashion via some means I can control? Could an ever-changing crypto footprint emulate an information server, authenticating the validity of the information and simultaneously cloaking bits from those not authorized?