Re: Thoughts on Discovery

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