Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
I Can't Stop Thinking

By sigwinch in MLP
Tue May 22, 2001 at 05:39:49 PM EST
Tags: Culture (all tags)
Culture

A rant on micropayments delivered as a comic. A weird scrolling flowing beautiful nonlinear comic, the likes of which I've never seen before.


Here are the other I Can't Stop Thinking meta-comics. But don't stop there -- check out the rest of Scott McCloud's stuff. In particular, have a look at Zot! Online.

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
Are you a fanboy/girl?
o No 29%
o Comics 8%
o Anime 5%
o Books 8%
o Movies 5%
o Several of the above 43%

Votes: 37
Results | Other Polls

Related Links
o rant on micropayments
o the other I Can't Stop Thinking
o Scott McCloud's stuff
o Zot! Online
o Also by sigwinch


Display: Sort:
I Can't Stop Thinking | 21 comments (18 topical, 3 editorial, 0 hidden)
Oh Baby! That's Worth a Bookmark! (nt) (2.12 / 8) (#2)
by greyrat on Tue May 22, 2001 at 08:37:43 AM EST


~ ~ ~
Did I actually read the article? No. No I didn't.
"Watch out for me nobbystyles, Gromit!"

Non-Linear Comics (5.00 / 3) (#5)
by Halon50 on Tue May 22, 2001 at 10:13:50 AM EST

Micropayments and the state of the online comic industry are topics that have been bought up in the online comics community from authors ranging from Gabe and Tycho of Penny-Arcade (I apologize, but I couldn't find the specific forum post relating to PA's micropayment system) to Scott Kurtz of PvP Online.

Many web comic sites have turned to offering a micropayment system as an attempt to bypass the old banner advertising network scheme that has proven to be nearly useless. Using micropayments to support your favorite web comics is still a new concept though; we'll see how it works as a support system in the long run.

On the topic of unique static comics (ie not Flash-based like this one) that attempt to break out of the familiar 1-, 3-, or 4-panel formats, When I am King from Demian5 (Warning: PG-13 content) makes an excellent foray into a non-linear presentation format. I've consistently found myself astonished at how the author chose to present a particular concept in one week, only to be surprised again the next week.

-How's that for a first post?

Nonlinear? (4.00 / 2) (#6)
by trhurler on Tue May 22, 2001 at 11:32:14 AM EST

I suppose that in the sense that the panels aren't geometrically aligned, that is nonlinear. I always thought nonlinear in this context was most usefully applied to plots, or presentation thereof; this is just an ordinary "I'm the cartoonist speaking" multipanel lecture dropped onto a Candyland board or something like that. Still, it is interesting in a sort of "I know the technology and business model he's talking about, and he obviously does not" sort of way.

For anyone who's interested in micropayments, presume that in order to be practical, the artist has to get at least half. Now, figure them at a quarter. That's higher than most people are saying, but figure a quarter. Now figure out how many payments you have to get in order for the business to be profitable. Not the artist; he might be ok, but think of the costs of the business. Facilities, equipment, insurance, salaries, benefits, travel(trust me on this one; for a business of any size, it will become important, and without size, this model doesn't work at all,) technology development, and so on. It can be done, maybe, but you're going to have to convince someone to pour probably a minimum of a hundred million dollars into a risky venture nobody really knows will work if you want to get the necessary scale. Good luck. (Seriously - I'd love micropayments. I'm just saying, it isn't as easy as people think. No, a couple of cgis and your dsl line will NOT cut it.)

--
And when you consider that Siggy is second only to trhurler as far as posters whose name at the top of a comment fill me with forboding, that's sayin
Nonlinear micropayments (none / 0) (#7)
by sigwinch on Tue May 22, 2001 at 01:33:33 PM EST

I suppose that in the sense that the panels aren't geometrically aligned, that is nonlinear.
I liked it because it is visually interesting, and it is definitely not the standard I-have-a-T-square-and-there-will-be-boxes approach. The format would also lend itself to parallel plot tracks drawn in, well, parallel. (Hmmm...wonder if you could do a choose-your-own-adventure comic in flowchart format? BOFH would fit that format nicely. ;-)
Now figure out how many payments you have to get in order for the business to be profitable. Not the artist; he might be ok, but think of the costs of the business. Facilities, equipment, insurance, salaries, benefits, travel(trust me on this one; for a business of any size, it will become important, and without size, this model doesn't work at all,) technology development, and so on. It can be done, maybe, but you're going to have to convince someone to pour probably a minimum of a hundred million dollars into a risky venture nobody really knows will work if you want to get the necessary scale.
I think you have to do several things to make it work:
  • Begin with the high-margin high-demand content: porn, weather, sports, comics, anime, etc.
  • Start small but have a plan to grow. Get it working for early adopters (read 'fanatics'). When you can afford it, improve uptime with fancy machines and geographical redundancy.
  • Write RFCs for the protocols between the browser, content server, and clearninghouse. (Are there any existing protocol specs?)
  • Develop a simple clearinghouse implementation. Needs interfaces to credit cards and checks, account management, transaction management. Credit card processing can initially be outsourced to, e.g., PayPal. Initial implementation should do absolute bare minimum to work. It conceptually resembles an online banking system, except that there are only a few types of simple transactions (banks have *tons* of transaction types, and we won't even think about stock brokers).
  • An occasional lost transaction is OK, as long as it's random. E.g., the ten transactions in progress during a disk crash. As long as you don't create or destroy money, you can just ignore the occassional mistake.
  • Create and distribute browser plugin for the few most popular browsers.
  • Copyright management data structures would be nice. DTDs would explicitly be for grants of minimum permission rather than maximum limits, so the DMCA doesn't apply. In the long run, this is critical, because people will purchase *gigabytes* of content, some of which is freely redistributable, some of which is tightly licensed, and some of which is in between. An average person could easily buy 3000 works/year, and without some sort of built-in categorization it will be a nightmare which hurts both creators and customers.

$100M is rather high, because you don't have to start with a full-blown commercial system that is ready to instantly scale to 500 million transactions/day. You *can* start with a small box on DSL or a turnkey colo box, and grow it as interest increases. It would be the micropayment equivalent of the Mosaic/NCSA httpd pair. The important thing, I think, is to have clearly written RFCs for every micropayment-specific protocol and data structure, a carefully developed security model, and actual running reference implementations. Once you have those, third parties can contribute improvements in small batches. Unless you have a spare $100M+ laying around, you have no choice. Besides which, a massive Apollo-style program would end in integration hell, as likely as not.

--
I don't want the world, I just want your half.
[ Parent ]

But (4.00 / 1) (#8)
by trhurler on Tue May 22, 2001 at 01:39:53 PM EST

I think you missed my point. You can't start small unless you have tons of money to lose. This kind of venture will not provide enough income to sustain operations until you're huge and can afford to amortize the fixed costs across a greater pool of revenue and a greater amount of time(the latter of which is a matter of cash flow.) Yes, you can operate something like that small, but between the fact that it will be much harder to sign up content providers of any quality and the fact that you will lose money until you grow, the sensible approach is to start big, but have the technology fully ready to roll before you officially open for business.

This makes further sense in light of the fact that micropayments are going to be a land grab market; if you don't get big fast, and you're successful, then someone else will get big fast, or else a big player will move in on your market, and you will be driven out of it. Size does matter in the financial world.

--
And when you consider that Siggy is second only to trhurler as far as posters whose name at the top of a comment fill me with forboding, that's sayin
[ Parent ]
Starting small (none / 0) (#9)
by sigwinch on Tue May 22, 2001 at 02:52:59 PM EST

You can't start small unless you have tons of money to lose.
I don't think money is what's stopping micropayments. The cash pissed away on boo.com could have gang-banged a micropayment system into existence. It's not lack of recognition either. The web pundits and content creators have been bitching and moaning about the lack of payments for years.

What's stopping micropayments is lack of architecture. If you want to do email, you can download MTAs and MUAs for free, or buy them, or look up the RFCs and build your own. The design, implementation, and operation of mail systems are well documented and understood. If you want to do web surfing, you can download browsers and servers for free, or buy them, or look up the RFCs and build your own. Again, there are countless books detailing every step of the process. Thousands of developers are familiar with the software and concepts.

But if you want to do micropayments, well, you're shit outta luck. There are no standards for the protocols and data structures needed. There are no working systems that you can point to and say "See, it would fit into our business model like so." There are few people familiar with the concepts.

This kind of venture will not provide enough income to sustain operations until you're huge and can afford to amortize the fixed costs across a greater pool of revenue and a greater amount of time(the latter of which is a matter of cash flow.)
So? For most web engineers and artists, it's already a totally losing proposition. They spend dozens, if not hundreds of hours of their time, and hundreds of dollars of their money, and they are guaranteed to have no possible return. From their point of view, spending a little more effort to help design and implement a micropayment system could seem reasonable.
...the fact that you will lose money until you grow, the sensible approach is to start big, but have the technology fully ready to roll before you officially open for business.
Obviously. Just like nobody started work on the Apache webserver until they had the project fully funded, and they didn't go live until it passed the final system integration milestone. Just like the Linux kernel. Just like Perl. Or CPAN. Oh, wait....
This makes further sense in light of the fact that micropayments are going to be a land grab market; if you don't get big fast, and you're successful, then someone else will get big fast, or else a big player will move in on your market, and you will be driven out of it.
The web doesn't exist because somebody ran the numbers, predicted a break-even market size, and then rolled out a web with more servers and browsers than the break-even point. It exists because the prophet Tim Berners-Lee had a vision about certain nifty possibilities, wrote the protocols and proof-of-concept implementations, and inspired Mosaic and NCSA httpd.

As far as the pioneers being pushed out of the market by the big financial institutions, *that's the whole point*: to commoditize micropayments, to make them effective and ubiquitous. If the pioneers can get rich, fine; if not, it'll still be a huge benefit to all web readers and artists. I just don't think the banks will have the insight or inspiration to do micropayments without a working toy system they can play with.

--
I don't want the world, I just want your half.
[ Parent ]

Micropayments are not a web server (3.00 / 1) (#10)
by trhurler on Tue May 22, 2001 at 03:19:18 PM EST

You're missing the whole point of what I'm saying: micropayments are NOT just a technology. Yes, I alone, all by my lonesome, could write the necessary software and start up a micropayment service, with the services of a CPA and one or two other people. However, nobody would follow my lead, and I lack the backing to go anywhere with it; if anyone else wanted into the business, he'd develop his own software, to his own specs - even if I'd provided publicly available standards info and so on of high quality. This is not the web, and micropayment software is not a web server. It is more akin to banking software, which is one of the most closed-source old-money endeavors in computing, and will remain so for the forseeable future.

You're right that banks aren't going to do this; if anyone does, it will be someone like Yahoo, Amazon, or Microsoft. If anyone else tries, he'll just get muscled or bought out by one of them very shortly thereafter. Don't think that some visionary is going to step up to the plate and say "here it is, folks, and it works!" and then have his work adopted as the standard; in the realm of things pertaining to money, it doesn't work that way.

--
And when you consider that Siggy is second only to trhurler as far as posters whose name at the top of a comment fill me with forboding, that's sayin
[ Parent ]
Re: not a web server (none / 0) (#11)
by sigwinch on Tue May 22, 2001 at 05:32:12 PM EST

Yes, I alone, all by my lonesome, could write the necessary software and start up a micropayment service, with the services of a CPA and one or two other people.
Not just you all by yourself, but also people who see micropayments as a strategic value, and people who have nothing to lose by helping.
However, nobody would follow my lead, and I lack the backing to go anywhere with it;
Make the system fairly cheap and low-financial-risk to try out, and then sign up the top 20 porn sites. Porn is the killer app for micropayments: Customers want small semi-anonymous payments, they don't want to risk their credit card account, and site operators want cash payments (to avoid costly charge backs).

Then are other markets, like comics and newspapers, that are too cheap for credit cards. If you can make it very low risk to sign up, they'll sign up in droves because it's their only hope to make money.

So how do you make it low risk? Two ways. First, you can make software suites that allow micropayments to be bolted onto standard web server systems. If the site is dynamic already, and the suites are well written, there will be very little risk to joining. Second, for more static content, you add micropayment support to a standard colo setup; the content creator uploads the static (or simple dynamic) content, and you manage making the micropayments work. Kind of a big Geocities-with-micropayments, but professionally managed.

Oh, and one more thing: you must have good downloadable browser plug-ins, a la Flash and Acrobat Reader. The customers have to be able to start using micropayments with little hassle.

if anyone else wanted into the business, he'd develop his own software, to his own specs - even if I'd provided publicly available standards info and so on of high quality.
Money is only valuable to the extent that it can be widely spent; banks only have value to the extent that they serve as conduits for capital. Making money proprietary is about as useful as only accepting deposits in the form of platinum: customers will flee to places where their money is useful. You might as well be advocating Flooz for micropayments.
This is not the web, and micropayment software is not a web server.
Nor is microsoft.com just IIS. The heart and soul of microsoft.com are the custom value-added data and scripts. However, without an open-standards-conforming IIS, the whole exercise would be pointless. The open standards are just the vehicle: you can still have a highly valuable proprietary component that beats your competitors into the ground. For micropayments, this means an easy-to-use account manager. Good account managers are incredibly valuable and can really set a company apart from its competitors.

Micropayment clearinghouses can also distinguish themselves by mastery of conventional financial accounts. A clearinghouse that funds accounts only through credit cards, and makes payments only through mailed checks is boring. One that can accept checks, directly debit checking accounts, and directly credit checking accounts is a winner. One that can accept precious metals from E-Gold accounts would attract libertarians. One that can exchange currencies will garner international traffic. Clearinghouses that don't partner with, or sell out to, banks will eventually be at a distinct disadvantage.

It is more akin to banking software, which is one of the most closed-source old-money endeavors in computing, and will remain so for the forseeable future.
But the interfaces are dead standard. Everybody uses dollars or a few other well-defined currencies. All checks in the U.S. use the same system of fractional routing codes, with the same system of machine-readable numbers. All credit card account numbers have the same basic form, and all credit card systems are interworkable with, perhaps, a little glue.

As to the closed-sourcedness, that isn't because they are tightly guarded secrets. That's because qualifying and certifying somebody else's code for your banking application is more expensive than adapting and requalifying your own code.

If anyone else tries, he'll just get muscled or bought out by one of them very shortly thereafter.
Just like the NYSE muscled out Chicage, Tokyo, London, E*TRADE, Ameritrade, and all the independent exchanges. Oh, wait...
Don't think that some visionary is going to step up to the plate and say "here it is, folks, and it works!" and then have his work adopted as the standard; in the realm of things pertaining to money, it doesn't work that way.
Micropayments are an exercise in large systems design, and that takes a small team of people who care about making it happen. Period. No consortium of financiers has the imagination or skill to pull it off; it was all those hosers could do to keep from killing themselves with Y2K. I don't even think a single financial company could do it: they are notorious for lack of imagination. (They only used smart cards in Europe because the gov't telcos were even less imaginative and couldn't even supply phone service for credit verification.) Maybe an Internet-aware company could do it, but it would be because someone high up in the company was a visionary. But it would have to be a company with large systems experience. Sun, for instance. They seem to be able to make things proprietary enough to ride the wave, but not so closed that the wave dries up.

Hmmm..."The network is the bank". Has a nice ring. ;-)

--
I don't want the world, I just want your half.
[ Parent ]

Heh... (3.00 / 1) (#12)
by trhurler on Tue May 22, 2001 at 06:05:02 PM EST

Make the system fairly cheap and low-financial-risk to try out
And then go out of business. Yeah, there were a lot of dot-coms that went under that way. I'm not going to be one of them, thank you very much.
and then sign up the top 20 porn sites
Which is nice if they'll cooperate. The fact that it is a good idea does not mean they'll do it.
The customers have to be able to start using micropayments with little hassle.
Yes, and it has to be secure. That's going to be interesting, seeing as, to put it mildly, it is not secure and cannot be made so. In addition, if you're not exposing credit card numbers, then YOUR business is subject to chargebacks - which means you need sizable cash flow right away.
Money is only valuable to the extent that it can be widely spent;
Contrast this statement with your claim that a micropayment business can start out small.
But the interfaces are dead standard.
Money is; banking software is not. Then again, even money isn't after you get into all the different forms it can take other than cash... you're going to need quite an organization to handle them all.

--
And when you consider that Siggy is second only to trhurler as far as posters whose name at the top of a comment fill me with forboding, that's sayin
[ Parent ]
One last reply (none / 0) (#13)
by sigwinch on Tue May 22, 2001 at 06:58:49 PM EST

Before I go any farther, let me state that I'm looking at this from the point of view of "I want to see micropayments. What can I do?" I'm not a bank, I don't have a massive customer base that I can strong arm, and I don't have to money to gang-bang together a system and go live in one might flash of glory. If I'm to contribute to anything, it has to be simple and low-risk.
Make the system fairly cheap and low-financial-risk to try out
And then go out of business. Yeah, there were a lot of dot-coms that went under that way. I'm not going to be one of them, thank you very much.
I didn't say anything about giving it away below cost and hoping to make up the losses in volume. I was referring to making it easy to use from an integration point of view. E.g., if you marry your web server backend to IIS/ASP, you'll scare away people using Apache/PHP. On the other hand, if the heart of the backend is a server/language agnostic micropayment kernel that can be easily glued to anything, site operators won't be afraid to try it out.
and then sign up the top 20 porn sites
Which is nice if they'll cooperate. The fact that it is a good idea does not mean they'll do it.
True, but the ones that do will be more attractive to customers (at least if the roll out is promoted effectively).
Yes, and it has to be secure. That's going to be interesting, seeing as, to put it mildly, it is not secure and cannot be made so.
It would use SSL and be as secure as existing sites that accept credit cards. Hell, it would *be* an ordinary web site that takes credit cards.
In addition, if you're not exposing credit card numbers, then YOUR business is subject to chargebacks - which means you need sizable cash flow right away.
No kidding! I can't think of any clean way to solve this problem, especially when you're still small. One approach would be to classify funds in an account by source: unsecured (credit card less than 90 days from deposit), partially secured (personal check less than 45 days from deposit), direct debit, cashier's check, cash. Funds would be spent from the lowest-risk category first. Above a chosen risk level, the merchant would have to either accept the risk or you would refuse the transaction.
Money is only valuable to the extent that it can be widely spent;
Contrast this statement with your claim that a micropayment business can start out small.
Starting small is just plain hard, proprietary or not. However, I was thinking more about a successful large-scale system. The proprietary system is a "walled garden" containing the collection of content providers chosen by the clearinghouse, and controllable by the clearinghouse. If that clearinghouse ends up being something like Disney or the Church of Scientology, we'd be in deep doo doo. Even if the clearinghouse is benevolent, it's still a restricted system with no competition.
But the interfaces are dead standard.
Money is; banking software is not.
Do you have any examples where an individual customer would have to change what they do to interact with one bank versus another? Or where a bank would have to change how it works between other banks? Checks, wire transfers, borrowing from each other and the central banks, trading of mortgages and other negotiable debts, Treasury bills, yadda yadda yadda -- all as standard as the day is long. (And if not, the banks are paying extra for manual data conversions and they know it.)

--
I don't want the world, I just want your half.
[ Parent ]

Almost... (5.00 / 1) (#19)
by trhurler on Wed May 23, 2001 at 11:32:41 AM EST

It would use SSL and be as secure as existing sites that accept credit cards. Hell, it would *be* an ordinary web site that takes credit cards.
The first sentence is true. The second is not. A micropayment machine would be an ideal and most highly prized target. If you got into it, you could do all sorts of things that would be very hard to spot and very, very profitable. The reason most commerce sites aren't hacked daily is that they're not worth enough to attract the kind of people who have both the skills and the lack of ethics; those people are busy ripping off banks and so on. Your micropayment site would draw their attention. That's fine, if you have a secure system, but no matter how well you write your code, you still have to run a web server, a database, an operating system or three, your code has to link against libraries you didn't write, and so on. This problem is not solvable in the general case today; the closest you can come is to wall off everything but the web server, SSL everything, and run OpenBSD all ever the place. You'd have to put the production system on its own subnet, prevent any and all remote access, including from your internal network, except to that web server, and you'd have to have faith in your firewalls, which is to say, you already lose.

Security is a disaster in the current environment.

--
And when you consider that Siggy is second only to trhurler as far as posters whose name at the top of a comment fill me with forboding, that's sayin
[ Parent ]
Good points about security (none / 0) (#20)
by sigwinch on Thu May 24, 2001 at 05:06:06 AM EST

There are several things that need to be secured:

1. Buyer must trust origin of content. Therefore, the system must provide for offline signing of content with 'trusted' keys (e.g., Verisign certificates). Furthermore, for semi-dynamic content like a newspaper, where a static article is wrapped with dynamic borders, it must be possible to sign part of the page. This lets the buyer verify after-the-fact that they weren't defrauded, which reduces fraud from a compromised web server to a single loss per customer.

For offline signing, I envision this process: put floppy disk of HTML into signing machine, push button, wait while signatures get written to disk, move disk to other machine, and ftp documents and signatures to production server. This would all be automated so it would take minimal effort or thought.

2. Buyer must trust seller's clearinghouse account number. Therefore, seller must sign (offline) account number with 'trusted' key. Even with a compromised web server, payments will never go to a rogue account. Seller reputation could still be tarnished, but there would be no direct financial incentive to compromise server (although there would be the indirect financial incentive of harming a competitor).

3. Seller's web server must only be able to check the clearinghouse account. This means that a compromised web server cannot defraud the seller. In fact, it should only be limited to a short list of recent transactions, to limit the intelligence available to an attacker. This feature would be dead simple for PayPal to add. (In fact, they will add it to support small businesses where low-level clerks can check transaction completion, but only high-level management can debit account.)

4. Buyer's account and client must have limits and warnings for unusual payments. This mitigates losses from compromised client software. Buyer's client must be very careful managing and timing-out passwords. I see the client side -- an endless sea of poorly maintained Windows 98 boxen -- as the weak point.

5. Long term, it would be nice if the buyer had a trusted client, a small PDA-like device that plugged into a USB port and acted as arbiter for transactions. Most of the time it would run in automatic mode, but if it detected excessive transactions it would lock out further transactions and start beeping for attention. It would need its own small display and keyboard. Smart cards are worthless for this application, as you need a trusted user interface. (This product isn't viable to sell now, but will be in a few years when the insecurity-market size curve reaches the massive consumer loss region. When you see the first major congressional committee on Internet fraud, it'll be time to start selling these.)

Incidentally, all this is a pretty good financial argument for open protocols, since the greatest long-term risk in micropayments is information seurity, and the greatest risk to information security is closed algorithms. Unless you are willing to spend a few hundred man years on security before going live, a proprietary protocol is a guaranteed long-term loser. A closed system means bleeding money while the committees cogitate; an open system means that security companies will fight tooth and nail to proactively reduce risk. Openness transforms security from an in-house cost center to an third-party profit center, which generally produces the best product.

(I've got to stop writing so much.)

--
I don't want the world, I just want your half.
[ Parent ]

Offline signing, the newbie problem (none / 0) (#21)
by trhurler on Thu May 24, 2001 at 08:57:17 PM EST

This is a false sense of security unless you also post bonded security guards around your building, harden the building in various ways, and so on.

In addition, you still have not fixed a different class of problem: if I can get into your web server, I can modify it such that while existing customers may be served properly, all new customers take it on the chin from yours truly. This is even more subtle, because your experienced users, who might know enough to complain, will not be affected, whereas your newbies, who by and large are going to be helpless without phone support anyway, will be the ones getting ripped off. If the fraud is subtle enough, only people who religiously record transactions they enter into and then keep their own records of their spending, and check these against monthly statements and so on would ever have any hope of catching me, and who is really going to keep a ledger of how many micropayments he made? The whole point is convenience!

You can make the latter attack harder using Verisign, but that just gives me another target; Verisign is probably well defended, but so are banks, and they get ripped off all the time. Banking execs speaking off the record often freely admit that they lose hundreds of millions a year(as an industry worldwide, not each,) to thefts that they choose not to do anything about because the publicity involved would harm them more than the loss of the cash.

Bottom line is, unless and until we have better baseline infrastructure from hardware all the way up, this sort of business is at least as risky as paper money, and the ability to detect loss is less with micropayments than if you steal my wallet. It may be that the market will decide that doesn't matter, but pretending it isn't true is a Bad Idea[tm].

--
"Ideas are more powerful than guns. We would not let our enemies have guns, so why should we let them have ideas?" -- Josef Stalin

[ Parent ]
Why it won't work (4.00 / 1) (#16)
by Skippy on Tue May 22, 2001 at 08:46:16 PM EST

There are significan barriers to entry. The one's I'm thinking of are related to the one's pointed out by trhurler but aren't quite the same.

Number one by far is that micropayments give the power to the consumer which is NOT where UltraHugeMegaCorp (hereafter UHMC) wants it. If you have micropayments, then suddenly you don't need the whole CD. You don't have to pay for the content that isn't good. Which is why you won't see any big company do this. Since, as trhurler pointed out, they are the only people with pockets deep enough to make it long enough to for micropayments to work, it ain't gonna happen.

Reason number 2 is that people won't stick together long enough in EITHER purchasing or producing to make a dent in UHMC's bank account which is the ONLY way that they're gonna notice and do micropayments.

Lets take our intrepid comic book artist, for example. UHMC comes to him and says, "We'll pay you $x right now and you can feed that family of four." When his alternative is to work at McDonalds while he waits for someone to develop a micropayment system, starve while he waits for his audience to develop, starve while sites (maybe his) go under because people aren't used to end-to-end payments and don't pay, and finally start to make a living then it isn't much of a choice.

Multiply that by 100 artists. Now all the artists work for UHMC because they wanted paid NOW. This means that there aren't any artists NOT working for UHMC so there isn't any competition. If someone good does show up then there isn't anyone for them to stand together with against UHMC so they'll fold and buy in as well.

Consumers, by and large, are sheep. How many towns have closed all their shops because everyone shops at Wal-Mart _EVEN THOUGH THEY ALL KNOW IT WILL KILL THEIR TOWNS ECONOMY_? ALL OF THEM! Even the Mom and Pop who own the "Mom & Pop Hardware Co." Consumers sure as hell aren't organized enough to demand anything from UHMC and make them pay attention.

A scheme such as you are proposing won't work until people are so fed up that they ARE willing to stick together. But, the way things are going, by that time it will be illegal to buy content from anyone but UHMC.

You can hack a micropayment standard all you want, but until the day you pull off the biggest social hack in the history of the human race, it just won't work. Sorry (and I mean that).

# I am now finished talking out my ass about things that I am not qualified to discuss. #
[ Parent ]

Why it will work (5.00 / 1) (#18)
by sigwinch on Wed May 23, 2001 at 01:37:21 AM EST

Number one by far is that micropayments give the power to the consumer which is NOT where UltraHugeMegaCorp (hereafter UHMC) wants it.
UHMC also wants only new product being sold, and they only want it sold through their authorized distribution channels. Tough fucking shit for them. eBay will supervise about $10B of transactions this year. The gross annual product of the state of Montana is $20B. That's right, by selling crap on eBay, people earned half as much as the entire state of Montana. Internet commerce doesn't live or die by the mud and wattle (or brick and mortar, if you prefer ;-) companies. It just needs a disintermediating agent with a nice user interface.

Six years ago, eBay did not exist. Six years ago, person-to-person trade over the Internet was a few people advertising things on classified ads and newsgroups. Six years before that, there was essentially no Internet as far as the average person was concerned.

If you have micropayments, then suddenly you don't need the whole CD. You don't have to pay for the content that isn't good. Which is why you won't see any big company do this.
No big content company, that is. Credit card companies, though, don't care if you only buy a single song for $1, as long as they handle the transaction.
Reason number 2 is that people won't stick together long enough in EITHER purchasing or producing to make a dent in UHMC's bank account which is the ONLY way that they're gonna notice and do micropayments.
This isn't a military coup. It isn't the Crimson Permanent Assurance of Monty Python fame, setting out to gut the fat, bloated multinationals by force majeure. It's a new mode of commerce enabled by the ubiquitousness of the Internet. It's the disintermediation of the soiled paper pulp market. Unless UHMC is willing to play very, very dirty, their only choices are to adapt or perish.
Lets take our intrepid comic book artist, for example. UHMC comes to him and says, "We'll pay you $x right now and you can feed that family of four."
Few artists create because a corporation came along and offered them a job, and hell, it's good pay and no heavy lifting. They work hard, often for years, in obscurity. They work for the love of the craft, the hope of becoming good, the hope of making it big.

I've been around the Internet, and the BBSes before it, and everywhere I look I see people striving to write and draw and create cool, clever things for their own sake. Sure, the big companies can channel the drive, and make it profitable, but people do not create because of the corporation.

When his alternative is to work at McDonalds while he waits for someone to develop a micropayment system, starve while he waits for his audience to develop, starve while sites (maybe his) go under because people aren't used to end-to-end payments and don't pay, and finally start to make a living then it isn't much of a choice.
This is a false dichotomy. Few artists suddenly achieve roaring success and quit their day jobs, big corporations or not. For fiction writers especially, I don't see why the Internet will be any more demanding or fickle than editors with chronically limited budgets.
You can hack a micropayment standard all you want, but until the day you pull off the biggest social hack in the history of the human race, it just won't work.
It's very easy to pontificate about what people will and will not like, but the realities tend to be surprising. Conventional wisdom said that people would not buy use items from unknown sellers across the Internet. It would simply be too risky. But they will: remember the eBay $10B/year figure.

You assume that artists won't create unless cash is paid in advance. They will -- for fiction writers at least, pure speculative writing is common. You assume people won't want to install custom browser software. Flash and Acrobat Reader demonstrate that they will. You assume that people won't fund accounts with clearinghouses. PayPal has 8 million registered users and is the largest payment service for eBay's $10B/year traffic. You assume that no one can build the necessary web server enhancements to support micropayments. Similar commerce systems are built all the time. You assume that web hosting providers won't build custom commerce systems. They are a dime a dozen.

Micropayments are nothing more than eBay for information. The only difference is one of degree: information has a very low marginal cost of production compared to Beanie Babies, so there is no scarcity, and limited volume auctions are unneeded. Everything else is the same. The micropayment web server plays the part of the seller, checking the PayPal account and not sending files until payment is received. The micropayment client is just a proxy to automate the buyer's interaction with PayPal. The ISPs act just like the delivery service, charging a small fee for transport.

Hell, a Perl wizard and an ActiveX wizard could hack together a working prototype using PayPal's existing text-based interface in a few weeks. Jamming the correct things into PayPal over HTTP would be amazingly ugly and prone to breakage, but it *would work*.

The software necessary to pull this off is fairly minor. Off-the-cuff, I'd say that developing the micropayment browser plug-in and server component would take about 10 man-years of effort. Say, $4M if you hire someone develop it. Of course, none of the software is exotic at all and, with good leadership, would make an excellent open source project. It would require a modicum of coooperation from the payment service (they just have to provide a stable interface that isn't gratuitously changed once a week), and they have a strong financial incentive to cooperate.

--
I don't want the world, I just want your half.
[ Parent ]

Two micropayment systems already in place (5.00 / 1) (#14)
by Halon50 on Tue May 22, 2001 at 08:37:26 PM EST

That's right, there are already two companies "sponsoring" micropayment systems, both which are in wide use by the online comic community.

The first, albeit least effective system is through the Amazon Honor System. They charge a flat 15-cent fee per-transaction for use of their system, plus 15% of everything anyone sends you. Ouch.

The second, less expensive system is through use of Paypal. Paypal charges 30 cents per-transaction, plus an additional 2.2% of any amount received over $15. The only catch is that both the sender and receiver has to have accounts at Paypal to make it work.

Both systems are far easier to implement than trying to set up your own web server and credit card authorization system--both companies already have the full monty to take care of all the dirty work for you.

[ Parent ]
Oops (3.00 / 1) (#15)
by Halon50 on Tue May 22, 2001 at 08:41:04 PM EST

I wish I could edit my own posts. Anyways the point I forgot to include was that both systems are just about useless for people who wish to charge (or send) amounts less than 50 cents or so. Of course, with today's economy equating one USD to a 1950's penny (I'm exaggerating), a minimum amount of a dollar should be expected in a micropayment system.

[ Parent ]
They are nonlinear (5.00 / 1) (#17)
by vectro on Tue May 22, 2001 at 10:36:10 PM EST

Look at Week 10 of zot for an example of a truly "nonlinear" comic.

But even when everything is happening linearly in time, I think that Scott makes a good point that the "candyland" model allows for more information - for example, the passage of time can be implied by the amount of spacing between panels.

“The problem with that definition is just that it's bullshit.” -- localroger
[ Parent ]

I Can't Stop Thinking | 21 comments (18 topical, 3 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!