Re: Thoughts on Discovery

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.

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


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

Received on Tuesday, 29 March 2016 07:51:03 UTC