Re: Thoughts on Discovery

On 29 March 2016 at 14:42, Melvin Carvalho <melvincarvalho@gmail.com> wrote:

>
>
> On 29 March 2016 at 13:01, Adrian Hope-Bailie <adrian@hopebailie.com>
> wrote:
>
>> Is acct: lookup really a problem?
>>
>
> I would say so.  But well, why even use acct: in the first place?
>
>
>>
>> It depends on the context in which you encounter the identifier. If the
>> context suggests that this is an Interledger account identifier then the
>> next step would be to normalize it into an acct: URI and then resolve the
>> ledger URL from that using WebFinger (or WebFinger 2.0 with JSON-LD)
>>
>
> Yes, that would be out of band information contained in the inter ledger
> protocol spec.  It requires organic growth, rather than, bootstrapping what
> we have already.
>

True but I'm unclear on how you would use linked data to get around this.
There is nothing built into HTTP that would enable this resolution is there?


>
>
>>
>> I hear you say that an xxx@yyyy identifier could be misinterpreted as a
>> mailto: or xmpp: or sip: URI but why would a piece of software that is
>> specifically trying to take an identifier and find meta-data about ledgers
>> and accounts for the purposes of sending an ILP payment normalize that
>> identifier to anything but an acct: URI?
>>
>
> So what if I want to send money to an email address, or xmpp account.  I
> can do this already, ILP cant.  So I would say there's some major
> scalability issues introduced.
>

I'm intrigued :) How can you send money to an xmpp or mailto address?


