W3C home > Mailing lists > Public > public-webpayments@w3.org > April 2015

Re: decentralized wallets and payment processors

From: Jorge Zaccaro <jorgezaccaro@gmail.com>
Date: Tue, 7 Apr 2015 22:18:52 -0500
Message-ID: <CAPnSDnPkQBPh=ATpptTjnRSK92sTVSp4rSnnNOcjD0ZzAz1=AQ@mail.gmail.com>
To: Melvin Carvalho <melvincarvalho@gmail.com>
Cc: Adrian Hope-Bailie <adrian@hopebailie.com>, Anders Rundgren <anders.rundgren.net@gmail.com>, Web Payments <public-webpayments@w3.org>
On Tue, Apr 7, 2015 at 6:44 PM, Melvin Carvalho <melvincarvalho@gmail.com>
wrote:

> 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.
>

Making use of forward search and linked data makes perfect sense when
building a wallet for the Web, not only for the semantic benefits for the
Web itself, but also for the navigational interactions that are opened up
to applications when complying with the REST's HATEOAS constraint (
http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven).

Getting to a well defined way of navigating a wallet graph might be a
little bit more difficult, but I'm optimistic about agreeing on basic
schemas for defining relationships (most of them already in place, e.g.
card->parent = wallet, wallet->transactions), and then using a hypermedia
specification like Siren (https://github.com/kevinswiber/siren) to group
the hyperlinks related documents and state transitions using just a few
simple categories like "entities" and "actions".
Received on Wednesday, 8 April 2015 03:19:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:39 UTC