Re: Web Payments Telecon Minutes for 2012-04-03

[David Nicol]

On Tue, Apr 3, 2012 at 2:25 PM, Manu Sporny <msp...@digitalbazaar.com> wrote:

 

transfer [is] the most
  fundamental [operation]

It's possible to tear them into pieces with capability theory, that way one doesn't need, for instance, subtypes of "transfer" to distinguish "push/give" from "pull/take" initiations. 

David I. Lehn:  how do we handle cash?
Manu Sporny:  that's outside of the system and your handling
  deposits which puts you into bank territory

"banking" is about making loans. Handling deposits, or "cash handling" itself, is something that is associated with banks, as due to the reserve limit rules they must have some deposits before they are allowed to draft collateralized debt obligations. Accepting cash does not make an operation a bank any more than operating a hot dog stand makes an operation  a slaughterhouse. That's far too strong of imagery. If some other operation was to come along and arrange a network of trusted point of sale stations, for instance barristas and librarians, settling up quarterly -- would this "flydoughnet" cash interface be able to relate to payswarm using the terms of credit card infrastructure? Not without at least a little shoehorning.  Starting with capability theory as the basic building block -- capabilities and persistent mutable or immuable data -- promises to eventually provide some looser boots.

 

Manu Sporny:  if we're talking about a pay vocab then cash is a
  mechanism
David I. Lehn:  we're going a little too far, we should leave it
  open-ended enough to handle it in the future

a "mechanism" okay
 

Manu Sporny:  we might just break this up into sections to make

  the vocab a little clearer
Dave Longley:  it's sort of a way to add in layers like david
  nicol mentioned on the previous call
David I. Lehn:  we might have a better generalized way to
  approach all this so i think we need more experience
Dave Longley:  i think doign the layers is a good idea to try
  organizing this data and see if it works well instead of having
  to split vocabs up so much.
Manu Sporny: http://www.productontology.org/
Manu Sporny:  this describes any type of product you can think
  of, we could possibly reuse this.

Wow, that's a stunning service. Reading the introduction at the productontology.org web page I kept expecting the punch line " ... and this entire project was written by one of Paul Graham's students in only ninety lines of code."

Another very nice general tool, on the subject of general tools, is Porter's value chain, which can be made to model any business process (by definition, an activity that transforms inputs into outputs; the process of a meeting transforms time into communication for instance)


 

Dave Longley:  We could make it the general case that the
  PaySwarm Authority doesn't need to know the specific type of
  asset sold. The only concern is whether or not there are any
  rules that need to be applied based on the type of asset sold.

it seems to me that the only way to enforce per-asset-type restrictions (you can't buy cannabis without a prescription, et cetera) is to have a moment in the process where the asset type is given enough information about the transaction, including identity hooks to find out more if it needs it (no slot machine tokens can be sold to registered gambling addicts) so an asset type gets a chance to disrupt sales of itself. Any attempt to codify or enumerate further than providing hooks to asset types will surely fail, and at least one snarky name for why is surely available within four links of http://c2.com/cgi/wiki?AntiPattern

 

David I. Lehn:  i agree that the processing rules need to be
  things that are standardized and that we understand...
David I. Lehn:  there may be extensions, etc., but this shouldn't
  be free form

Unless the subject changed in there I appear to be opposed to Lehn on this point.
 

Manu Sporny:  the next thing that's up is the no additional
  payees rule.
Manu Sporny:  the reason that this exists is so that we can
  specify, in a listing (selling an article, etc), that they don't
  want any additional people adding fees to the item that they are
  selling
Manu Sporny:  so we definitely need that and it's not a general
  commerce thing it's specific to payswarm which is why it's here.

Well here's something that could become within the domain of things the final asset-side sale disruption check could do, the check finds out its final price after markups and if the asset is a ticket to see Fugazi in 1991 the asset will refuse to be sold for more than five dollars.

http://ezinearticles.com/?Fugazi---5-Dollar-Shows,-10-Dollar-Albums-And-1,000,000-Dollar-Passion&id=613602

One of my projects is a safe language for expressing exactly that kind of thing in. Which might be overkill. A little language consisting of algebra plus a few dozen names might be small enough to easily verify that it isn't trying to escape and then evaluate.