Re: Registry Services [via Interledger Payments Community Group]

On 11 February 2016 at 05:53, Stefan Thomas <stefan@ripple.com> wrote:

> > What you are referring to (I think) is a user experience, that of
> typing a url into an input box, rather than, clicking one.  It's clear that
> users are not trained to do this, in the same way they have been trained to
> type in email addresses at this point in time.
>
> Agreed.
>
>
> > Facebook use firstname lastname, which is what I think most people are
> used to.
>
> There is actually a Facebook group for people with my exact first and last
> name with over a hundred members. (Me not being one of them.)
>
> When talking about identity we need to distinguish between unique
> identifiers and identifiers that are not unique. You often need both.
> Facebook for example also has unique usernames in addition to the firstname
> lastname thing, because there are cases where you need to refer to a
> specific user, e.g. in Facebook URLs, Facebook emails (
> yourname@facebook.com, might be discontinued, don't remember) and
> Facebook's payments efforts. Twitter similarly collects both unique
> (Twitter name) and non-unique (firstname lastname) usernames. The former
> are used for mentions and URLs, the latter are used for search, etc.
>

Yes facbeook use the graph protocol for this.  The URL is the unique part
and the <firstname> <lastname> is the display part.  Both are packaged
together on the screen in a hyperlink.  So the user gets to see something
they are familiar with and the system sees something unique.  Best of both
worlds.


>
> My email was solely concerned with unique identifiers. That's just cause I
> don't have any strong feelings on different ways to build non-unique
> identifiers right now. It also goes into Solid (which I think you're
> involved in?) and other decentralized social graph efforts that I don't
> know much about.
>

Yes, but your email also implied an on screen user experience, or human
computer interface.  Im happy to talk about unique identifiers in isolation.


>
>
> > To scale payments you need a first class identity system.  Or you'll
> hit a wall scaling -- ripple and bitcoin are good examples.  Meaning no
> disrespect to either system, both have very cool features, just scalability
> is not one of them, when compared with the web.
>
> First off - what do you mean by "scale"? Bitcoin and Ripple don't "scale"
> because they can process a limited number of transactions. Adding more
> network participants does not add more transaction processing capacity. The
> Web and Interledger fall on the other side of the scalability divide.
> Adding more ledgers and connectors in Interledger does increase the overall
> processing capacity.
>

It's an intentionally woolly term.  The web gets stronger gracefully as it
has more or any key metric e.g. users, data, capacity.   Most other systems
hit walls.  The web hasnt and doesnt seem to be doing so.  There's reasons
for this.


>
> Regarding Ripple's and Bitcoin's identity systems I can't see any evidence
> that those ran into scalability limits. But even if they did, you'd be supporting
> my argument. Federated names are proven to scale, email and the Web both
> use federated names on top of DNS and they are used every day by billions
> of users. The burden of proof when it comes to scalability is on any
> schemes that propose to do better than DNS.
>

DNS is a lookup technology.  As a subset of DNS http is also a lookup
technology, this enables you to look up for example a name and tie it to a
URL in a way that does not require organic growth (everything talks HTTP).
Email relies on DNS but is not a lookup system, it's a message delivery
system.  So you have to create a hack to make the user experience as good
as facebook (namecoin, webfinger etc.) and then you have to roll it out to
the whole world.  Quite a challenge.


>
>
> > I dont know what this is?  Is it an email address?  An acct: URI?  A
> sip address?  An xmpp address?  Any number of other addresses.
>
> Does it matter? The identifier X@Y.COM means what it says. "The account X
> as managed by Y.COM." If users care about decentralization they can use a
> domain they control. And some do. My email address is on a domain I own and
> I run my own email server. Most companies use their own domains for email,
> not gmail.com and Google offers a version of Gmail (Google Apps) for
> exactly that use case.
>

It matters because you've lose the uniqueness.  What's the problem with
calling it mailto:user@host?  These identifier are just very hard to
lookup.  They do have the advantage that users are now trained to remember
them.  That overloading comes at a cost.


>
> Is this perfect? No. I'd love a TLD that browsers can look up without even
> consulting VeriSign's root zone or any central authority. (Perhaps even
> with an officially registered GTLD for DNS backwards compatibility.) I'd
> love it if domains and SSL certificates were always free. I'd love for
> there to be a decentralized chain of trust all the way down to the SSL
> cert. Those are all awesome battles that we should fight.
>

Agree.  It's not perfect, but we're not competing with perfect.  Just
trying to make a system that works well enough.


