Re: Brands excluded from digicash beta

[db@Tadpole.COM (Doug Barnes)]

> 
> Maybe it's just me. As a beta-shop owner, I expect to have Digicash
> work with me when I have problems, concerns, or questions. Marcel,
> Paul, and others at Digicash were very helpful during the incubation
> period. My chief concern at this point is that there's no way for me
> to get paid, and no publicly available date for same.

There have clearly been problems in communication and in 
expectation-setting. In particular, since DigiCash is not,
to the best of my knowledge, planning on entering the 
US$ cash <--> ecash business themselves (instead, using
licensees), it might have been a wise move for them to set 
expectations lower or to have taken steps to guarrantee at 
least a trial US$ cash <--> ecash gateway.

> I think their attitude is that crypto's not _necessary_. I disagree;
> Nathaniel Borenstein has already been taken to task on www-buyinfo for
> that view. Their API supports TCP/IP transactions, so the mail
> exchange is between the FV server and the buyer.

If you've used the DigiCash clients, you know that they make it
much, much easier to spend money than this e-mail confirmation
system. Since they don't use crypto (and instead rely on the
debatable assumption than an e-mail backchannel is secure, backed
up by extreme reversability). This is not to say that someone
couldn't remedy these problems along the same lines as DigiCash
without using blind signatures or licensing from Chaum, however.

> 
> The very fact that FV has a set of terms and conditions that mention
> exposure time, responsibility for fraud, and so on tells me that their
> system is more fully fielded. I know, I know; ecash is in beta. That's
> fine. I still want to be able to sell things _now_.
> 

FV may be more operational, although I'm curious if any transactions 
have managed to fully settle yet... yes, it is important for the operator 
of a US$ cash->ecash gateway to consider fraud and exposure, but the 
_protocol_ determines that e-cash transactions are non-reversible, like
putting coins into a vending machine. The gateway operator has to either
use non-reversible US$ inputs, or needs to determine an acceptable level
of exposure to reversible transactions.

The two systems are worlds apart in terms of where the risk is placed.
FV places the risk entirely on the vendor; DigiCash places the risk
entirely on the e-cash holder. Note that lots of people walk around with
credit cards, bills _and_ coins in their wallets, and use them for different 
things throughout the day. I don't think that things are going to be
that different on the net.

> On the other hand, I can't use ecash for hard goods. I have no idea
> what the transaction costs will be, and there's no way for sellers to
> get paid _at all_.

This is absolutely true, and will remain so until at least one
of Chaum's licensees becomes operational. 

> I happen to agree with the portion about
> allowing try-before-you-buy access; in some cases that is a very
> valuable way to gain market and mindshare. Remember the "Macintosh
> Test Drive" in 1985?

I think that if people want try before you buy, it can be done
(easily) without building it into the payment protocol. I'm 
all for shareware, giving freebies so folks get hooked, and
so forth, but it seems odd to build a unconditional rejection into
the payment system, especially for products that can't be
returned in any meaningful sense.

> Not. Read their web pages. There's a TCP/IP API, which I'm using. The
> only mail exchange is from the FV server to the customer and back
> again. As Hal pointed out, there are valid reasons to support systems
> other than the Digicash e-wallet. After all, there will be offline
> ecash, right?

I think that it is _vital_ to have e-mail and TCP/IP versions, 
don't get me wrong here! I _have_ read the web pages, and I
note that you still have to pop into your e-mail to approve the
purchase. This is an inherent flaw to the protocol, that there 
will be 2-3 user-side software components, instead of 1-2 with
DigiCash:

FV: browsing software, paying software, confirming software
DC: browsing software, full payment software

I'm assuming that over time, the TCP/IP payment methods will be
integrated into browsing software, but FV will always be hampered
by the need to have something separate to handle the back-channel,
since they are religiously opposed to using signatures for 
validation (although you suggest some progress in this area).

> 
> First Virtual's chief advantage is that I can get paid. No fooling
> with clearing, scalability, or anything else-- people can buy my
> products.
> 

You get paid (in ninety days), so great, use it today if you can
get your users to use it. Keep your eyes open for tomorrow. 
You may end up getting actually paid by another method before the
payments you receive today actually settle...