>
>
>>
>> On 29 March 2016 at 12:53, Melvin Carvalho <melvincarvalho@gmail.com>
>> wrote:
>>
>>>
>>>
>>> On 29 March 2016 at 12:40, Adrian Hope-Bailie <adrian@hopebailie.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On 29 March 2016 at 08:50, Melvin Carvalho <melvincarvalho@gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On 28 March 2016 at 12:58, Adrian Hope-Bailie <adrian@hopebailie.com>
>>>>> wrote:
>>>>>
>>>>>> There have been some good discussions around the correct technology
>>>>>> for the discovery of a receiving account (ledger).
>>>>>>
>>>>>> The current proposal is to to use WebFinger (
>>>>>> https://tools.ietf.org/html/rfc7033) which is the basis for
>>>>>> discovery in a variety of web based protocols such as OpenID Connect.
>>>>>>
>>>>>> There has been a proposal to use JSON-LD however it is unclear at
>>>>>> this stage how this would be done as JSON-LD is not a protocol, it is a
>>>>>> data format for linked data.
>>>>>>
>>>>>> There have also been suggestions to explore other existing lower
>>>>>> level discovery protocols such as DDDS based on DNS.
>>>>>>
>>>>>> I've been having this debate for about 10 years in various groups
>>>>>> related to payments, identity and other more obscure use cases. The reality
>>>>>> is that there is no one discovery protocol appropriate for all use cases.
>>>>>>
>>>>>> In an ideal world there would be an entirely decentralised registry
>>>>>> (noting that DNS is not) that could be used as the primary source of truth
>>>>>> for resolving a human readable identifier into something that can be used
>>>>>> by a machine to accomplish some specific goal.
>>>>>>
>>>>>> I don't believe it's the goal of this group to solve this problem but
>>>>>> if we feel the current proposal of Webfinger is inappropriate for resolving
>>>>>> an account@ledger identifer into a ledger address then let's find a
>>>>>> a better alternative.
>>>>>>
>>>>>> But, before we get into a religious debate about the choice of
>>>>>> technology I'd suggest we agree on what the requirements and design goals
>>>>>> are for this discovery protocol.
>>>>>>
>>>>>
>>>>> By the way I dont think we really have religious debates.  I think
>>>>> what happens is that we have varying degrees of having read, understood and
>>>>> implemented technologies, and processes of education during the drafting of
>>>>> specifications.
>>>>>
>>>>
>>>> It sounds like you are saying "some of us know what we're talking about
>>>> and others don't so it's not a debate it's just us waiting for the rest to
>>>> catch up". I disagree. Simply having the best understanding of a technology
>>>> doesn't mean your opinions on that technology are always right.
>>>>
>>>> The purpose of a group like this is to get wide and varied input and
>>>> not to be dismissive of other peoples ideas or opinions.
>>>>
>>>> I think the best way to get a point across in this context is to write
>>>> some code and submit it as a patch against the existing reference
>>>> implementations OR point the group to it for review.
>>>>
>>>
>>> Totally agree, I spend most of my time writing code.  But I will
>>> participate in mailing lists too if I think I can explain stuff.
>>>
>>>
>>>>
>>>> I don't think anyone is afraid of taking a non-standard approach and
>>>> using it if it's the best technical solution but when it comes to solving
>>>> non-core problems I'd favor existing standards with existing
>>>> implementations.
>>>>
>>>>
>>>>>
>>>>> I think I understand webfinger pretty well (my name is on the spec)
>>>>> and well we made it as good as it could be, but it still has limitations.
>>>>> It's not a discovery protocol for user@host, thought that is what the
>>>>> original motivation was.  It's a discovery protocol for URIs.  In
>>>>> particular, it evangelizes the organic growth of the new URI scheme
>>>>> acct:user@host.  This was always going to be a big ask, because as we
>>>>> tend to find out in the proceeding years, organic growth is hard.  The
>>>>> other limitation is that the serialization, JRD, is quite restrictive, and
>>>>> doesnt play well with anything other than itself.
>>>>>
>>>>
>>>> The only problem I have with WebFinger is JRD. It's a weird
>>>> serialization format that doesn't appear to be used anywhere else.
>>>>
>>>
>>> JRD is not only weird it has several limitations.  You can only have one
>>> literal as an object.  When URIs are objects they must be ordered by
>>> preference, without any clear guide as to what preference means, which is
>>> an interop nightmare, and implementation burden.  It treats numbers as
>>> strings.  I think there's a few other things that I've forgotten.  Net
>>> result is that it ends up too complex for people to implement correctly.
>>> At least every single time I looked at an implementation there was one
>>> point or other that didnt align with the spec.
>>>
>>>
>>>>
>>>> That said, WebFinger gives us exactly what we need for the Open Web
>>>> Payments Scheme discovery. I have an account identifer in the form xxx@yyyy
>>>> and I am able to resolve at least two URL's from that, one pointing to a
>>>> ledger and one pointing to an actual account.
>>>>
>>>> That's the requirement and WebFinger addresses the requirement.
>>>>
>>>>
>>>>>
>>>>> The important word in JSON LD, is not JSON, but rather, LD.  Linked
>>>>> Data is simply a tweak of HTTP to allow discovery.  This is the so-called
>>>>> "follow your nose" pattern that people experience every day.  You go to a
>>>>> URL, you find links and you click on them to 'discover' more information.
>>>>> Linked data simply lets machines do this the same way humans do.  There is
>>>>> no new protocol, only HTTP.  The JSON part shows you how to parse the
>>>>> links.  But the same applies in other serializations including HTML.  When
>>>>> you paste a link into facebook it will show you the image, caption and
>>>>> headline.  That uses Linked Data discovery to fetch those items.  It isnt
>>>>> something new, it's something that is very widely deployed on the web
>>>>> already.
>>>>>
>>>>> So, I dont think there's a debate going on, just explaining stuff.  It
>>>>> only becomes a debate when the education process goes wrong, often for
>>>>> human reasons.
>>>>>
>>>>
>>>> I don't think we agree on whether or not WebFinger solves the problem
>>>> we are trying to solve or if there is a standardized protocol for doing
>>>> this that is a good alternative. So I'd still call this a debate. I am
>>>> waiting to be shown a better alternative, at which point I'd happily
>>>> concede the debate :)
>>>>
>>>
>>> I think we have lots of people on various stages on a journey, and we're
>>> all learning from each other.
>>>
>>>
>>>>
>>>> If you said to me, the basics of WebFinger are okay but let's use
>>>> JSON-LD instead of JRD I'd agree that's a good approach but would want to
>>>> spec it out so that we have some level of confidence that we're creating a
>>>> dependency on something that will be standardized in and of itself (maybe
>>>> as WebFinger 2.0) soon.
>>>>
>>>
>>> That would work.  But you still have the acct: lookup problem.
>>>
>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> This discovery protocol is intended to be simple and form part of a
>>>>>> basic application layer payments protocol we're developing called OWPS
>>>>>> which also has a stated design goal of being simple and addressing only a
>>>>>> select set of use cases.
>>>>>>
>>>>>> As I have stated in a separate thread, nothing prevents us from
>>>>>> taking the plunge and trying to develop a far richer application layer
>>>>>> protocol that incorporates more complex systems of discovery.
>>>>>>
>>>>>> Finally, if there are alternative proposals to WebFinger please let's
>>>>>> see them in action. All of the Interledger code is being developed in the
>>>>>> open so it should be possible to fork the project you're interested in and
>>>>>> implementing an alternative proposal for everyone to review.
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>