Re: A Survey of ILP Account Identifiers?

On 7 December 2016 at 22:08, Adrian Hope-Bailie <adrian@hopebailie.com>
wrote:

> > it does a reverse lookup on my http url and finds my crypto addresses.
>
> Can you expand on this?
>
> Reverse lookups imply you need to crawl all known URLs and index the
> identifiers that are linked to them and then also have a strategy for
> resolving duplicates (i.e. What if two different Web IDs claimed your email
> address as their own?)
>

Great question!  For a background see the imfamous Zooko's triangle:

https://en.wikipedia.org/wiki/Zooko's_triangle

Let me break down into two questions.  First, comparison of forward and
reverse lookup, strengths and weaknesses, and strategies.

Secondly, the provenance question of how you trust that information.

In the interests of brevity, I'll give a high level explanation, but feel
free to drill down, on details.

*Forward vs Reverse Lookup*.  Both strategies come with cost/benefits.  A
forward lookup is when you take a URI and get back documents and strings.
A reverse lookup is when you take a string and get back a URI.The advantage
of forward lookup (aka follow your nose) say by dereferencing an HTTP URI
is that you will get a definitive result, often secured via TLS.  The
disadvantage is that it requires memorizing an identifier, cut and paste,
of that identifier persisted for you (which luckily most browsers do these
days).  The other disadvantage is the one time setup at registration.  The
disadvantage of reverse lookup is that you need a lookup table aka an
index.  So typically this is done in a silo at sign up time when you
confirm your email it gets stored in a DB.  Facebook is an example of silo
based reverse lookup.  Another method is a distributed version of this
relying on shared infrastructure like GPG, which uses keyservers.  X.509
has a similar shared lookup infrastructure.  There are other systems trying
to solve this problem in a webby way, such as keybase and webizen.  Another
way is using a "well known" location decided out of band as with the RFC
7033 (aka webfinger).  Different people are going to use different
strategies based on the pros and cons.  If ILP is usable by all these, and
can prove interop, it's going to be a great system.  Typically systems fail
this test, so it's a hard problem.

*How can I trust the index?*  This is another hard problem in the
distributed world.  In a single silo it's possible to verify an email by
having a user click on a link.  It gets tricker when you have multiple
sites.  This is where the work on verifyable claims at the W3C is going to
come in really useful.  You can verify the authenticity of a claim either
by inference (e.g. the domain that controls one identifier also controls
another) or you can use digital signature to verify claims.  Given that ILP
seems to be developing a trust infrastructure through the connectors, it
might be a good advantage to reuse that technology.

I realize answers are quite abstract, as it's been 10+ years to work all
the details out, mainly through trial and error, and I didnt want to type
to much.  I hope I've at least partially answered some of your questions,
I'd be happy to expand on individual details.



>
> On 4 December 2016 at 22:36, Melvin Carvalho <melvincarvalho@gmail.com>
> wrote:
>
>>
>>
>> On 4 December 2016 at 19:55, David Fuelling <dfuelling@sappenin.com>
>> wrote:
>>
>>> Hey All,
>>>
>>> There seems to be several different ways to define the format and
>>> characteristics of an ILP Ledger Account identifier (e.g., ILP Address,
>>> email address, URL, etc).
>>>
>>> For me, this has led to some confusion as I've tried to reason about
>>> when and where to use which style of identifier.  So, I created the
>>> following wiki page to try to and collect my thoughts and formalize my
>>> understanding of these different proposed identifiers, when to use them,
>>> and why:
>>>
>>> https://github.com/fluid-money/ilp-connector-java/wiki/A-Sur
>>> vey-of-Interledger-Account-Identifiers
>>>
>>> While I feel like this has clarified some thing for me, it has prompted
>>> a few more questions, which I tried to outline in the last section called
>>> "FAQ" -- I provided some strawman answers and counter-answers in there, but
>>> I'm curious if anyone has input/opinions/clarifications/corrections
>>> about what I've put together overall.  Feel free to share your thoughts,
>>> and if there's any interest I'd be happy to move this page over to the
>>> Interledger project on Github if people find it useful.
>>>
>>
>> It might be easier to explain how I do this.
>>
>> My identifer is a primary key which is an HTTP URI.  In general it is
>> hidden from the user, but it may show up in places, much like how URLs
>> appear in the address bar of a browser.  The user doesnt really need to
>> know what it is.  Just that it works.
>>
>> Tied to may URL is my name (used for personalizing apps), my email
>> address (which could be used as a short hand to log in), my crypto
>> addresses (used to send crypto coins), my wallets (which are like ledgers
>> and give you instructions on how to send credits), my keys (used for PKI
>> and login) and pretty much any other info I want.
>>
>> Lets say you want to send me some crypto coins, you send to my email
>> address, it does a reverse lookup on my http url and finds my crypto
>> addresses.
>>
>> Lets say you want to send me some webcredits, you similarly get my
>> wallets, then if you have a positive balance, it will give you an API
>> endpoint or inboxl that you can send credits to.  My agent will pick up the
>> payment and make the transfer.
>>
>> Same could apply sending money from phone to phone, via irc or internet
>> chat etc. lots of other use cases present themselves.
>>
>> This is how the web / linked data was designed to work, it gives you not
>> just human readable flows, but machine readable flows so that simple steps
>> such as payments can be performed by machines / agents.  Leading to complex
>> and innovative use cases.
>>
>>
>>>
>>> Thanks,
>>> david
>>>
>>
>>
>