Re: decentralized wallets and payment processors

On 7 April 2015 at 20:12, Adrian Hope-Bailie <adrian@hopebailie.com> wrote:

> I'm interested to hear how you think linked data solves this problem.
> For me it is the single biggest issue plaguing the work of this group and
> the Credentials CG.
>
> Any discovery protocol has to start with an identifier (URI, email
> address, URN, whatever) and end with the URL of a resource that is the
> start of a linked-data graph describing the entity that holds/owns/is
> represented by the identifier.
>
> Today, all identity systems except the one proposed by the W3C Credentials
> CG use DNS in some way to do discovery.
>
> What is missing is a decentralised data store that can serve as the
> registry for these identities. The Credentials CG has proposed Telehash as
> this data-store.
> The challenge is that one then has to be explicit in defining the
> discovery protocol as to which decentralised data store to use.
>
> If someone proposed the namecoin block-chain as an alternative how do we
> decide which to use?
> Who will the stewards of this decentralised data store?
> Is there an architecture for this data store that would be rubber-stamped
> by the W3C as a cornerstone for dependent recommendations?
> (Here I am trying to think of an architecture that incentivises
> participants to maintain the network assuming that financial incentives
> aren't practical)
>

There are generally 3 strategies for discovery, they are not mutually
exclusive, but can be used in combination, these are implementation

Aside: let me quickly define two terms, forward search and reverse search.
Forward search is how the web got going, it's when you type in (or paste,
or click) a URL for a document and get back the document + words.  Reverse
search (which these days is more common) is when you type in words and get
back URLs.

Both forward search and reverse search are discovery methods.  Forward
search generally requires following a protocol, such as HTTP, which is
great from an engineering perspective.  Reverse search requires access to
an knowledge base and preferably index.  Reverse search is much more
uncertain from a standards perspective because you dont konw that you'll
get what you were looking for.  A good example of reverse search may be a
facebook user authenticating via their email address, and facebook using
that as a foreign key to their graph protocol URL.

The third discovery method is the well known pattern, where you look in an
agreed or hard coded place.  Not great engineering, but can be a good fall
back.

I'm not proposing any one of these methods as part of a standard, to be
clear.  Just going over common patterns.

What I can say is that linked data is a style of forward search where data
finds more data.  So from a user you can find a payment processor.  From a
payment processor, you can find a name, public key, API area, transactions,
balances and so on.  In linked data the preferred identifier is an HTTP
identifier because it has two advantages, namely a large network effect
(many things talk HTTP) and it's dereferencable by design.  Im not saying
that HTTP is the solution to all problems, but on the web these two
properties have proven to be useful, so far.  However none of these methods
are *limited* to HTTP, it's just that HTTP offers well tested engineering
possibilities.

The wallet I am making makes mainly use of forward search, sometimes called
"follow your nose".  The hardest part is to find a pointer to the user, but
after that most things are discoverable.  When forward search hits a dead
end, you could give up, or create a probe sequence for other methods such
as looking at your index/cache or a well known location.

What is required is a well defined way of getting from a user to all the
information you need for a wallet, namely balances, history, payments area,
and meta data.  That is what I'm trying to get to proof of concept with.

The sync part requires more thought, and Im interested to brain storm.

Hope that makes sense!


>
>
> On 7 April 2015 at 03:44, Melvin Carvalho <melvincarvalho@gmail.com>
> wrote:
>
>>
>>
>> On 7 April 2015 at 11:46, Anders Rundgren <anders.rundgren.net@gmail.com>
>> wrote:
>>
>>> On 2015-04-07 02:40, Melvin Carvalho wrote:
>>>
>>>> I've been sketching out an implementation of a payment processor and
>>>> wallet system lately
>>>>
>>>> Turns out decentralized wallets are a really hard problem to solve
>>>>
>>>> Some thoughts I had:
>>>>
>>>> 1. A multi user wallet, seems to be roughly the same thing as a payment
>>>> processor, when in a decentralized environment
>>>>
>>>> 2. A decentralized payment wallet / payment processor should be able to
>>>> largely live in the browser
>>>>
>>>> Note: I'm looking at this from the perspective of crypto currencies to
>>>> start with.  Fiat may require more thought / work.
>>>>
>>>> Some questions:
>>>>
>>>> Would these two goals be desirable to the group, because it's what I'm
>>>> trying to create?
>>>>
>>>> Are there any technical barriers why this would be impossible using web
>>>> technology?
>>>>
>>>> Or is it out of scope for this version?
>>>>
>>>
>>> IMO, the #1 problem with decentralization is service discovery.
>>>
>>> The rest shouldn't be harder than for example PayPal.
>>>
>>
>> I agree this is a major problem.  Fortunately linked data was designed
>> exactly to solve this problem, so I think this group has an advantage in
>> that respect.
>>
>> My current thoughts are to allow the user to have have a wallet / payment
>> provider linked from their identity and the software will be able to follow
>> those links to get further information.  Specifically we've talked about
>> adding the comm : paymentProcessor predicate to the commerce ontology.
>>
>>
>>>
>>> Anders
>>>
>>
>>
>