- From: Adrian Hope-Bailie <adrian@hopebailie.com>
- Date: Tue, 29 Mar 2016 11:40:07 +0100
- To: Melvin Carvalho <melvincarvalho@gmail.com>
- Cc: Interledger Community Group <public-interledger@w3.org>
- Message-ID: <CA+eFz_KNbNhKz3o9ZUD-Rgzwn2jdSBd6oE62Pg_c4Fch0b8x5g@mail.gmail.com>
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. >> >> >
Received on Tuesday, 29 March 2016 10:40:38 UTC