feat(daemon): locate based lookup with three party handoff

[kumavis]

rework recursive lookup to use identify/locate. this achieves third party handoff with automatic introductions to new peers.

what do we do when things support lookup but not locate?

[kriskowal]

attn @dckc We have a dilemma with the pet daemon’s implementation of pet name path lookup. Changing the protocol for following pet-name paths to internally call locate instead of lookup (producing location of the value instead of the value) and a final call to provide(location) to obtain the value trivially solves three-party hand-off and introduction to remote peers, but loses us the ability to follow chains of name hubs that do not implement locate.

This might be a case where having some interface hints on the location would help us decide whether to dispatch locate or lookup, leaning on lookup by default. Consider a location like endo://node-id/id?has=locate&address=...&address=....

[dckc]

attn @dckc We have a dilemma with the pet daemon’s implementation of pet name path lookup...

hm. um... I don't see a way out. I would like to phone a friend. @michaelfig ?

cc @gibson042 @erights

[kriskowal]

The answer is probably that we should have one method that supports hand-off and another that explicitly does not, such that you can choose whether your node masks the route to the target or hands the target node off to the source. Maybe that should even be expressible with a different kind of dot in dotted paths.

[kriskowal]

Perhaps the pet name path

• foo.bar corresponds to self~.lookup('foo')~.lookup('bar') whereas,
• foo:bar corresponds to self~.provide(self~.lookup('foo')~.locate('bar')).

Noting that the first term of both is self~.lookup('foo'), that suggests there’s a distinction that might be expressed with a prefix of either . for lookup or the combination of locate and provide for :, for a more concise basis:

• .foo is self~.lookup('foo')
• .bar is self~.provide(self~.locate('foo'))

However, that distinction is not interesting local to self.

[michaelfig]

Maybe that should even be expressible with a different kind of dot in dotted paths.

A different kind of dot means that petnames can't be a subset of JavaScript. I encourage you to consider a petname syntax where a property key is used to traverse one edge in the name graph in the most conventional, low-powered way, and function/method calls are used to access orthogonal spaces.

In the following, I am treating self as a name hub in its own right. If it is not, please substitute a different identifier for the current active petname system.

Making the name lookup lazy until path.then(...) is called or the path is an argument to an operator like provide(path) allows different ways of interpreting a path while remaining concise.

await self.foo.bar 
await provide(self.foo.bar)