Re: Micropayments: myth?

[Einar Stefferud <Stef@nma.com>]

Hmmm,,, In general, when someone says something this is misunderstood,
it is upon the speaker to make it understandable, though it of course
helps if the listener is trying to understand.

Shall we continue to argue about which of us are being responsible
speakers/listeners, or disucuss the subject at hand.

I fear that I did not see in yoru text any mention of requiring the
transfer of microcurency during the transaction.  Yes, of course, if
you solve the microcurrency problem, so that I am actually
transferring value while my "gas gauge" is measuring the flow.

But, without a solution to the microcurrency problem, you are speaking
in entirely hypothetical terms.  

This started as a discussion of micro-charging and micro-payment, and
now is a discussion of micro-currency, ala eCash.  As such, I have
nothing to contribute;-).,..

I somehow missed the conversion signals;-)...Cheers...\Stef

>From your message Thu, 20 Jun 96 12:05:55 -0700:
}
}
}more dazed and confused responses on microcurrency... why are people
}making this so complicated???
}
}From: Einar Stefferud <Stef@nma.com>
}>
}>Your analogy breaks because you do not provide for the corresponding
}>of connections between the gas tank and the dashboard indicator for
}>the case of buying small items from many different vendors.
}>
}>I can see each vendor site giving you a "gas gauge" indicator, either
}>showing how much you have cumulatively charged at a given site, or how
}>much is left on your prepaid site account (these are the same thing in
}>terms of adding up charges), but I fail to see how your analog applies
}>outside the local control of each vendor site.
}
}the *vendor* *does*not* control the "gas gauge". the gauge is presented
}by your LOCAL SOFTWARE. (for those late into this, the gas gauge analogy
}is used as a visual metaphor for the way a browser would keep track
}of microcharges).  it would make *no*sense* for each provider to
}create their own gauge. they might create one for their own site
}of your transactions, but you absolutely must have a tracking mechanism
}that is built into your own software and NOT under the control of the
}outside agency. 
}
}don't people get this? with microcurrency, you don't say to a 
}seller, "bill me for this item". it would rarely work like that at
}all. instead, it is, "here is my money, please give me the item". 
}the money exchange is always part of the complete transaction. 
}billing is an archaic concept in this paradigm that is superfluous.
}you only need it when you can't have instantaneous transactions.
}
}>In short, you have again shown that microcharging systems are limited
}>to local accumulations.  Your gas tank example is limited to the car
}>you are driving, and does not tell you anything about anything else.
}
}the gas gauge analogy seemed transparently obvious to me. 
}you are proving a rule I've noted in cyberspace, that if anything
}can be misunderstood, it will be.  you are confusing yourself. 
}
}the analogy would be more like the
}following: you can drive on different roads, and some take more
}gas than others. but the roads cannot themselves suck gas
}out of your tank or change your gas meter.
}
}>Unfortunately, you appear to be applying the idea to a collection of
}>vendors which you wish to visit, which means that someone somewhere
}>must be getting the disparate charges from different vendors to update
}>your singular gas gauge.
}
}NO, NO, NO!!!! your local software controls your gas gauge. NOBODY
}ELSE. furthermore, the site *never* grabs money from you. this is
}a *billing* paradigm. you either send money, or no money can
}be transferred. the site can *request* money but such a system
}would only be automatic if the charge fell within the minimal limits
}set by the user (i.e. max $1.00 per hour, max 5c per transaction,
}max 10 transactions per minute, or whatever--  all this is 
}trivial to implement)
}
}>Drawing analogies is great fun, but all analogies break at some point
}>in their life, because they abstract away enough detail to paint a
}>simplified picture.  Sometime this leads to complete failure to map as
}>intended.
}
}analogies are meant to help people understand something simple. if the
}thing itself is simple, and people can't even understand it in
}the simple state, often the analogy will confuse them even further.
}
}>}The billing happens, as others have previously noted, entirely at the 
}>}client side.  There's no reason the wallet or web browser can't keep a 
}>}log of expenditures, and there's no chance for spoofery at that point 
}>}(the wallet knows where it sent money).  
}
}I wish people would stop talking about BILLING in regard to microcurrency.
}I believe it is mostly a flawed concept that is not largely going to
}apply to microcurrency. perhaps some other term is appropriate, any
}takers? it seems to me a lot of the misconceptions I've been seeing
}are based on the idea that BILLING would somehow be involved. 
}billing is involved in cash systems in which you dissociate the
}transfer of material from the transaction. this will generally
}not happen with microcurrency imho, and it is largely only useful
}with transactions that allow coupling of the material and the money
}in one swipe, such as for a http file download or whatever.
}