Re: Thoughts on Discovery

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.

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.

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 :)

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.

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