Nomenclature proposal: "federated asset" (was Re: On Interoperability)

On Thu, Jan 12, 2012 at 12:37 PM, Pelle Braendgaard
<pelle@stakeventures.com> wrote:

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

Thus the need for a glossary and a layered model, instead of presuming
that all involved are experiencing the same "real world."

> 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:
>
> https://github.com/jplewicke/rivulet
>
> 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

The draft tipjar.com answer to this is to not support
non-participating currencies at all, beyond allowing people to
register their flavor of chit as a liaison for one. USD, for instance,
is represnted by "tipjar classic" which operates by paper checks
mailed to a post office box, and nothing more modern, by design. Call
that TJUSD. If someone else wants to also liaise for USD, they may,
ideally if PayPal wanted to be very kind to us they would register as
a competing liaison for USD and their symbol would be something like
PPUSD.

maintaining "nostro" accounts and offering each other credit lines on
an external currency that is liased by multiple entities can be done
entirely with currency definition and "give" functionality -- if Alice
gives Bob a 10000 USD credit line, that would be represented as Alice
defining a currency representing credit with Alice and issuing Bob
10000 USD worth of it. And so on.

One problem is, that "And so on" might not get spoken to an audience
who can see the "and so on" as a set of trivially collapsing dominoes
leading to wherever.

It's really quite the impressive magic trick, that all the financial
institutions honor each other's checks, and close to immediately, too.

So defining standards, or at least recommendations, for accounts
between trusted liaisons to a common external asset type seems like a
reasonable request. One might call it perhaps the "extension for
federation"  and refer to an asset type that is good at any
participating federation member a federated asset.

Received on Thursday, 12 January 2012 19:36:33 UTC