Re: The difference between PaySwarm and OpenTransact

On Thu, Jan 12, 2012 at 3:26 PM, Dave Longley <dlongley@digitalbazaar.com>wrote:

>  On 01/12/2012 02:38 PM, Pelle Braendgaard wrote:
>
> Dave,
> No where does it mention that OpenTransact is for individual payment
> providers.
>
>
> To my knowledge, OpenTransact doesn't work across different payment
> providers -- and you seem to have said so yourself. That interoperability
> isn't there. Instead, it defines a standard API for working within a single
> payment provider. You might only have to write a tool to work with a
> payment provider once -- such that you can then switch it to any other
> payment provider that also implements the same API, but you can't
> communicate or initiate commerce across those two payment providers. You
> need a separate account with each provider.
>

OpenTransact definitely works across different payment providers. On
PicoMoney alone we have probably over 100 different OpenTransact assets
already and there are several different OpenSource implementations already.
As I mentioned earlier there are several local time banks using it. These
can all interoperate together.

What I seem to have a hard time explaining is the key to OpenTransact is
the Asset url. Each asset has one single url. However it can work just fine
across multiple providers.

So it is not a centralized protocol and never was. It is just for each
unique asset there is a central transaction processor. There could be 1000s
of different USD payment providers each one providing a USD based asset.
These could talk to each other as has been discussed in other threads.

I believe that integrating with the new OpenID Connect spec solves most if
not all the account interoperability issues. So if it is already being done
there why do we need to include it in OpenTransact?

http://openid.net/connect/


> PaySwarm, by contrast, makes online payment and commerce largely payment
> provider agnostic. A merchant doesn't have to list all of the payment
> platforms that they have an account with and then require their customers
> to go sign up with them in order for commerce to occur. OpenTransact makes
> no effort to change this current problem; it is out of scope. Similarly, it
> is out of scope in PaySwarm to tell a particular payment provider what API
> that they have to use or what authentication method they have to do other
> than what's necessary to facilitate commerce.
>

First of all besides having a destination IRI how have you solved the real
issues of interoperability? PaySwarm acts as it's magic. By adding a
destination IRI the funds just magically appear on the other side. I have
not been able to find anywhere in the spec where this is solved.

We realize that this is an important issue and have been talking about it
on the list the last 2 years. There are many ways of solving the issue and
yes we also recommend using URI's as account identifiers.

When I say things are out of scope I say they are out of scope of the core
OpenTransact protocol. They are certainly not out of scope of our
discussion. But we can not standardize something yet when there are 100s of
different ways of transporting the money.



>
> OpenTransact seems to want to be a general account delegation method,
> where a specific API (what to POST/GET from various URLs) must be
> implemented for the specific functions of financial delegation. This
> "encompasses only one way of doing things". Though, that's part of what a
> standard is about -- you provide only one way of doing things so that
> everyone knows what to expect.
>

This exposes the most simple atomic structures to application developers so
they can build and redefine commerce and finance in a way not possible if
you structure your standard around a single commerce model.

I would argue just by virtue of our focus on delegation, OpenTransact is
considerably more open, secure and interoperable than a system where you
have to share your private key.


> PaySwarm doesn't tell payment providers what their API must be for
> delegating general access to their customer's accounts. It spec's out only
> the delegation that is required for online payments and commerce is
> standardized (based on digital signatures). In fact, for more general
> access, you could use OpenTransact -- or any other technology. You could
> also simply use Oauth2 and invent your own API should you find that
> OpenTransact is insufficient. I'm sure that many payment providers will
> have more Oauth2 functionality that they'd like to expose on top of
> OpenTransact. This also means that many payment providers will provide
> their own API access tools anyway, so the people writing tools to access
> various payment providers will only need to link to the library for that
> payment provider. In other words, most of their tool (what makes it unique)
> will be write-once anyway. However, if all the payment providers out there
> used OpenTransact, there would only be one library that had to be linked to
> their specific (extra-functionality) library, so there is some benefit
> there.
>

By leaving that out of the specification you are eliminating at least the
following use cases, which all rely on mobile devices:

http://payswarm.com/specs/source/use-cases/#mobile-computing-based-purchase
http://payswarm.com/specs/source/use-cases/#point-of-sale-device
http://payswarm.com/specs/source/use-cases/#automated-vending


