- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Tue, 7 Apr 2015 12:39:18 +0200
- To: Dave Raggett <dsr@w3.org>
- Cc: Web Payments <public-webpayments@w3.org>
- Message-ID: <CAKaEYhJx6QtoX6VW-thq=ta_vi1VLb6Y6s+Kg-GtujTm3Zxxqw@mail.gmail.com>
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. > My model is very simple. A wallet has a balance. It has a way to pay another entity. It has deposits and withdrawals. That's the main part of it, there's other things like an address book and integrations API, but that's secondary. What I discovered in programming a wallet with linked data is that when you program the single user case, the multi user case is not too much more complicated. So whilst I had originally considered writing one system for the wallet and one for the payment processor, I have found the same code can largely be reused for both. This lead me to realize that making the browser wallet multi user is not a lot of work, and offers interesting new functionality. > > 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. > Im very glad you brought up syncronization, because this is exactly the challenge I ran into. I have one wallet on my desktop, one in the office, and one in the cloud. I'd like them to be consistent without having to worry. Im still looking for a good way to solve this, right now I'm using an always on web server with websockets. But the P2P approach sounds very attractive, I just dont know how to do it. Also I quickly found the need for more than one wallet on my desktop. For example I use a payments workflow to track my own work, down to single keystrokes, I then record and aggregate that work so that I can review my day, check my productivity and generate reports. However I dont want every keystroke going into my 'main' wallet, I have smaller wallets that catch micro transactions and then periodically feed them up to the bigger wallets. You may think of this the way advertizing companies do micro payments such as pay per click, there could be 1000 transactions feeding into your balance, but you will only withdraw to your main bank account once per month. > > — > Dave Raggett <dsr@w3.org> > > > >
Received on Tuesday, 7 April 2015 10:39:47 UTC