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

Anyway here is my rundown of the sections I missed.

Extensible Machine Readable Metadata

Manu’s section

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

Manu’s section

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

Manu’s section

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

Manu’s section

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

Manu’s section

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

Manu’s section

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

Manu’s section

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