It is about creating a lively open ecosystem of payment providers,
> merchants, marketplaces and other kinds of apps.
>
>
> I disagree. It is not about an open ecosystem, but rather a closed one
> where everyone has to get an account with each payment provider -- or they
> can't do business with each other. Instead, my reading is that OpenTransact
> is about making it easier for people to write tools that link to the same
> library; or for payment providers to cut down on development time when
> providing their own libraries. I'm having a hard time seeing it as more
> than an API standard because of its interoperability issue and its silence
> on the payment silo issue that exists today.
>

As I explained above this is a huge misunderstanding and probably my fault
for not explaining it correctly. This is not about Silos. It's about
opening up silos and creating commerce and finance networks on the web.


>  The basic building block is a transfer. That transfer could encompass
> one or more transfers with business logic behind the scenes.
>
>
> Sure, but what I'm hearing is that someone else will have to build a
> standard on top of OpenTransact in order to make online commerce truly open
> and interoperable. At the same time, they'll have to do so with any
> inefficiencies that come from a standard that isn't forward looking
> (enough, IMO). There seem to be significant scalability (at least much is
> non-optimal) and atomicity issues with using OpenTransact, eg: to send
> payments to multiple people for the same asset. Without considering how
> applications may want to leverage OpenTransact to engage in more than just
> "the basic building block", there are a lot of open questions as to whether
> or not "the basic building block" is performant enough. A MySQL database
> stores data just fine for the most basic application. However, trying to
> get it to scale is a much more complex process. It is a good idea to think
> forward sometimes, especially when the use cases are out there -- and have
> been out there for many years (MySQL didn't have this advantage).
>

Bulk payment is an obvious important scaling issue we have not dealt with.
A bulk extension on top of or included in OpenTransact Core, but using the
exact same semantics is absolutely a good idea and does not conflict at all
with the basic concepts or semantics of OpenTransact.


> Another example of a potential issue with OpenTransact is exactly what we
> ran into when designing PaySwarm. You have said that digital signatures are
> a good idea and you'd like them to be built into OpenTransact in the future
> as an extension. However, if that's true, all of the same challenges that
> PaySwarm has solved will come up in that process. In fact, you may learn
> the same lessons and decide that Oauth2 duplicates the necessary delegation
> functionality required to facilitate commerce. Then you'd be stuck with a
> system with two methods of delegation that *must* be implemented in order
> to be compliant, instead of just one.
>

You have said yourself that digital signatures do not solve delegation.
Signatures and delegation are two very different things that solve two very
different problems.

> The biggest problem with PaySwarm is that it really encompasses only one
> way of doing things. Yes it's extendable but the specs makes many
> assumptions that limits it.
>
>
> PaySwarm only "encompasses one way of doing things" for what it is that it
> standardizes. PaySwarm enables interoperability between payment providers
> and facilitates online payment and commerce. It only standardizes what
> needs to be delegated in order for this to happen and gets out of your way
> for everything else. That is not a limitation, rather just the opposite.
> What PaySwarm does limit is only what it standardizes, which solves the
> challenges that anyone who wants to engage in open online commerce would
> otherwise need to solve themselves. I think it does so rather minimally,
> without being so basic that it ignores what I think are very important and
> long standing use cases for online commerce.
>

I beg to differ. It's SOAP vs Rest


> I would really like to see a joint set of standards bringing along the
> best of both worlds and that is what I had originally hoped the web
> payments group was about. My big complaint that started this debate was a
> seeming lack of will to do this from the PaySwarm team.
>
>
> I don't think there's a lack of will to work together at all, I just think
> that there's currently a misunderstanding of what the two standards do and
> where their strengths and weaknesses are. But that's what this conversation
> is about.
>

I agree there is a misunderstanding. I feel I have done more than my part
both on the lists and on the conference calls to try and steer things into
somewhere we can work together. I think Manu's borderline offensively
comparison table
http://manu.sporny.org/2011/web-payments-comparison/really did nothing
to help the conversation. I also admit my tone soured
then and I should not have used the "everything is out of scope" term.

Hopefully in tomorrows call we can be more civil and and talk openly about
what we can do to work together on this.

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