-
Notifications
You must be signed in to change notification settings - Fork 71
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(daemon): locate based lookup with three party handoff #2119
base: master
Are you sure you want to change the base?
Conversation
6ddff82
to
fcafcdc
Compare
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 This might be a case where having some interface hints on the location would help us decide whether to dispatch |
hm. um... I don't see a way out. I would like to phone a friend. @michaelfig ? |
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. |
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 Making the name lookup lazy until await self.foo.bar
await provide(self.foo.bar) |
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 notlocate
?