Universal payment API. Re: Legacy systems vs blockchains - what is the spec impact?

On 2014-10-24 20:13, Daniel.Buchner wrote:
>> I guess (on thin ice here...) that a receiver (payee) looks into the
>> distributed ledger for proof of transaction.
>
> "I doubt that anyone seriously expects a mobile app to store a whole
> block chain; in practice, a user of a blockchain system communicates
> with a specialist, reducing the situation to federation."
>
> The difference here is that the app in question could self-certify transactions with its own server using direct blockchain queries. The apps own server can install the bitcoind package and process confirmations itself. This is not a federated reliance on a large provider like Blockchain.info.
>
> My main area of interest is in the user stories for developers and consumers. Obviously developers want to reach a broad consumer base, and today that includes mostly legacy credit/fiat systems of value transfer - that's just the reality. Given these business requirements, I completely agree that the standard must (and should) allow for all types of value transfer over N systems.
>
> However, I wonder if we can allow for a more streamline flow, within the same set of APIs, if the dev or user chooses a payment type that does not require all the same steps as other value transfer systems. Maybe the proposals already allow for this, I need to do more investigation (talking through it at TPAC will help). In the end, my only desire is to arrive at a place where the standards we create do not impose needless steps on every value transfer system plugged into it, if that can be avoided (note: I am not saying what you currently have does this).
>
> For now I'll do more research and get up to speed with all the material. I have nowhere near the level of insight I need to make any statements about the current work. Let me know if I've anything in error - after all, you have far more insight into the details of these proposals and what they must account for.
>
> Thanks for the discussion thus far, I can't wait to learn more,

I believe it is a mistake trying to wrap all payment systems into a single API.
This will likely only stifle innovation and prolong the standardization process indefinitely.

I think the "stack" is more important and that actual W3C standardization (if ever
taken on...) will concentrate on that rather than full-fledged payment protocols.

Just my 2 öres (nowadays 2 centimes).

Regarding the stack itself, there will probably be a slight clash between
those like me who believe that the platforms must be improved as a part of
the stack and those who want to innovate within the existing limits and
cover those with "polyfill".

A payment scheme like shown on https://mobilepki.org/WebCryptoPlusPlus
requires major platform upgrades.  OTOH, that didn't stop Apple!
If such requirements stall the W3C process, then we may have to
find other ways ahead or give up.  Many important platform standards
are nowadays rather developed as open source like for example
http://www.linaro.org

Timing may in the end turn up as the most important factor for adoption.

Anders

>
> - Daniel
>
>
> ________________________________________
> From: David Nicol [davidnicol@gmail.com]
> Sent: Friday, October 24, 2014 7:59 AM
> To: Anders Rundgren
> Cc: Reutzel, Bailey; Manu Sporny; Eric Martindale; Web Payments
> Subject: Re: Legacy systems vs blockchains - what is the spec impact?
>
> On Fri, Oct 24, 2014 at 1:57 AM, Anders Rundgren
> <anders.rundgren.net@gmail.com> wrote:
>
>> I guess (on thin ice here...) that a receiver (payee) looks into the
>> distributed ledger for proof of transaction.
>
> I doubt that anyone seriously expects a mobile app to store a whole
> block chain; in practice, a user of a blockchain system communicates
> with a specialist, reducing the situation to "federation."
>
>
> --
> Sometimes I imply things, or include important information in
> pictures. Without a request for clarification, I will assume I was
> clear, which can cause later problems when I wasn't. So please ask me
> to clarify anything that seems ambiguous. Doing so is not rude. Thank
> you.
>

Received on Friday, 24 October 2014 19:58:28 UTC