An attempt to structure the field.

[bug1]

Im having a bit of trouble following the two level communities in regard to the need for uniqueness.

If names are unique within a community (or hierarchy of communities), it offers the benefit that then name can be resolved without user interventions.

However it depends on a top level community that is globally unique, or it ends up back to where it started, the need for unique names within a community.

I think the hierarchy of communities is still a good idea, but we still need to solve the problem of the top level community.

If each community uses some sort of trust metrics to maintain itself independently, then the hierarchy probably doesnt need to be authoritative, its just there to solve the uniqueness problem by providing a context.

[jfw]

(12-18-2010 11:32 PM)Joe Wrote:  Not a two-level hierarchy, but rather associations.

Fully agreed. I just added the following sentence here: An outline of a possible lookup algorithm - which incidentally describes what the Askemos/ball implements to map host identifiers to ip addresses. (See for example a live "Host Map".)
((Whereby lookup algorithm links to Joes post.))

(12-18-2010 11:32 PM)Joe Wrote:  I have every confidence that the client will be able to return reasonable results without making Grandma answer name resolution questions.

Ah, I see the difference now: at the level you are talking about - mapping identifiers to ip addresses, you are right. Grandma will not dial them.

The problem I see is, how will Grandma - or a server administrator - join communities and deal with the fact that more than one registry resolves the same name - that is the her input - to different identifiers?

In other words: does IDONS stop after mapping identifiers to ip addresses, or shall it map user input to ip's?

[Joe]

(12-19-2010 01:38 AM)bug1 Wrote:  Im having a bit of trouble following the two level communities in regard to the need for uniqueness.

If names are unique within a community (or hierarchy of communities), it offers the benefit that then name can be resolved without user interventions.

However it depends on a top level community that is globally unique, or it ends up back to where it started, the need for unique names within a community.

I think the hierarchy of communities is still a good idea, but we still need to solve the problem of the top level community.

If each community uses some sort of trust metrics to maintain itself independently, then the hierarchy probably doesnt need to be authoritative, its just there to solve the uniqueness problem by providing a context.

Not a hierarchy of communities, but an association of communities. No top level is necessary or desired. Also a Name need not be unique within a set of communities or even within a single community. Multiple results will be differentiated by trust and by distance.

- Joe

[rev412]

(12-19-2010 10:03 AM)Joe Wrote:  Multiple results will be differentiated by trust and by distance.

So depending on where you are in the network and who you trust, the same name will resolve to different addresses. I'm not seeing how this works for the person whose friend sends them the latest cool URL or the email address of someone they should meet.

[Joe]

(12-19-2010 08:35 AM)jfw Wrote:  

(12-18-2010 11:32 PM)Joe Wrote:  I have every confidence that the client will be able to return reasonable results without making Grandma answer name resolution questions.

Ah, I see the difference now: at the level you are talking about - mapping identifiers to ip addresses, you are right. Grandma will not dial them.

The problem I see is, how will Grandma - or a server administrator - join communities and deal with the fact that more than one registry resolves the same name - that is the her input - to different identifiers?

In other words: does IDONS stop after mapping identifiers to ip addresses, or shall it map user input to ip's?

I was talking about the client requesting a Name to be translated to a returned Address. The intermediate Identifier mapping should be hidden from the client.

Grandma doesn't need to know that Identifiers even exist. The only awareness Grandma should have of Identifiers are that permanent URLs look weird, and that they continue to work even after the company has been acquired by another company.

How will the IDONS client make decisions about which returned result is "right"?

The client will receive a set of results, each of which matches the original query, but to differing degrees. Some will be much closer than others (smaller distance value), some may be explicitly trusted (though maybe not so much for Grandma), etc. After passing through those two filters, if it's still not clear which is the correct result, a Bayesian analysis may be used against a corpus of past results. Although we may be able to do most of the tuning automatically here, Grandma may have to get Grandchildren to help if manual intervention is required.

Also, there may be other server-side mechanisms we can use to incrementally suppress Names that the community finds undesirable for whatever reason.

- Joe

[Joe]

(12-19-2010 10:50 AM)rev412 Wrote:  

(12-19-2010 10:03 AM)Joe Wrote:  Multiple results will be differentiated by trust and by distance.

So depending on where you are in the network and who you trust, the same name will resolve to different addresses. I'm not seeing how this works for the person whose friend sends them the latest cool URL or the email address of someone they should meet.

