Re: Part 2: PaySwarm vs. OpenTransact Comparison

*OpenTransact vs PaySwarm part 2 - yes it's still mostly out of scope*

Generally this post will again reflect the differences in approaches.
OpenTransact is a single layer simple pragmatic standard for performing
payments nothing else. PaySwarm is a fully featured idealistic multi
layered approach where you must buy into a whole different way running your
business.

A Facebook friend suggested that OpenTransact vs PaySwarm is like
Libertarianism vs Socialism. I don’t quite buy that in practice as I know
that PaySwarm is not about forcing anyone to do anything.

However the basic PaySwarm philosophy of wanting to design a whole world
view is very similar to central planning or large standards bodies like
ANSI, IEEE etc. OpenTransact follows the market based approach that the
internet was based on of small standards that do one thing well.

Anyway here is my rundown of the sections I missed.

*Extensible Machine Readable Metadata*

We specify JSON for responses. Manu correctly says that we don’t have a
specific mechanism of extending this format. Again this falls completely
out of the scope. An extension could easily be done using JSON-LD as
JSON-LD is simply an extension to JSON.

I don’t think it would help the standard by specifying how extensions
should be done at this point. I think JSON-LD is a great initiative and it
may well be that which becomes an extension format. But there are also
other simpler extensions that might better be called conventions that
probably do not need the complication of JSON-LD. Such as Lat/Lng which has
become a standard geo location convention in many different applications.

*Transactions*

I don’t like the term transaction as Manu is using it here. I believe it is
being used here using computer science terminology. But leaving that aside.
OpenTransact does not support multi step transactions in itself right now.
I think most of these can be easily implemented in the Application Layer
and thus is out of scope of OpenTransact.

I could see a bulk payment extension supporting something similar in the
future. If the need comes up lets deal with.

*Currency Exchange*

Exchanges are done between currencies or other kinds of assets in many
different ways. We have discussed it a lot on the OpenTransact mailing
list. But most of us have come to the conclusion that we may be able to get
away with just using plain open transact for this. This led us to some of
the changes we proposed to OpenTransact in October.

An example of this would be an exchange application providing OpenTransact
URL’s for each exchange type. Eg.


   - http://cambio.example.net/usd/eur for US$ to Euro exchanges.
   - http://cambio.example.net/eur/usd for Euro to US$ exchanges.


An exchange could be performed to exchange $100 to Euro using a simple
OpenTransact Transfer Request:

http://cambio.example.net/usd/eur?amount=100

The to field would not be necessary as the exchange would either be the
market maker or match an existing open transact order.

Notable omissions here are exchange price quoting which I think would make
a great OpenTransact extension. For interactive applications the price
would be shown as part of the TransferRequest to the user and application
specific questions can be asked.

*Decentralized Publishing of X*

   - Decentralized Publishing of Items for Sale
   - Decentralized Publishing of Listings
   - Decentralized Publishing of Licenses
   - Digital Contracts
   - Affiliate Sales

These features listed are necessary if you subscribe to the world view that
the entire worlds commerce needs to be squeezed into a web startup. I think
they would make a great standard in it’s own right that could be published
separately from the payment standard. Maybe call it CommerceSwarm or
something like that.

I believe they are at a higher level of abstraction than a payment and are
thus out of scope. If supporting these are a requirement for an open
payment standard, I think it will be very hard for any existing payment
providers or e-commerce suppliers to support it as it requires a complete
change in their business, where OpenTransact provides a fairly simple easy
implementable payment as it’s only requirement.

If you were to create such a new standard OpenTransact does provide all the
lower layer payment primitives necessary.

*Verifiable Receipts*

I like the idea of a verifiable receipt. I want verifiable receipts.

Most commerce sites now a days provide a verifiable receipt via email. I
believe though that this is one of the valid applications of digital
signatures.

However I don’t want us to stall the development and implementation of
OpenTransact by inventing a new form of PKI or battling out which of the
existing PKI methods we should use. See my section on Digital Signatures in
the last post.

Thus we have taken the pragmatic approach of letting businesses do what
they are already doing now. Sending an email and providing a transaction
record via their web site.

*Secure X-routed Purchases*


   - Secure Vendor-routed Purchases
   - Secure Customer-routed Purchases


These are neat applications that could be performed in some way through an
application. You know I’m going to say it’s out of scope of OpenTransact.
OpenTransact was designed as a simple way of performing payments over the
web. Off line standards are thus out of scope.

*Currency Mints*

Also see his section on Alternative Currencies in his 2nd post

The currency mint is not equivalent to the transaction processor. Making
that assertion conflates two important concepts; 1) the issuer of a
currency, and 2) the transaction processors that are capable of transacting
in that currency. To put it in different terms, that’s as if one were to
say that the US Treasury (the issuer of the USD currency) is the same thing
as a local bank in San Francisco (an entity transacting in USD).


Manu is mistaken here. In a modern book entry based alternative currency
the transaction processor is most often the same as the mint. It is however
not the same as the issuer. The issuer is the entity who maintains the
liability on their books for the amount of value issued.

EG. In my own private currency Pelle Hours the currency issuer is me but
PicoMoney the company is the mint and transaction processor.

The minting of currency in the physical world is obviously a separate case.
In the electronic world where currency consists of nothing more than a
ledger there is no need for the traditional requirement of a payment
processor. Besides BitCoin all modern alternative currencies have the mint
and the transaction processor as the same entity.

There is simply no need for a payment intermediary when the source of the
currency is online. With OpenTransact it would be possible to create proxy
or derivative currencies on other currencies, similar to what PayPal and
Dwolla do with USD.

*Crowd-funding*

Saying that you can not do crowd funding with OpenTransact is like saying
you can’t do Crowd Funding with http. Obviously KickStarter and many others
are doing so and yes you can do so with OpenTransact as a lower level
building block.

*Data Portability*

We are very aware of concerns of vendor lock in, but as OpenTransact is a
much simpler lower level standard only concerned with payments, data
portability is again outside the scope. We do want to encourage work in
this area.

I have previously proposed Wide Ledger as a simple microformat/json interop
format for transaction data. I hope more work can be done with this in the
future.

I will follow up with yet another post responding better to Manu’s second
post

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

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

Received on Monday, 2 January 2012 21:01:53 UTC