2) A group of us went over the First Virtual stuff in detail last night over fajitas, and were practically rolling on
I'm sorry that it took me so long to reply to this thread. I've been travelling and came back to a backlog of over 3000 messages. (The 100 messages/day reported by the Digicash folks sounds really *pleasant* to me right now -- I'm averaging around 350! :-) ) Excerpts from fv: 2-Dec-94 Re: Brands excluded from di.. db@Tadpole.COM (2508*) the floor with laughter. I'm delighted to hear that you're so easily amused. I hope your merriment wasn't too disruptive to the other diners, who might have drawn the mistaken conclusion that you were either rude, foolish, or both.
Basically they have an attitude of "Crypto is too hard, people won't want to use it." So instead, each transaction consists of an e-mail exchange which is converted ultimately into credit card transactions
Wrong. A First Virtual transaction takes place as a single step via mail, FTP, or WWW. *After* the transaction there is an email exchange to confirm the purchase, and although this exchange works as-is with virtually any mail reader in the world, it can be largely automated by an FV-enhanced mail reader. Ultimately, using such a tool you'll be able click on a single button to confirm ALL of your recent transactions, assuming they're all ones you want to authorize.
The exposure time for the merchant is on the order of _90 days_. All fraud, etc., is on the head of the merchant.
You're right about the 90 days for now; as I have stated many times, this is an inevitable consequence of our extending the credit card merchant system to unknown and untrusted sellers anywhere on the Internet. You can become an FV seller with no credit checks, and indeed with no human intervention, so the 90 days protects us (and by extension the community of legitimate buyers and sellers) against abusive sellers. As I have also stated, however, we are working on a system whereby legitimate sellers can go through a qualification process after which the 90 day holding period will be completely waived. We cannot yet announce a definite availability date for this facility, but it isn't very far away.
The bottom line here is that FV has a system which is much more sluggish than the DigiCash system, even though it doesn't use "hard" crypto.
and the transactions are trivially reversible. This is actually a _design goal_ in their "Soylent Green", er, "Simple Green"
Well, it doesn't use "any" crypto, hard or soft. As to "sluggish" -- I would point out that you can set yourself up with an account in minutes, without human intervention, which contrasts pretty well with some of the experiences reported on this list with other systems. And purchases are instantaneous. What's sluggish? Have you actually tried using our system? It is far from anonymous, This depends on your definition of anonymity. In our system, a buyer and a seller can meet and conduct business without EVER knowing each other's identities unless they choose to reveal them. This is trivial, and indeed it already happens all the time on our Infohaus. However, First Virtual knows the real identities (or, at least, we know the real underlying credit card, from which the real identity can be ultimately traced), and can be forced to provide it to the government under court order. We will otherwise keep all such information completely private. I think this meets most practical standards for anonymity, and it is certainly far more anonymous than most real-world commerce mechanisms such as credit cards, where they buyer & seller names both appear on the charge slip. proposed standard. I'm not sure what you're referring to here, but if you mean that it's possible to refund someone's money, that's certainly true. All our accounts are in principle bidirectional, although people can choose to have buyer-only or seller-only accounts. Just out of curiousity, if I think of a silly name to call someone else's commerce mechanism, will that prove anything of interest?
It is completely inappropriate for hard goods of significant value,
As we have made clear, this was an explicit design decision. Our terms and conditions, which you don't seem to have read, actually FORBID the use of our commerce engine for hard goods. So you really don't need to work too hard to convince us on this point.
and its minimum transaction cost is high enough to rule out its applicability for very small transactions.
Wrong again. We explicitly permit seller-based accumulation, so there's nothing to stop you from building a service that charges, say, a tenth of a penny for each bit of information; however, you have to accumulate the charges on your end until they pass our 30 cent threshhold, that's all. If someone buys less than 30 cents worth of stuff from you, you have to take it as a "free sample" loss.
Even if used for purely informational goods, if an undercapitalized info service becomes popular, it will sink beneath the waves while waiting for payment.
This is amazingly wrong. First of all, consider what it means for an info service to become popular: It means that their server and net connection are more highly utilized. Neither of these is typically a metered resource, which means the incremental costs are zero. There's an incremental cost involved in upgrading either of them, but if your service is so wildly successful that you have this problem, how hard do you think it will be for you to get a bank loan to cover an upgrade to your computing facilities or Internet connection, which are the ONLY incremental costs of this kind of runaway success? It is also worth noting that in the existing credit card system, new merchants who have only recently qualified for Visa/MC merchant status often have a similar holding period imposed upon them by their banks. It's Standard Operating Procedure, that's all. If you're setting up an information service based on our mechanism, the cost of operation for the first 90 days should be factored into your startup expenses, just the way you would have to factor in the cost of inventory for a hard-goods business. (Indeed, for most hard goods businesses, the inventory cost would be higher than 90 days operating expenses.)
As near as I can tell, FV's technology was developed by people who wanted to implement their pet philosophy about Internet commerce (customer should examine info first, then commit to paying, all transactions reversible, cryptography and anonymity are bad, secure transactions are not possible on the net, etc.), rather than anything bordering on an Internet cash-like system.
Wrong again. FV's technology was developed by people who wanted to sell information products on the Internet. That's the ONLY reason we did it. We didn't (and still don't) see any other commerce mechanism that would meet our needs, so we built one. We expect to make our money on information products, not on the commerce engine. We also don't think cryptography and anonymity are bad. If you would just read our materials, you will see that we think that cryptography is problematic and that anonymity is good. We've strived for the maximum possible anonymity without the problems we perceive in using cryptography. (And FYI, we know whereof we speak: we use cryptography heavily internally, and we are extremely aware both of its power and utility AND of the practical difficulties in its use.)
So, I ask, First Virtual is looking better and better for doing _what_? Until they deal with the interface problem (get a decent client, rather than relying exclusively on e-mail), I think they're not even going to be adequate for getting shareware-scale proceeds from putting up a cool Web page.
Please check out our Web pages before you make any more comments like this one. You can buy stuff today from our Infohaus, using Web or FTP access, or email if you prefer, so it's pretty silly to say that we rely exclusively on email. (Actually, the email interface is the LEAST usable.) The people selling things on our Infohaus -- who are NOT associated with FV in any way other than as our customers -- get paid in REAL MONEY. Tell *them* that the system isn't adequate. Or tell it to my in-laws, who are now getting monthly loan repayments (real money) from me via a cron job that I set up on my own machine at home (Setting up such a job requires no special FV intervention -- anyone who knows how to set up a cron job can do it, it's that easy. This stuff really works, check it out!)
FV may be more operational, although I'm curious if any transactions have managed to fully settle yet...
We haven't been up for 90 days yet, so no funds have passed the aging period. I'll suggest to our PR people that they make a big deal about the first settlement to sellers, which should happen in January...
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.
Hey, we agree on something! Different mechanisms for different purposes makes perfect sense. This is why you won't, in general, find us bad-mouthing any of the other systems -- we think there's room for several payment mechanisms on the net, and don't see any purpose being served by "taking the low road". I'm happy to note that the folks behind the other systems seem to be taking a similar approach. I hope we can all keep it up.
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.
Of course it can be done without bundling it into the payment protocol. You've missed a critical point: By "bundling" it into the payment protocol, we have been able to achieve a vast SIMPLIFICATION of the payment protocol. It is not a coincidence that we are the first (and so far, still the only) system that is operational with real money. It's because we set out to implement that subset of commerce that was amenable to rapid deployment. Try-before-you-buy permits a vastly simplified commerce system, but nobody should be surprised if that commerce system is ONLY useful in situations where try-before-you-buy is acceptable!
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:
You've read them, but you don't appear to have understood them, which is probably our fault, not yours. The email confirmation is indeed a bit cumbersome if it gets invoked very often and your mail system isn't FV-smartened. But if you use an FV-smart mail tool -- and note that Z-code recently became the first vendor to publicly announce and demonstrate support for our protocols -- you can get this down to where a single mouse click authorizes a dozen or so purchases. Not a big deal. You could even have an intelligent agent do the authorization for you in some cases, although this requires some real caution!
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).
You can already browse by Web or FTP, so "over time" == "now". Once again, we're not OPPOSED (religiously or otherwise) to using digital signatures, we're just opposed to making electronic commerce wait for the widespread deployment of signature technologies. When such technologies are widely deployed, we'll probably use them (though this is not a promise, it will depend on the situation at the time). Sorry for the length of this message -- I hope it clears up a few misconceptions. -- Nathaniel PS -- Doug, please tell the folks at Tadpole that your mailer is not doing a very good job generating Message-ID headers. In particular, it isn't getting the domain right in the Message-ID, which can be a problem for Message-ID uniqueness. Specifically, instead of <9412021548.AA17294@tadpole> it should really be <9412021548.AA17294@tadpole.com> It's just a nit, but these little details do matter, and if you tell me what mail tool you're using, I might be able to tell you how to fix it. -- NB