(Jim-PC) *should* probably resolve to a different address for me than it does for you. This is a good thing. It transforms the virtual landscape into communities that can better serve users.

To send me a link to a cool web site, if it were relatively unique you could just reference it directly http://(Slashdot)/cool.htm. Or if you're concerned about it being overridden at the community level, you could send something like http://(Discussion forums)(Slashdot)/cool.htm or http://(Geek sites)(Discussion forums)(Slashdot)/cool.htm.

- Joe

[rev412]

(12-19-2010 11:27 AM)Joe Wrote:  http://(Geek sites)(Discussion forums)(Slashdot)/cool.htm.

So for this example, is the idea that (Geek Sites) and (Discussions forums) are not hierarchical (their order doesn't matter) and you're looking for the (Slashdot) that resolves to the same Identifier in two communities with those names (understanding that there may be many communities with the same names and many different (Slashdots) in each of them)?

[Joe]

(12-19-2010 01:04 PM)rev412 Wrote:  

(12-19-2010 11:27 AM)Joe Wrote:  http://(Geek sites)(Discussion forums)(Slashdot)/cool.htm.

So for this example, is the idea that (Geek Sites) and (Discussions forums) are not hierarchical (their order doesn't matter) and you're looking for the (Slashdot) that resolves to the same Identifier in two communities with those names (understanding that there may be many communities with the same names and many different (Slashdots) in each of them)?

Close. Rather than a hierarchy, just associations. I would be looking for (Geek sites) that know of (Discussion forums) that know of (Slashdot). I imagine a lookup like this resolving something like this:

Create a set of (Geek sites) then use them for resolution to create a set of (Discussion forums). Then use them to create a set of (Slashdot). Sort by distance, etc. and remove duplicates.

Because of the community qualifiers, if someone in my community created a (Slashdot) it would be skipped entirely or at least would have a greater distance than the "real" desired (Slashdot).

- Joe

[bug1]

So your association of communities is like keywords within twitter or tags on slashdot.org or freshmeat.net.

Hmm, I do think social sites seem to be evolving to use that aproach.

I wonder how it would play out in the long run in regard to community size, on one hand individuals would want to be in small groups where they have more control of uniqueness/trust, on the other hand they would want to be in big groups so its easier to find.

[Joe]

(12-19-2010 03:34 PM)bug1 Wrote:  So your association of communities is like keywords within twitter or tags on slashdot.org or freshmeat.net.

Hmm, I do think social sites seem to be evolving to use that aproach.

I wonder how it would play out in the long run in regard to community size, on one hand individuals would want to be in small groups where they have more control of uniqueness/trust, on the other hand they would want to be in big groups so its easier to find.

As counterintuitive as it may seem, they'd actually be harder to find in the larger communities because of duplicate names. The smaller communities provide a context that isn't otherwise present.

- Joe

[jfw]

(12-19-2010 04:12 PM)Joe Wrote:  As counterintuitive as it may seem, they'd actually be harder to find in the larger communities because of duplicate names. The smaller communities provide a context that isn't otherwise present.

So I understand: there needs to be some user control over name a resolution scheme like this
http://idons.askemos.org/SRS

Which means to me that the client side need most focus. How make I sure that:

1. home.me resolves to my home page
2. dad.mom is my grandfather
3. joe.gulfclub.me is the friendly guy
4. dad.joe.gulfclub is redirected to worst.enemy.wife.me
   

It's not that hard: tweak your personal DNS server. But that's the hard part!

[eternaleye]

(12-19-2010 11:27 AM)Joe Wrote:  

(12-19-2010 10:50 AM)rev412 Wrote:  

(12-19-2010 10:03 AM)Joe Wrote:  Multiple results will be differentiated by trust and by distance.

So depending on where you are in the network and who you trust, the same name will resolve to different addresses. I'm not seeing how this works for the person whose friend sends them the latest cool URL or the email address of someone they should meet.

(Jim-PC) *should* probably resolve to a different address for me than it does for you. This is a good thing. It transforms the virtual landscape into communities that can better serve users.

To send me a link to a cool web site, if it were relatively unique you could just reference it directly http://(Slashdot)/cool.htm. Or if you're concerned about it being overridden at the community level, you could send something like http://(Discussion forums)(Slashdot)/cool.htm or http://(Geek sites)(Discussion forums)(Slashdot)/cool.htm.

- Joe

I see a large assumption here. Looking at "Or if you're concerned about it being overridden at the community level", this implies that such things can be done. However, if each entity is in multiple communities, *how* exactly will such overrides take place? There would need to be some order of composition, which would need to be agreed to by all members of the community. <understatement>This seems slightly difficult.</understatement>

[Joe]

(12-24-2010 01:22 AM)eternaleye Wrote:  

(12-19-2010 11:27 AM)Joe Wrote:  

(12-19-2010 10:50 AM)rev412 Wrote:  

(12-19-2010 10:03 AM)Joe Wrote:  Multiple results will be differentiated by trust and by distance.

So depending on where you are in the network and who you trust, the same name will resolve to different addresses. I'm not seeing how this works for the person whose friend sends them the latest cool URL or the email address of someone they should meet.

(Jim-PC) *should* probably resolve to a different address for me than it does for you. This is a good thing. It transforms the virtual landscape into communities that can better serve users.

To send me a link to a cool web site, if it were relatively unique you could just reference it directly http://(Slashdot)/cool.htm. Or if you're concerned about it being overridden at the community level, you could send something like http://(Discussion forums)(Slashdot)/cool.htm or http://(Geek sites)(Discussion forums)(Slashdot)/cool.htm.

- Joe

I see a large assumption here. Looking at "Or if you're concerned about it being overridden at the community level", this implies that such things can be done. However, if each entity is in multiple communities, *how* exactly will such overrides take place? There would need to be some order of composition, which would need to be agreed to by all members of the community. <understatement>This seems slightly difficult.</understatement>

It's not an assumption, but a requirement. From Lauren's requirements post:

- Minimal constraints on name selections and changes
- No central registries

I didn't mean to imply a specific mechanism when I referenced the possibility of the name being overridden. I was just calling out the possibility that the same name may already be defined in the recipient's community. So the actual mechanism would simply be defining a name that happened to already be used somewhere else.

The slightly difficult part (definitely an understatement) is how to appropriately weight duplicate names so that the query is resolved in the correct context, thus returning the correct response.

- Joe

[eternaleye]

(12-25-2010 12:43 AM)Joe Wrote:  It's not an assumption, but a requirement. From Lauren's requirements post:

- Minimal constraints on name selections and changes
- No central registries

I didn't mean to imply a specific mechanism when I referenced the possibility of the name being overridden. I was just calling out the possibility that the same name may already be defined in the recipient's community. So the actual mechanism would simply be defining a name that happened to already be used somewhere else.

The slightly difficult part (definitely an understatement) is how to appropriately weight duplicate names so that the query is resolved in the correct context, thus returning the correct response.

- Joe

Regarding it being a requirement, not necessarily. I'm not entirely sold in the 'communities' concept, at least as it has been described so far, because of the great degree to which it subjectivizes name resolution. If communities can be composed arbitrarily, that means that there are an arbitrary number of paths via which an entity can be resolved. This raises the complexity level by requiring the algorithm be either recursive or iterative, rather than strictly bounded in lookup time. Also, note how browsers color links that have already been visited differently from unvisited ones - if an identical entity can be referenced in arbitrary ways, it means that browsers must either perform a name->identity lookup for *every* link in a page to disambiguate, or suffer a feature regression (admittedly small as it may be). I suspect there are other such issues. I personally would prefer a single-level resolution system with something closer to 'multimethod dispatch' (I am a CS student), where each name could have arbitrary traits and selection between identical names could be made based on traits. There would need to be an invariant requiring each have at least one unique trait, but that can be trivially implemented with a single mandatory 'pubkey fingerprint' trait.

The example of (Jim-PC) resolving differently on the LAN could be handled by allowing 'delegation' of IDONS resolutions, similar to how modern broadband routers implement a caching DNS with additional entries representing the router itself and entities on the LAN.

I do, however, like the parentheses notation for IDONS addresses, since the parentheses is banned in DNS _and_ does not imply hierarchy. Perhaps it could be of the form (name)(trait1=foo)(trait2=bar) in the scheme I describe above.

[lauren]

This level of detail is significantly premature, but parentheses would need to be escaped in standard shells. I really want to avoid special characters in paths that would need escaping in the most common environments (even if escaping were only required at the shell level).

--Lauren--