Re: decentralized wallets and payment processors

On 7 April 2015 at 10:52, Dave Raggett <dsr@w3.org> wrote:

>
> On 7 Apr 2015, at 01:40, Melvin Carvalho <melvincarvalho@gmail.com> 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?
>
>
> I guess depends upon what function you want to be realised by wallets.
> The analogy with personal physical wallets and purses points to the idea of
> digital wallets that hold “cash”, payment cards, loyalty cards, identity
> cards, prepaid vouchers, discount coupons and tickets. This model presumes
> that each wallet belongs to a single person.
>
> A related perspective is on wallet synchronisation.  Imagine that a user
> have the same wallet installed on a number of different devices. The aim is
> to synchronise changes when the wallets are online. For instance, copying
> new receipts to the other wallets. Synchronisation would also apply to user
> preferences, and to payment instruments.  This could be implemented via
> keeping a copy of wallet in the cloud, or via peer to peer connections
> where each instance of the wallet has the list for the set of instances.
> The peer to peer approach is more complex as you need to allow for devices
> being offline so that they have to be synchronised later when they next go
> online.  Moreover in principle, there could be more than one wallet with
> new receipts etc.  One solution involves a mechanism for electing one of
> the devices as a temporary master that manages version control. Another
> solution is based upon clock synchronisation.
>

Dave, I've been thinking a lot about sync lately, during my testing phase.

I think traditional methods for sync here are not going to meet my needs.
I'm thinking more along the lines of UNIX IPC.  In particularly, shared
memory and messaging.

In the case of shared memory, two wallets will have the same URI and then
merge when connections allow.

In the case of messaging wallets allow information to flow like water in a
network.  This becomes more spontaneous.  I envision a web of wallets, a
user may have many wallets all talking to each other and triggering
things.  Your fridge may order food on your behalf when it gets low.  A
family may have a shared area for photos and video, with payments triggered
as more files are uploaded.  A person may track their work locally for
analysis, then send a summary to employers and accountants etc.

Importantly, I no longer see a distinction between payment processor and
wallet.  A payment processor to my mind is just a multi user wallet.  I
like the wallet metaphor in this context.  It's not hard to create and
destroy wallets spontaneously, to add block chain technology over the web,
to deploy smart contracts in javascript and to have personal coinbases (aka
currency mints) regulated via a ripple-like web of trust.

The reason I take the UNIX analogy is because I see the next gen of the web
becoming much more like an operating system, than a browsing space.  Some
of this may probably be suitable for v2.0 of the web payments spec.  But I
probably will have it all coded up and working in an MVP by the time v1.0
is out.


>
> —
>    Dave Raggett <dsr@w3.org>
>
>
>
>