Re: Thoughts on Discovery

On 29 March 2016 at 12:13, Adrian Hope-Bailie <adrian@hopebailie.com> wrote:

>
>
> On 28 March 2016 at 22:25, 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.
>>>
>>
>> Which are the variety of web protocols webfinger is the basis for?
>>
>> Every system ive seen use this is what I would call "dead on arrival", I
>> dont expect interledger to fair much better.  I've also never seen
>> webfinger implemented correctly or work with other webfinger
>> implementations.
>>
>> More data points would be interesting.
>>
>
> As a start Open ID Connect Discovery which I know many don't like but I
> certainly wouldn't call it dead on arrival.
>

I hear people are dropping support for web finger.  You mentioned various
other protocols, could you elaborate on which?


>
>
>>
>>
>>>
>>> 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.
>>>
>>
>> Im not sure what's unclear here.  It doesnt have to be json based, it
>> could be any type of linked data.  In fact, Im moving more to turtle
>> personally, at this point.
>>
>
> JSON-LD is a data format. I think to propose JSON-LD as the mechanism for
> doing discovery you'd need to explain a little better how this would work
> or put an implementation online for the group to see.
>

I think you've misunderstood the motivation for Linked Data.  I've
hopefully explained it in a subsequent post.


>
> i.e. I have identifier me@myledger, what is the process to resolve a
> ledger URL from that?
>

The only way is to guess, or use out of band knowledge.  The webfinger way
is to use out of band knowledge (ie the spec) to translate me@myledger to
acct:me@myledger.  Then you need to find a way to resolve that URI since it
doesnt resolve itself.  So you again look in the spec.  The spec tells you
to go to myledger/.well-known/webfinger and then add a subject parameter.
Then you parse the bespoke return, and you'll get some new information.
The main issue that I see is evangelization and organic growth of the new
URI scheme.  It hasnt yet caught on and we need many more years to see if
it does.  That's not time im prepared to invest, because I want to use this
technology now.


>
> I appreciate that the serialization format used in WebFinger has been
> "dead on arrival" but that's the format used in the spec. Perhaps a
> WebFinger 2.0 spec is the right way to go that uses JSON-LD instead?
>

The serialization is just one issue.  Specs that adopt webfinger dont tend
to do well or interoperate.  ILP may be different, but Im not holding my
breath.

Yep, I'd like to see a webfinger 2.0 on those lines.  I suggested this
already, in fact I would have liked to see it as part of webfinger 1.0, but
json ld just didnt have enough traction to get there back then.  It does
now.  But that would take some time to standardize, unless you take the
"Just do it" attitude, which I think works.


>
>
>>
>>
>>>
>>> There have also been suggestions to explore other existing lower level
>>> discovery protocols such as DDDS based on DNS.
>>>
>>
>> I think reinventing DNS should be out of scope.
>>
>
> Yes, at the application layer. For the lower layer protocols of ILP it
> would be great to have no dependency on DNS at all (or at least no strong
> binding to individual hosts/domains) and since we are developing this from
> the ground up this may be possible.
>

Sounds good.


>
>
>>
>>
>>>
>>> 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.
>>>
>>
>> Why not?  Id strongly disagree here, linked data is the discovery
>> mechanism of the web.  Not seeing the issue, I suppose, other than NIH.
>>
>
> Again, this is a mechanism not a well documented protocol for this use
> case. Is there well documented protocol using linked data that explains how
> to resolve a URL for a specific type of resource from an identifier?
>

It's extremely well documented.  The last 15 years of standardization at
the w3c has had linked data as a core focus.


>
> You may be able to make the case that linked-data can be used for all use
> cases but what's missing is the use cases specific protocol that an
> implementer can write code against.
>
>
>>
>>
>>>
>>> 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.
>>>
>>
>> Webfinger doesnt resolve the account@ledger identifer.  So, now Im
>> wondering what problem you are trying to solve.
>>
>
> Yes it does. It uses acct: URIs but it's pretty trivial to say "if the
> identifier is in the form account@ledger then assume it's an acct: URI"
> then follow the rest of the spec to the letter.
>

This is not trivial at all.  Absolutely no software would assume this.
Every major piece of software including gmail, skype and numerous other
will assume it's mailto:account@ledger.

Other software might think it's xmpp: or sip:


>
>
>>
>>
>>>
>>> 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.
>>>
>>> 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.
>>>
>>>
>> I have already created an implementation and demoed it in another working
>> group.  My aim is to do the same with payments / inter ledger, as I
>> integrate it with Solid.  I'll post a demo when it's ready.
>>
>
> Great!
>
>