1997-01-20 - Re: microcurrency: Netscape vs. Microsoft

Header Data

From: “Vladimir Z. Nuri” <vznuri@netcom.com>
To: Alan <alano@linda.teleport.com>
Message Hash: 65495bc7571052a3dda213c239bafa9a2b3d7408bffc5bdfe5b62adb48ce0035
Message ID: <199701201946.LAA14921@netcom4.netcom.com>
Reply To: <Pine.GSO.3.95.970118145332.29052B-100000@linda.teleport.com>
UTC Datetime: 1997-01-20 19:48:15 UTC
Raw Date: Mon, 20 Jan 1997 11:48:15 -0800 (PST)

Raw message

From: "Vladimir Z. Nuri" <vznuri@netcom.com>
Date: Mon, 20 Jan 1997 11:48:15 -0800 (PST)
To: Alan <alano@linda.teleport.com>
Subject: Re: microcurrency: Netscape vs. Microsoft
In-Reply-To: <Pine.GSO.3.95.970118145332.29052B-100000@linda.teleport.com>
Message-ID: <199701201946.LAA14921@netcom4.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


[microcurrency]
>It will also not catch on until there are better standards involving
>microcurrency transactions amongst the vendors.  It would also help if
>there was a single interface (or "helper app") for whatever vendor you
>decided to go with.

as I see it, I think there are a few key standards that need 
to be devised: 

1. an html tag that indicates how much a link costs, probably in
the <a href="" cost=xx> type syntax

2. modification of http to support a payment mechanism, by sending
a token.

3. browser "piggy bank".

there are other standards, such as how a person might get
cash into their piggy bank etc., but most would be related to
the above items. 

notice that we don't really need a good interoperable standard
to begin with. often Netscape and MS invent tags that are not
interoperable between them, and later standardization arrives
at a consensus / convergence. as I see it, I think the browser
manufacturers should just pick their favorite digital cash
scheme (cybercash, digicash, whatever) that is easiest to
implement, and do so, with the intention of integrating other
schemes at a later date.

>Currently every vendor of payment schemes has made it proprietary in some
>way.  (At least the ones I have seen.)  This means that if the user visits
>three different web pages, each using a payment scheme from a different
>vendor, that user has to be signed up with all of those vendors.  (Or at
>least have their helper apps.)

hence, a good opportunity for the browser manufacturer to remove
all these additional complications and make it point-and-click
simple. I agree, this is not going to be a total nonbrainer. but
better the browser manufacturer do it for their software, allowing
everyone who uses it to benefit, than every single cash user
in cyberspace trying to replicate the same difficult series of
steps to get their cash going.

>I will not even go into the hastles of trying to set it up from the server
>side.  (The last payment scheme I installed (cybercash) was not very well
>documented.  The documentation on the web site contradicted the software
>with the tar file.  (And both were wrong at some point.))  Until these
>payment schemes are easier to deal with for the web page provider, they
>will not catch on.  (There will also need to be more support for Internet
>service providers with multiple vendors all on different payment schemes.)
>
>Until there is a single standard hammered out, micropayments will still be
>few and far between.

generally, that's what I'm calling for, some ad hoc standards being
put into place immediately by the browser manufacturers, in the
same way new tags are always being invented. standardization generally
results *after* an initial, minimally constrained innovation phase, imho.







Thread