Re: Thoughts on Discovery

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.


>
> 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.


>
> 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.
>>>>>
>>>>>
>>>>
>>>
>>
>