>
>
> > Persona is being shut down, imho, due to this bad design decision.
>
> Opinion noted and very much respected.
>
> For reference, here's Mozilla's Persona After Action Report:
> https://wiki.mozilla.org/Identity/Persona_AAR
>
> I definitely agree with this: "We started building a whole identity stack
> but it's really hard to do things in a decentralized way."
>

Seems so.  Problems are more psychological than technical imho.


>
> My experience is that decentralization is 10x harder at least. That
> doesn't mean don't do it. But definitely build something simple first and
> make it incrementally more decentralized. More generally: Perfect is the
> enemy of the good. It doesn't matter what your goal is, whether it's
> decentralization or a pretty UI. Build something that at least works, then
> improve it.
>

That can work.  But the migration can be hard.  Sometimes you end up
throwing away a lot on each improvement.  A bit of design at the start can
save pain later.


>
> We can make payments as decentralized as the Web by building Interledger
> on the same technology stack. Let's call that option A. If we want to make
> Interledger (and the Web and email) more decentralized than that, then imho
> we should look at making a more decentralized stack to build on. That means
> more decentralized alternatives for DNS (a way to map unique human-readable
> identifiers to other values), TCP/IP/BGP/etc. (a way to communicate) and/or
> X.509 (the CAs we know and love), which is all very useful work, but I
> recommend building an implementation of Interledger on the web stack first.
> It's the quickest thing we can actually ship and still a huge improvement
> over payments today.
>

A good approach.  I think five bells is very promising here.


>
> As for improving DNS and TCP/IP - I think there are interesting mutual
> dependencies here. From talking to CJD (of cjdns fame) many years ago I
> learned that incentive issues are fundamental to many truly decentralized
> systems. That's why Bitcoin, Ripple and Ethereum have currencies built-in.
> It's one of the only ways to prevent DoS and manage resource
> allocation/prioritization in a fully decentralized way. Interledger in
> principle can be used as a truly decentralized payment method (if you make
> a super-pure version that rests on cryptographic keys only, no URIs and no
> human-readable anything.) On top of that you can build a decentralized
> blockchain, mesh network or other fully decentralized system. Let's call
> this option B. This is the only way I know of to solve incentive issues in
> a fully decentralized system without creating a currency. (And in case it's
> not obvious why that's attractive, after six years of trying to take two
> different currency-based systems mainstream, please believe me when I say
> it's a nightmare. People just end up being invested in one currency or
> another and rationality goes right out the window.)
>

Yep this comes after you've solved the web part.  The icing on the cake.


>
> I want to work on option A right now, because that's how I personally
> think I can impact the most people in the shortest amount of time. It
> doesn't mean that I wouldn't want to contribute to option B also or on the
> side. But I believe that B will take longer.
>

Agreed.


>
>
> > Webfinger isnt far behind it.
>
> Definitely not married to Webfinger. But X@Y.COM style identifiers are
> the only ones I can think of that 1) users are used to typing and that 2) a
> browser can easily map to a URI. And Webfinger is a perfectly
> straightforward way to do that mapping. If there is a better alternative to
> Webfinger I'm all ears.
>

Yes, so this is what's called Zooko's triangle.  Turns out that solving
zooko's triangle is a 100 billion dollar problem.  Fortunately facebook
have done it with their open graph protocol.  Webfinger failed by keying
off email style identifiers.  The burden is on the webfinger community to
evangalize their system and make it as widespread as http.  You have two
problems instead of one.


>
>
> > Why not just use WebID?
>
> Sure, I only didn't consider it because I don't know it very well. What
> does a WebID identifier look like when you type it and what is the process
> for mapping it to an Interledger account URI?
>

Normally you would just click a button.  Hyperlinks are used a lot on the
web, but when was the last time you typed one in to a form?


