Re: Thoughts on Discovery

I thought I'd forward comments from some a couple of off-list colleagues
about how another DNS-based Discovery-related protocol might fit here (also
based on the IETF RFCs for DDDS). In particular, this relates to avoiding
the need to query multiple ledgers - but also in bootstrapping a valid ILP
address from other known Payee identity information.

I know there's a concern here with DNS, vs the fully distributed
blockchain. But despite the existence of its (non-distributed) Root, DNS
has the interesting and special characteristic of being a global *Identity*
system, not least for businesses. Internet identity alone would be
insufficient in the payments legal and security context. But it might still
be one useful input.

Per Dale's email below, there is some code implementing this, which I could
ask him for, and post to Github if there's any interest.

Roger

_________________________

>From Pim:

The URI that WebFinger needs could be obtained indirectly using something
like BDXL location.  For example,    123456789.bankaccounts.org could have
a NAPTR-U DNS record pointing to WebFinger URI,  that would then return the
information needed to make a payment to account 123456789.   Just showing a
sample use of these technologies,  not sure if they are the ones that make
most sense in this context though.

___________________________

>From Dale:

There seem to me to be two kinds of discovery protocols: broadcast and
unicast query...

Broadcast are used over local networks (which in ipv6 can be quite large)
-- used to discover printers, routers, etc in a "broadcast domain"  This is
also used for bootstrap protocols like dhcp, arp, mdns, etc etc. Multicast
discovery is basically a variant of this.

Now unicast query is one that supposes you have configured something to at
least initally serve as a target for your query. If it is browser-based
search,google.com would be such a target. For DNS, a computer has something
like a resolv.conf file that is where it directs the initial DNS query.
DNS  then remarkably will requery for a resolution to your query through a
vast tree of resolvers. (If people don't think DNS is a distributed
protocol. I don't know what they mean by "distributed") So I agree that it
would help to define the discovery requirements, the degree of "zero
configuration" needed, query language expressive power, etc. Webfinger I
think assumes you have a URL, DNS an entry to DNS resolver network plus a
DNS name (which serves as the query). If you hear more specific
requirements, I could suggest options. I think the discussion is at an
early stage. I am guessing that there are no "security entry requirements"
for seeking to discover an endpoint or address. That would complicate
things a bit.)

Yes I did do some code for BDXR on DNS query using python and javascript
bindings. I am sure they are around on a harddrive somewhere.
On Mar 30, 2016 8:17 AM, "Melvin Carvalho" <melvincarvalho@gmail.com> wrote:

