Re: Part 3: PaySwarm vs. OpenTransact Comparison

On Thu, Jan 12, 2012 at 1:58 PM, Manu Sporny <msporny@digitalbazaar.com> wrote:
> bcc: opentransact
>
> The interoperability that we're after is at least at the level of
> SMTP... where you can be on one server and send an e-mail to someone
> else on another server. The same sort of interoperability is required
> for payments... OpenTransact does not specify how you do that.

You are confusing "the transaction" and "the delivery", which is why
you misunderstood how I categorized ACH.  Payment networks cannot
always work like SMTP because SMTP has the benefit of both of these
actions happening in the same medium.  If I am paying you with gold
through an electronic system, at some point the gold has to be moved
from my vault to your vault, and unfortunately I can't do that with an
HTTP ;)  If I am paying with USD, a bank transfer has to happen at
some point (or someone needs to mail cash).  OpenTransact focuses on
recording the transaction, and not necessarily the delivery.  In a lot
of the situations we are talking about, the provider is the issuer and
ideally delivery happens instantly, and is irrevocable.  Maybe the
provider takes on the risk of delivery and gives instant
confirmation/availability of the transaction being recorded, but there
are obviously thousands of permutations of how this works in the real
world.

Also, there is nothing to hold back two clearing partners in a network
from settling delivery using standard OpenTransact, if it is
physically possible.

> As stated in the blog posts, we have a set of use cases[6] and we're
> addressing those. Any assertion that states that we're doing anything
> other than that, "boil the oceans", "socialism", "central planning",
> etc., is hyperbole. Your argument about a "supposed payment standard",
> and the assertion that "doing anything else should not belong in a
> payment standard" is a "No True Scotsman" fallacy[7].
>
> That is, arguing that one of the use cases is not useful or focusing on
> the technical concerns will be far more effective than making broad
> philosophical generalizations. What would be helpful at this time are
> statements of technical concern or issue, not broad philosophical
> assertions that will inevitably lead to perma-threads. "seems self
> detrimental to me" doesn't help us understand /why/ you think it's self
> detrimental - please list the reasoning.
>

I think you read past my criticism,   I am not talking about your use
cases, unless the documentation of your spec is confusing me.  I am
talking specifically about "2. The Conceptual Model"  The things you
outline here are business rules which will limit interoperability.
Limiting interoperability would be self detrimental since that is one
of your stated goals.

> Here is our take away from the conversation about Pelle's thinking on
> PaySwarm:
>
> 1. Doing more than just monetary transfer is not necessary.
> 2. Just about everything that PaySwarm is doing above pure monetary
>   transfer is out of scope.
> 3. Digital signatures in a payment specification is not necessary.
> 4. Metadata extensibility in a payment specification is not necessary.
> 5. The specification shouldn't combine all of these things together.
>
> We have responded to points #1-#4, and given our reasoning on why the 26
> features discussed in the original blog post matter. We already accepted
> point #5 as an editorial issue quite some time ago and will do our best
> to split the specs up once we're sure that we have the full picture
> outlined in a single spec (which is what we did with the JSON-LD
> specifications).
>
> So, please - technical feedback is far better than broad philosophical
> statements. I'll write a blog post on the security issues with the
> OpenTransact specification, and Pelle's most recent use cases, when I
> find the time.

The entire point (from my perspective) of specifications and standards
is to get people to come together philosophically around a common
problem, and then decide on a technical document that describes the
philosophy around solving that problem, which is why you are hearing
feedback about these issues instead of technical comparisons/flaws.

-Jake

Received on Friday, 13 January 2012 08:36:31 UTC