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

On Tue, Apr 3, 2012 at 2:25 PM, Manu Sporny <msporny@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.