>
>
> On 30 March 2016 at 17:02, Melvin Carvalho <melvincarvalho@gmail.com>
> wrote:
>
>>
>>
>> On 30 March 2016 at 14:51, Adrian Hope-Bailie <adrian@hopebailie.com>
>> wrote:
>>
>>> So you're suggesting that the answer to resolving an account identifier
>>> (URI) to a ledger URL is to query every known ledger and find out if the
>>> account exists in that ledger?
>>>
>>
>> No, I didnt say that
>>
>> I think you misunderstand what linked data is, how it works or even that
>> it is a discovery protocol.  Or even that the web itself is a tool for
>> discovery.  I suggest it is beyond the scope of this discussion, and my
>> ability to explain any more than I have, I'd simply invite you to do a web
>> search and review documentation on linked data, of which there is quite a
>> bit.
>>
>> Let me clarify that I think using webfinger for the use case you lay out
>> would be disadvantageous.  Mainly because of JRD and acct: URIs schemes
>> have disadvantages.  I suspect ILP will find this out soon after it tries
>> to gain adoption.
>>
>> The concept of a super ledger is slightly orthogonal.  It's a
>> fundamentally more webby way of creating a ledger.  When you use URIs in
>> your ledger, in many cases there is no need for any additional protocols.
>>
>
> I dont know but maybe this article is a good starting point:
>
> http://dig.csail.mit.edu/breadcrumbs/node/215
>
> It predates linked data I think, and hopefully explains the motivations of
> graph vs web, and how the graph is linked and used to discover new
> information.
>
>
>>
>>
>>>
>>> I'm not sure that's scales very well.
>>>
>>> On 30 March 2016 at 12:55, Melvin Carvalho <melvincarvalho@gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On 30 March 2016 at 10:02, Adrian Hope-Bailie <adrian@hopebailie.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Tuesday, March 29, 2016, Melvin Carvalho <melvincarvalho@gmail.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On 29 March 2016 at 21:47, Adrian Hope-Bailie <adrian@hopebailie.com>
>>>>>> wrote:
>>>>>>
>>>>>>> What is a super-ledger? It sounds like you're suggesting that the
>>>>>>> whole world should all just use a single ledger which seems pretty hard to
>>>>>>> scale
>>>>>>
>>>>>>
>>>>>> I mentioned it in another thread.  A super ledger is a ledger where
>>>>>> every entry is a URI.  Just as URIs are sometimes called "super keys".  All
>>>>>> of the ledgers Im working with are are super ledgers.
>>>>>>
>>>>>
>>>>> How does the URI resolve to the address of the super-ledger?
>>>>>
>>>>> Do I need to query every super ledger to find the account I'm looking
>>>>> for?
>>>>>
>>>>
>>>> Yes exactly.  There can be many super ledgers.  Hence the need for
>>>> inter ledger transactions.  If a URI is in two different super ledgers it
>>>> can then act as a connector.
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tuesday, March 29, 2016, Melvin Carvalho <
>>>>>>> melvincarvalho@gmail.com> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 29 March 2016 at 16:47, Adrian Hope-Bailie <
>>>>>>>> adrian@hopebailie.com> wrote:
>>>>>>>>
>>>>>>>>> On 29 March 2016 at 16:32, Melvin Carvalho <
>>>>>>>>> melvincarvalho@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 29 March 2016 at 15:48, Adrian Hope-Bailie <
>>>>>>>>>> adrian@hopebailie.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> This is a higher level function.
>>>>>>>>>>> I.e. I give you some identifier for my account like
>>>>>>>>>>> adrian@mywalletprovider.com and you have a well-defined
>>>>>>>>>>> protocol to resolve the address of my ledger from that.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Have a look what happens when I hover over the link you pasted
>>>>>>>>>> (image attached)
>>>>>>>>>>
>>>>>>>>>> firefox automatically translates it into mailto:
>>>>>>>>>>
>>>>>>>>>> this denotes an email address using a URI
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> Right, because in the context of an email program it makes sense
>>>>>>>>> to normalize that to a mailto: URI.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> so how do you send money to an email address, this becomes a
>>>>>>>>>> trivial problem with a super ledger, you just send it to the URI
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> How? I'm not following how I would send money to a mailto: URI?
>>>>>>>>>
>>>>>>>>
>>>>>>>> In a super ledger every entry is a URI, so you just have the mailto:
>>>>>>>> address as the recipient.  Problem solved.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Following which you will do path finding to my ledger.
>>>>>>>>>>>
>>>>>>>>>>> If ILP is TCP/IP then we're trying to figure out a good way to
>>>>>>>>>>> do DNS :)
>>>>>>>>>>>
>>>>>>>>>>> On 29 March 2016 at 15:26, Xavier Vas <xavier@tr80.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Adrian,
>>>>>>>>>>>>
>>>>>>>>>>>> Sorry, I'm confused, how's this discussion separate from our
>>>>>>>>>>>> discussions
>>>>>>>>>>>> on path finding and routing? How exactly do you define
>>>>>>>>>>>> "discovery" vs.
>>>>>>>>>>>> "path finding"?
>>>>>>>>>>>>
>>>>>>>>>>>> Xav
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Sent from a mobile device, please excuse any typos
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Sent from a mobile device, please excuse any typos
>>>>>
>>>>
>>>>
>>>
>>
>

Received on Saturday, 2 April 2016 17:17:15 UTC