On Interoperability

4 views
Skip to first unread message

Pelle Braendgaard

unread,
Jan 12, 2012, 1:37:54 PM1/12/12
to Web Payments, opentr...@googlegroups.com
OpenTransact is all about interoperability. That is why it was created. I have been quite perplexed to be honest where this comes from.

It is not just library interoperability. 

It is trusting that my application can work with many different providers.

It is allowing people to create new interesting derivative open transact services on top of existing services.

It is also about letting me bring my transactions with me and maintain them in a separate app.

However as I understand it the very narrow definition of Interoperability that Manu believes we don't support is:

I want to pay someone from my PayPal account and having it show up in my Moms Dwolla account.


Just like when you in a bank can send money from one bank to another.

Before I start going through the issues here. I would like to ask where PaySwarm specifically specifies how to move money from one payment provider to another? I can not find it in the spec.

What we realize though is that there are many different ways payment services can interoperate.

This is not as simple as defining a protocol. There are many different issues here.

Like how do I as PayPal move money to Dwolla? That is not an API issue.

Traditionally in the US you can abstract that away to banks via the ACH network and SWIFT internationally.

PayPal and Dwolla both use ACH to move money between peoples bank accounts.

The way money is moved in banking has traditionally been through banks maintaining "nostro" accounts within each other. 

So if I have an account with CitiBank and want to send $20 to someone in Wells Fargo. Citi would credit Well's Fargos nostro account $20 and tell them to send it to their customers account. Chase would charge Citibanks nostro account $20 and move that into their customers account.

Every now and then (in the old days) you would have to physically move money or gold to maintain good nostro account levels.

This was later modernized by having central banks deal with such movements in a centralized ledger, so individual banks didn't have to have connections with everyone.

In a web payment 1.0 world PayPal and Dwolla use ACH to abstract away all of that.

In a web payment 2.0 world without ACH things are different. We want to move money between two of possibly thousands of payment providers, we need either a distributed graph of connected payment providers each with "nostro" accounts with each other or a few central players.

I like the distributed graph model myself. The most important proposal in this space is Ryan Fuggers Ripple project http://ripple-project.org/

There is actually an OpenTransact implementation of it called Rivulet here:


These are currently all based on a central graph database. But the ideas could definitely be implemented in a distributed way using OpenTransact.

The point of all of this is interoperability can mean a lot of things. Also that sending money from one institution to another is not quite as simple as it is made out.

P


--
http://picomoney.com - Like money, just smaller
http://stakeventures.com - My blog about startups and agile banking

Guillaume Lebleu

unread,
Jan 12, 2012, 2:06:23 PM1/12/12
to opentr...@googlegroups.com, Web Payments
I completely agree with this. 

What the payment space needs is a way to authorize and clear in *real-time* the transfer of liability, via a chain of debit/credit on the balance sheet of various nodes (credit intermediaries), whether official banks or not. The challenge is to be able to discover nodes that can participate in this chain based on the preferences of the parties to the transaction, and then be able to commit that chain of transactions.

The interesting thing is that every transaction in this chain is a transaction on a credit intermediary's balance sheet, from one account of an issuer of assets to another account at the same issuer, so OpenTransact fits really well this model.

Guillaume Lebleu

Melvin Carvalho

unread,
Jan 12, 2012, 2:33:48 PM1/12/12
to opentr...@googlegroups.com, Web Payments

Just a question about this (hopefully related to interoperability).

Why use a central graph database when the Web is already a highly
scalable distributed graph database, with namespaces?

Pelle Braendgaard

unread,
Jan 12, 2012, 2:44:09 PM1/12/12
to opentr...@googlegroups.com, Web Payments
A very good point and that is where I and many others think OpenTransact can really shine.

To avoid centralization, I prefer it starting informally through a smaller network of payment providers, learning from that and creating more formalized structures probably based on Ripple afterwards.

OpenTransact is already well represented in the community currency space and will hopefully be more so in the next year. Several people in the UK community currency space are working on creating more formal networks between each other already.

P

Manu Sporny

unread,
Jan 12, 2012, 8:43:28 PM1/12/12
to Web Payments, opentr...@googlegroups.com
On 01/12/2012 02:06 PM, Guillaume Lebleu wrote:
> What the payment space needs is a way to authorize and clear in
> *real-time* the transfer of liability, via a chain of debit/credit on
> the balance sheet of various nodes (credit intermediaries), whether
> official banks or not. The challenge is to be able to discover nodes
> that can participate in this chain based on the preferences of the
> parties to the transaction, and then be able to commit that chain of
> transactions.

Could you explain a bit more Guillaume? I'm pretty sure we already do
this in PaySwarm (discovery of nodes and transfer of liability).

Discoverability because every IRI used in the PaySwarm protocol can be
dereferenced and machine-readable information can be extracted from it.
All IRIs are human- and machine-readable (HTML for the human part, RDFa
for the machine-readable part). That is how we do discovery.

Transfer of liability is explained in the link to the archive at the end
of this message.

> The interesting thing is that every transaction in this chain is a
> transaction on a credit intermediary's balance sheet, from one
> account of an issuer of assets to another account at the same issuer,
> so OpenTransact fits really well this model.

I disagree. While that may be the intent for OpenTransact, it is not
technically implementable in an interoperable fashion, based on the text
in the current specification. It has also been asserted that specifying
this as a part of the Core specification is out of scope. Have you read
this yet, Guillaume?

http://lists.w3.org/Archives/Public/public-webpayments/2012Jan/0025.html

It explains why I do not think OpenTransact systems are interoperable.
If you could explain where I go wrong, I'd appreciate it.

-- manu

--
Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: PaySwarm vs. OpenTransact Shootout
http://manu.sporny.org/2011/web-payments-comparison/

Reply all
Reply to author
Forward
0 new messages