From: "Vladimir Z. Nuri" <vznuri@netcom.com>
Date: Mon, 20 Jan 1997 13:43:08 -0800 (PST)
To: Hal Finney <hal@rain.org>
Subject: Re: microcurrency: Netscape vs. Microsoft
Message-ID: <199701202143.NAA19163@toad.com>
MIME-Version: 1.0
Content-Type: text/plain



>> notice how much crypto really caught on when Netscape 
>> incorporated it, and how this action alone did more for
>> the proliferation of crypto in cyberspace, almost, than
>> all prior efforts combined. I think that microcurrency
>> will be unleashed in a very similar way.
>
>I assume you are referring to secure web connections via SSL in talking
>about crypto.  In that case there was a very strong pent up demand for
>the service.  Customers were afraid to send credit card numbers and
>other personal information across the web.  Sellers were pressuring the
>net server companies to do something to quell these concerns so on-line
>selling could succeed.  Netscape did it, and in the grand tradition of
>the net, implementation beat design and SSL defeated SHTTP.

neither has "beat" the other at this point. but this does show something
I have always believed: companies should just invent ad-hoc, quick-and-dirty
standards if full standards are not immediately available. it makes no
sense to me to delay the introduction of some new feature because there
isn't industry standardization. the case is often that the initial 
ad-hoc standards will tend to converge into a better standard down
the road. I don't see standards as "forever". standards should be
viewed as stepping stones to better standards. 

hence I think netscape and/or MS should invent a "plug and play" 
(i.e. trivial to use) micropayment standard immediately, regardless
of what industry standardization does not or will exist. it wouldn't
be pretty at first but standardization to better interfaces could
ensue later. the main thing is to get it on the table, and get
people using it, to create the demand. services are rarely developed
unless there is a demand. hence I suggest that a *rudimentary* form
of the service be first devised and implemented asap to increase
demand for one with much more finesse.

  In its early
>versions SSL had a lot of problems but it was a good enough solution for
>what it needed to be.

exactly.

>The question is whether there is similar market demand for pay per view
>web pages.

don't think this is a valid question. the whole point of microcurrency
is just decreasing the cost until people hit the page and don't
care about the cost. hence I think there is a guaranteed market, because
with microcurrency you can always shave off your price to virtually
infinitesmal values (say pennies a hit) that will guarantee you will
have at least some audience.

  Do web service operators think they can offer value added
>services which will motivate customers to click through the for-pay link?

I'm imagining just putting a teeny little transaction charge on top
of every single hit that now exists. if it is small enough, consumers
won't care very much.

>There is also the issue of sellers learning to use the various payment
>systems which are out there.  Here again if Netscape and Microsoft would
>just pick one then everyone could standardize on it, which would
>increase acceptance a great deal.

well, pick one payment scheme and then competing companies could
adopt the same standard (but offer competing systems and features)

>Ecash as it is implemented now has the problem that the customer has to
>open a special bank account.  What you need is a payment system where
>you can use your existing VISA card and withdraw cash against it into
>your electronic wallet.  This is pretty close to the FV model but their
>payment system is somewhat clumsy.

exactly. someone who reengineered the whole thing from top to
bottom and made it absolutely trivial to use-- I suspect the future
of the browser wars will belong to the company that does this.
again, I note it might be doable in a plug in, but as I said, I 
think browser manufacturers are eventually going to put it into 
their own code because of its sheer importance.