>
> On Wed, Feb 10, 2016 at 6:51 PM, Melvin Carvalho <melvincarvalho@gmail.com
> > wrote:
>
>>
>>
>> On 11 February 2016 at 03:21, Stefan Thomas <stefan@ripple.com> wrote:
>>
>>> Here are my two cents on the identifier issue:
>>>
>>> Right now in the ILP prototype, destinations are expressed as URIs. From
>>> OpenID we know that exposing the user to URIs as identifiers was a terrible
>>> user experience that users strongly reject.
>>>
>>
>> Using URIs is a great way to scale.
>>
>> Not sure this characterization is accurate.  Users see URIs all the time,
>> for example hyperlinks, and in the address bar.  What you are referring to
>> (I think) is a user experience, that of typing a url into an input box,
>> rather than, clicking one.  It's clear that users are not trained to do
>> this, in the same way they have been trained to type in email addresses at
>> this point in time.  Your language indicates you have strong view on this
>> topic, further discussion my not prove fruitful, let's see. :)
>>
>>
>>>
>>> At Ripple we used to have identifiers like
>>> this: rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh and we introduced Ripple names
>>> which look like this: ~bob (pronounced "ripple Bob")
>>>
>>> This might look reminiscent of Twitter usernames (@bob) or Square
>>> cashtags ($bob), which is no coincidence - the colleague
>>> <https://angel.co/gregkidd> who strongly advocated for these names at
>>> Ripple was also a first round investor in Twitter and an advisor at Square.
>>>
>>
>> Facebook use firstname lastname, which is what I think most people are
>> used to.
>>
>>
>>>
>>> The lesson I took away from that whole experience was that creating a
>>> namespace like that without a central operator is hard. Namecoin is trying
>>> to do it, we were trying to do it, I'm strongly against making either
>>> effort a dependency of Interledger.
>>>
>>
>> That's where the web can help, it is good at namespaces.
>>
>>
>>>
>>> That leaves the "next best thing" which is federated identifiers.
>>> [username]@[domain.com] Email uses them, OpenID Connect adopted them in
>>> their OpenID Connect Discovery spec
>>> <https://openid.net/specs/openid-connect-discovery-1_0.html>. Ripple used
>>> them as a hack <https://wiki.ripple.com/Federation_protocol> while we
>>> were working on Ripple names. They were extremely easy to build, developers
>>> had an easy enough time adopting them, they are the most decentralized
>>> thing that is actually production-ready and users have an ok time using
>>> them.
>>>
>>
>> I dont know what this is?  Is it an email address?  An acct: URI?  A sip
>> address?  An xmpp address?  Any number of other addresses.  There's a
>> scalability point of failure right there.  Let's say it's an email
>> address.  We're back to the centralized model where the big email providers
>> dominate.  Can we do better?
>>
>>
>>>
>>> Identity is very hard and I applaud anyone who is working to create
>>> better solutions. But I've learned not to make a new identity protocol a
>>> dependency of your new payments protocol.
>>>
>>
>> I feel the opposite.  To scale payments you need a first class identity
>> system.  Or you'll hit a wall scaling -- ripple and bitcoin are good
>> examples.  Meaning no disrespect to either system, both have very cool
>> features, just scalability is not one of them, when compared with the web.
>>
>>
>>>
>>> For any peer-to-peer payment solution on top of Interledger *today* that
>>> requires an identifier, I would recommend an [account]@[ledger domain]
>>> looking thing, e.g. bob@superpay.com which resolves to an ILP URI via
>>> webfinger. With any luck the scheme will get popular enough such that email
>>> providers let you set a wallet provider and your actual bob@gmail.com
>>> email address will redirect to your wallet. I'm fully aware of the awesome
>>> work that Manu Sporny, Mozilla (Persona) and many others have been doing on
>>> a scheme that doesn't require cooperation from the domain holder (Gmail in
>>> this case), but I don't think those efforts are production-ready today. The
>>> same goes for decentralized identity networks like Namecoin and
>>> identi.fi.
>>>
>>
>> Persona is being shut down, imho, due to this bad design decision.
>> Webfinger isnt far behind it.  Why not just use WebID?  It's best of breed
>> in this class.  I suspect the usual biases will kick in at this point.  But
>> I'm more than happy to let implementations do the talking on this one.
>>
>>
>>>
>>> If you disagree, you don't have to convince me or anyone else, you just
>>> have to build a prototype of a protocol on top of ILP using whatever
>>> identifier you think is better. Once we have both options implemented,
>>> it'll be easier to decide which one we like.
>>>
>>
>> Working on it! :)
>>
>>
>>>
>>> On Wed, Feb 10, 2016 at 3:48 AM, W3C Community Development Team <
>>> team-community-process@w3.org> wrote:
>>>
>>>> Hello,
>>>>
>>>> Are there discussions around registry services ? I assume to handle
>>>> transactions
>>>> across ledger, one needs to identify the addresses and the ledgers. To
>>>> interface
>>>> with existing ledgers, we would need account number, servicing bank
>>>> identifier
>>>> ...
>>>>
>>>> Thanks,
>>>>
>>>> Stephane
>>>>
>>>>
>>>>
>>>> ----------
>>>>
>>>> This post sent on Interledger Payments Community Group
>>>>
>>>>
>>>>
>>>> 'Registry Services'
>>>>
>>>> https://www.w3.org/community/interledger/2016/02/10/registry-services/
>>>>
>>>>
>>>>
>>>> Learn more about the Interledger Payments Community Group:
>>>>
>>>> https://www.w3.org/community/interledger
>>>>
>>>>
>>>>
>>>>
>>>
>>
>