Re: Thoughts on Discovery

On 28 March 2016 at 20:26, Stefan Thomas <stefan@ripple.com> wrote:

> I think as a prototype of an alternative Discovery flow it would even be
> ok to just show the resolution flow.
>
> What are the steps leading up to returning the URI? That's what you'd want
> to demonstrate.
>
> If you do want to fork our code, the relevant section would be here:
>
>
> https://github.com/interledger/five-bells-wallet/blob/master/api/src/controllers/webfinger.js
>
> Note that running a wallet service requires a few steps at the moment: You
> need to have a ledger where you're the admin, so generally that means
> setting up a ledger first, then setting up a wallet. If you wanted to show
> interledger payments, you'd also need to set up a connector to some other
> ledger. In the future, we'll hopefully streamline a lot of this, but that's
> beyond the scope of this email.
>

Love this flow, and my intention is to create it from first principles.
Initially I'll be running a super ledger, in fact a number of super ledgers
using nodejs and express so that you can call them either as a JS function,
on the command line, or via a web call.

The idea of connectors is brilliant, and thats the next frontier for me.
To begin with I'll operate in a high trust scenario where escrow is not
needed, simply because that will enable me to prototype faster.  But I'd
like to add things like escrow as a next phase.

What I'm working towards is how the connectors trust each other between
ledgers, either by setting up trust lines (maybe something like
ripple/trustdavis?) or by taking the natural limit of allowing no account
to fall below zero.  I think I'll be able to flesh this out more as the
implementation progresses.  So Im interested to compare notes, and to see
what extent hetrogeneous ledgers can work together.

Im unsure I can personally visualize a system where webfinger and linked
data (eg json LD) interop, mainly due to webfinger limitations, but I
suppose I can add support for it, in the event that organic growth reaches
some kind of critical mass, and the benefits outweigh the cost of coding.
Looking forward to testing this stuff out.  Optimistically im aiming for Q2
of 2016.


>
>
> On Mon, Mar 28, 2016 at 3:58 AM, 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.
>>
>> 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.
>>
>>
>