Link: Slashdot "Why won't you pay?"""

Micropayments, Macropayments, Subscriptions, etc.

Moderator: Moderators

Locked
User avatar
Greg Stephens
Forum Founder
Posts: 3862
Joined: Sat Apr 14, 2001 7:00 pm
Location: Los Angeles, California, USA
Contact:

Post by Greg Stephens »

Good morning! That's a nice tnetennba.
lylebclarke
Frequent Poster
Posts: 53
Joined: Sun Apr 15, 2001 7:00 pm
Location: New Zealand and Denmark
Contact:

Post by lylebclarke »

Setting the threshold to five yields some good stuff both for and against.
Guest

Post by Guest »

Since the micropayments revisited thread is focusing in on the various alternatives and is mostly positive, I'm going to put this negative post here alongside the slashdot pros and cons, although technically the slashdot thread is about paying for content period, not just micropayments:
<p>An <a href="http://world.std.com/~buzzard/upay.html">essay</a> on the problems with achieving a workable micropayment system that I've thought of or heard from others, written in response to ICST 6...
<p><a href="mailto:buzzard@world.std.com">Sean Barrett</a>
John2two
Regular Poster
Posts: 22
Joined: Sun Apr 15, 2001 7:00 pm
Location: Monroe, Oregon, USA
Contact:

Post by John2two »

Thank you, Sean. That is the best, most clearly thought-through, most clearly presented case against the likelihood of a micropayment infrastructure coming into being that I've ever read.

You have clearly laid out the challenges, and I agree that they do appear very daunting. I'm not ready to toss in the towel yet, but we need your voice in the mix.

John
User avatar
Greg Stephens
Forum Founder
Posts: 3862
Joined: Sat Apr 14, 2001 7:00 pm
Location: Los Angeles, California, USA
Contact:

Post by Greg Stephens »

That is an excellent essay. I think the only point that I want to raise is with item #7 (upay requires site authors become businsses): I don't think this requirement is unique to micropayments specifically or to paid online content in general. Rather it is always going to be an issue whenever somebody decides to stop doing something merely as a hobby and take it up full-time. This is not only true of artists (actors, musicians, dancers, etc.) but of any person that is sufficiently motivated to strike out on their own and be their own boss. This is certainly a something that any individual who is going to implement an online payment system needs to consider, but I would think this is somthing that is inherent to capitalistic society rather than online finance.

Perhaps upay is what will separate the amateur from the professional? The hobbyist solicits donations for content, the professional requires a payment.
Good morning! That's a nice tnetennba.
cjstone
Forum Member
Posts: 9
Joined: Wed Jul 11, 2001 7:00 pm
Location: CJ Stone
Contact:

Post by cjstone »

I have a reply to Sean's deal--well done, BTW--but it's getting larger and larger. I'm still wet behind the ears here, so give me an idea of how long is too long. He's called up a lot of talking points, and I'm answering them all, the gods help me.

cjs
User avatar
Greg Stephens
Forum Founder
Posts: 3862
Joined: Sat Apr 14, 2001 7:00 pm
Location: Los Angeles, California, USA
Contact:

Post by Greg Stephens »

so give me an idea of how long is too long.
As much or as little as you can manage!
Good morning! That's a nice tnetennba.
cjstone
Forum Member
Posts: 9
Joined: Wed Jul 11, 2001 7:00 pm
Location: CJ Stone
Contact:

Post by cjstone »

First, I prefer the abbreviation mupay to upay for several reasons. One, we can make a zen joke on the koan "What is mu?" Koans are supposed to defeat all logical thinking, which talking about micropayments seems to do. Two, we can say moopay for everyone who is either bullish on or bullheaded about micropayments. Three, people who whine or winge either for or against can be talking about mewlpay.

Second, I want to frame my response in terms of a closed, peer-to-peer micropayments system.

1. Users don't want to pay for content
The largest mistake Sean is making--and everyone seems to make this mistake, even me--is binary thinking. Everyone will pay, or everyone won't. All content will be metered, or no content will be metered. There will be many middlemen, or there will be no middlemen. People must know all about the content, or they will know nothing of the content. People will be able to get exactly the content they want, or they won't be able to tell their holes from a butt on the ground (content-wise, that is).

Well, it's probably true that some people will pay, and some won't (for whatever reason--too cheap, too broke, too dogmatic, etc.). Some content will be metered, and some won't. Some authors (authors = content providers of all kinds) will hondo the tech end and not need a middleman, and some can only draw the cartoons and cash the checks. Some authors will provide good summaries and previews of their work, and some won't. And so on. People, products, and prices are going to land on a spectrum between all and nothing.

The ideal in this is a closed peer-to-peer (P2P or p2p) micropayment system. Closed is good because it prevents freeloading, enhances transfer speed, and secures payment token validation and rectification. P2P mupay is good because everyone who comes to a p2p mupay is a peer--no matter how large or small, incorporated or not, international or parochial--each entity enters as a peer and remains a peer.

Thus SMcC, who makes *ICST* every so often is on the same footing with the New York *Times* and their database of several hundred thousand documents. Multinational MegaMusic approaches a p2p mupay system at the same level as Jim's Big Ego. In some cases, depending on contracts and the like, a big company like NY *Times* might buy an article from a freelancer; publish it for mupay in their daily rag; and then discover the listing of the article has driven consumers to the freelancer, who has the original, uncut article available for mupay, too. Given that there must be some kind of a search function, peers appear to be one size and report on the content they offer.

Now note: being part of this p2p mupay net DOES NOT prevent anyone from selling their content another way, for example, NY *Times* selling a complete whatever via QPass. To suggest otherwise is to fall into the binary trap again.

Note also that it's possible for authors (and we're even thinking of big companies as authors now) to belong to multiple mupay nets, provided the cost of joining and overhead is minimal. In the distant future, when humans have tamed the atom and hyperdrive has flung them to the stars (the humans, not the atoms), then it would be possible to negotiate common exchange between mupay systems, much like Canadian merchants along the border accepting USF in their cash registers with just the push of a USF button.

2. Users don't want to deal with upay decision-making

But the system he advocates--each peer setting a threshold micropayment--is the solution for this. Combined with a "gas gauge" to tell you how much you have left in total, the solution is virtually ideal.

Of course, the micropayment has to be sufficiently small. As Jakob Nielsen has pointed out, electricity is so cheap (even though constantly metered) that the price only serves to make sure we turn off the lights when we go to bed. So mupay costs have to be as non-intrusive as the cost to have a light bulb on.

3. If users pay for content, they want to keep that content...If you buy a book, a videotape, (or])a CD, you can (until they) fall apart. You can even sell them later.

But users can only sell those items *once*. This is actually a author issue, and should read, "If authors sell content, only the authors sell content." In the examples above, the content is limited and carried by the form (and a judge just ruled on this for ebooks); therefore, users would basically have to give up the right of duplication except for "fair use."

4. Getting upay into browsers is hard

It's the mupay software that's tracking what's available, what people think of it, how much it costs, and how much money you have, and that's not necessarily a browser. It would be good if the mupay software was friendly with a browser, but once you are connected to the P2P mupay net via its software, it's not required.

5. Critical mass chicken & egg problem

Critical mass not a problem as being part of the net doesn't preclude not being part of the net. In fact, while it would be possible to have a proprietary search scheme, XML is probably best, since descriptions from inside the mupay net could be transported outside the mupay net as bait that would encourage people to join the net.

6. Technological improvements could remove the success tax before upay happens.

A closed mupay net that uses swarming technology (chops the content into bits that can be stored in multiple locations and retrieved from muliple locations so downloading isn't interrupted) doesn't have to confront increased dowloads at the ISP.

NOTE: for swarming to work, the mupay net must be closed, the peers must share resources such as disk space, and the size of the chops must be small enough so as to be "invisible" (not larger than 64K).

7. upay requires site authors become a business

Greg answered this handily--when you go pro, you have to do some other stuff. Business is one of them. But a closed mupay net must very accurately track all token exchanges, so I'm not sure which part of doing business we're talking about: marketing, accounting, taxes, regular delivery of product, etc.

8. upay introduces middlemen
9. Middlemen could get monopolies


In a closed P2P mupay net, the only middlemen are other peers, and swarming prevents any one peer from becoming a monopoly. The only possible monopoly is at the bank, which validates and pays all tokens. By law, any member of the net must be able to cash out at any time, so there's a limit to the bank's control in that sense; however, it would be possible for the bank to become "the company store", charging special fees until peers are bled dry ("state tax, city tax, gas tax, brass tax, carpet tax...").

This is a matter for contractual control and would be a sore spot in any type of payment net, macro or micro. In fact, this is a common problem with royalties at book publishers--if your aggregate royalties are below a certain amount, usually $100, they don't have to pay them to you. You'd have to read your entry agreement carefully.

OK, so the kinds of things I'm talking about are pipedreams, yes? No. Check out MojoNation; check out SwarmCast from OpenCola; and check out Morpheus, the heir-apparent to Napster. (Look at Javien if you wish, but they have it backwards, so I don't think they're going anywhere.) MojoNation most closely follows my ideal of a closed P2P mupay net, and the difference between them and the real thing is a matter of will.

--sorry if I went on a bit; sorry if I used the Bbcode wrong; and I'm sorry about all that throat cancer (I was on a roll).

cjs
Guest

Post by Guest »

This is Sean again, sorry I don't have an account, but I drew the line about getting more usernames and passwords a year or two ago. (I use three different machines frequently, so browser-stored solutions don't cut it for me.)

Let me clarify the arguments in the essay to the responses raised so far (I hope this isn't too repetitive):

1: Users don't want to pay for content

It's certainly not a binary question, but that's the thrust of the argument: if there is both free and non-free content, some people worry that most people will stick with the free content.

Certainly an author can avoid the success tax by making all the content non-free, but that doesn't make upay a success in that context, if what happens in practice is that 99% of that author's readers leave. Or at least most of us wouldn't call that a success.

2. Users don't want to deal with upay decision-making
4. Getting upay into browsers is hard

I don't think cjs' responses to these two add up to something very satisfying: "yes, you need a good UI, so when you need the good UI for micropayments, you'll go launch a special P2P micropyament delivery system"? That's awfully inconvenient if it happens in the middle of regular browsing. Some people believe it's inconvenient enough to be a barrier to user participation.

3. Users want to keep the content they pay for

cjs' response misstates the central concern here... my example of being able to resell was not the point and clearly a mistake on my part; I was just looking to point out that there is something physically there and tangible.

Certainly a browser-external P2P system can guarantee you download, rather than just view, content; e.g. that's how napster and gnutella work. but a built-into-the-browser system (like current subscriptions services) do not make any such guarantee.

5. critical mass

The two concerns with critical mass are for authors and for upay businesses.

Let's look at it from the author's point of view. Yes, you can be non-binary and provide all your content both through upay and through non-upay (non-pay-at-all), but what's the incentive for anyone to pay? And if you put your content exclusively behind pay barriers, any user who's currently not signed-up to your upay service isn't likely to be willing to jump through the hoops just to see it.

From the business point of view, if you're aggregating a lot of micropayments into single transactions that are turned into a traditional transaction (e.g. a credit card charge), you need a big matrix of consumers and authors, and you aggregate all the micropayments from one consumer into a single charge, and you aggregate all the micropayments to one author into a single payment. Until there are enough authors providing content that each consumer is hitting hundreds or thousands of micropayments each month (whatever it takes to hit, say, ten dollars), it will be difficult to aggregate the charges successfully.

(This is all based on guesswork on my part about what's going on behind the scenes.)

6. technological improvements

As I noted in the original essay, the p2p situation cjs describes for avoiding bandwidth problems can occur on a p2p *free* net, instead of a p2p upay net. So that's a disincentive for anyone to get involved with a p2p upay net.

Since all of the examples cjs listed are free nets, not pay nets, I'm not sure what a "p2p mupay" net is supposed to be (nor am I clear what the providers' business models are). I think we can all agree if there were a free p2p net that worked well and was easy to use, we'd be all over it for solving the success tax problem.

7. becoming a business

Well, this one was a big question mark for me, but the primary worry that I was trying to raise is that if you're a hobbyist, not trying to make any money, just trying to pay the success tax by collecting money through micropayments may force you to become a business. (I don't actually know.)

Yes, once you decide to go past it as a hobby, you'd have to anyway. But it's the hobbyist that concerns me. Hence my suggestion that we get around that by having free websites use micropayments. So if it's true that accepting upay would require you to be a business, then I'd suggest we can get around this argument if free websites use micropayments--but that becomes another burden, another barrier: we need to see adoption of upay by the free providers at some point in the transition, and I'm not sure how we get them onto the same page, and how they get past the chicken-and-egg problem.

8. 9. middlemen

True p2p avoids this, yep. If there's third-party authentication because there's real money involved, then I dunno; or if there's a business involved in it at all, they can be subject to the same attacks as Napster (see the discussion of KaZaA below).

MojoNation rubbed me the wrong way when I looked at it (one or two years ago?); it didn't seem like it was really possible for a 56K user to participate (to acquire Mojo), because upload bandwidth from such a user is too precious; and unfortunately, even now, penetration of broadband is pretty low. (I saw a year-old gov report, I forget the numbers, something like 10% of on-line homes?)

Swarmcast's explanation is a little incoherent for me, it seems to rely on lots of people downloading the same file at the same time, so it would be good for live broadcasts but not much else. (Note that this is not what the Swarmcast FAQ answers for 'what is swarmcast', but it's the best I can figure from reading 'how it works'; but it's related to the word 'cast' so I suspect I've got it right.)

Also, p2p systems have problems with people running behind NATs and some firewalls. The NAT2NAT problem can be really severe. (I think Swarmcast says you're screwed; in the section on 'relay server' MojoNation's FAQ points out that people behind firewalls are spending "a steady toll in Mojo"--simply because they have to constantly reach out and ask 'anything new for me?' since they can't receive an incoming connection.)

p2p indexing is a severe problem; true p2p systems (like Gnutella and FreeNet) have significant problems with inaccessible data; whereas systems that rely on a indexing server (like Napster) will require a company with funding to run the server.

Looking up Morpheus said it was based on KaZaA, so I took a look at that. KaZaA is basically a super-gnutella, so it's still got issues: content isn't automatically replicated, as in MojoNation or FreeNet; content searches don't seem to be guaranteed (not that they'll admit that anywhere).
KaZaA is European, and one site noted the following:

<blockquote>In terms of business model and legality: KaZaA is currently in discussions with European collecting rights organizations. They intend to launch a subscription model where their users can pay a subscription fee and the bulk of this fee will be passed on to the collecting rights organizations who in turn will redistribute this to the artists.</blockquote>

Note that there's a pretty clear separation of activity described above: the rights organizations won't know what's actually being downloaded frequently; so they'll just distribute the money based on success in some other medium. This is, of course, exactly one of the middlemen monopoly rants I launched into (using the BMI charging clubs as an example), and basically makes the situation no different than Napster, but with different tech. (And since KaZaA supports all file types, not just music, I'm not sure how they'll decide how to divvy up between them. Some to the motion picture industry, some to the music industry, and some to the porn industry? Oops, no, probably not the last one, even if it's probably 20 or 50% of the content being exchanged. And what about people distributing etexts of books over KaZaA? And pirated computer games? And...)

Sean Barrett
cjstone
Forum Member
Posts: 9
Joined: Wed Jul 11, 2001 7:00 pm
Location: CJ Stone
Contact:

Post by cjstone »

I drew the line about getting more usernames and passwords a year or two ago.
I hear you, man.
1: Users don't want to pay for content...It's certainly not a binary question, but that's the thrust of the argument: if there is both free and non-free content, some people worry that most people will stick with the free content.
"Users don't want to pay for content" is a gross generalization, and I think it's badly formulated. There's a sense in which no one wants to pay for anything because free is (all the good things about free here). So, rather than talk about their wants, let's talk about their wills.

It's important not to assume a binary position--either all will or all won't--when we know that some will and some will not. Economically, we want to know, "Is the 'some will' group large enough to support micropayments?"

It's also important not to binary the 'some will' group, because even in the 'some will', some will pay for music and some won't; some will pay for cartoons and some won't; and so on. Many kinds of contents can be provided, and people will organize themselves into different communites of will and won't.

As for people "sticking with free content", there are two things to be unwound here--preference for free content and using free content as bait. In the first case, my dad never goes to see a movie in the theater. He always waits for it to come on TV. He doesn't care about films, so waiting 20 years to see 2001 is no big deal to him. He's indicative of a class of people, but they aren't the whole population, as the film industry proves.

I don't think I have to explain the "free content as bait" formulation very much. Some of it can be complete old content, and some of it can be partial new content.

Finally, free content won't go away because not everything is salable. I really can't pick up sticks from the sidewalk and make a business selling them. Some content is a stick on the sidewalk.
Certainly an author can avoid the success tax by making all the content non-free, but that doesn't make upay a success in that context, if what happens in practice is that 99% of that author's readers leave. Or at least most of us wouldn't call that a success.
I'm not sure what the argument is here. In a closed, P2P mupay net with swarming techniques, the seller gets a valid pay token from the buyer, and the buyer gets an assembling URL from the seller. The buyer assembles the purchase from peers on the net, and the total amount transferred is invisible to any one ISP or web host because the individual chops are so small. Success tax avoided by closure and swarming.
(you'll see something you want in your browser and) you'll go launch a special P2P micropyament delivery system"? That's awfully inconvenient if it happens in the middle of regular browsing. Some people believe it's inconvenient enough to be a barrier to user participation.
Well, it's not necessarily any more inconvienient than any other plug-in my browser launches. When I look at a PDF document on the web, my browser actually launches Acrobat for me, too, and it all happens in the background. It could be the same deal with the mupay software. Some people would not believe it's inconvienient enough to be a barrier.
3. Users want to keep the content they pay for...I was just looking to point out that there is something physically there and tangible.
And you ably pointed out that we often buy stuff that's written on the wind, like a concert or a movie.
Certainly a browser-external P2P system can guarantee you download...but a built-into-the-browser system (like current subscriptions services) do not make any such guarantee.
No, no guarantee--that's a contractual matter for however it is your browser functions with the P2P system and for however it is the P2P system functions with you. Very little is guaranteed; that's why contracts exist.
5. critical mass...Let's look at it from the author's point of view. Yes, you can be non-binary and provide all your content both through upay and through non-upay (non-pay-at-all), but what's the incentive for anyone to pay? And if you put your content exclusively behind pay barriers, any user who's currently not signed-up to your upay service isn't likely to be willing to jump through the hoops just to see it.
I meant to say two things. First, authors can have a warning period--"I'm going Behind the Green Door on 1/1/99"--and second, as noted above, they can present old content, bait, and things that aren't salable.

As for what users are and aren't likely to do, we know that fans follow their idols through rather expensive doorways. If the doorway isn't expensive, so much the better and so many more followers. I, for one, would pay a few cents to see SMcC's work.
From the business point of view, if you're aggregating a lot of micropayments into single transactions that are turned into a traditional transaction (e.g. a credit card charge)...SNIP...Until...hundreds or thousands of micropayments each month (whatever it takes to hit, say, ten dollars), it will be difficult to aggregate the charges successfully.
If the closed P2P mupay system has a "strongbox" (and I don't want to say "bank" for many reasons), then everyone who joins puts a stake in the strongbox. All pay tokens were validated before they were used, so no one pays money they don't have; thus, at the end of the "day", all tokens are resolved and aggregated. This is separated from "cashing out".

By law, anyone can cash out whenever they want, and this separate action, cashing out, can be handled by whatever CCP scheme you like, including mere "reversal of charge" to a member's credit card.
As I noted in the original essay, the p2p situation cjs describes for avoiding bandwidth problems can occur on a p2p *free* net, instead of a p2p upay net. So that's a disincentive for anyone to get involved with a p2p upay net.
?? Swarming protects members of a P2P net from an ISP's "excessive transfer" charges; and, Yes, swarming works in or out of a mupay net; so I don't see how that's a disincentive of any kind.
Since all of the examples cjs listed are free nets, not pay nets, I'm not sure what a "p2p mupay" net is supposed to be (nor am I clear what the providers' business models are). I think we can all agree if there were a free p2p net that worked well and was easy to use, we'd be all over it for solving the success tax problem.
These are all free because no one is doing it. In the case of MojoNation, Jim McCoy said he intended to start a mupay net but started before people got the idea at all. In the mean time, he realized his strength was creating the software for mupay, not running a for-profit mupay net itself. Others have only recently started and are testing the backbone of their P2P net.
people behind firewalls
I'm not worried about this right now. I'm not trying to make it work for people behind NATs and firewalls.
p2p indexing is a severe problem
It's a crucial problem--the system can't work without it--but it's a solvable problem.
n terms of business model and legality: KaZaA is currently in discussions with European collecting rights organizations. They intend to launch a subscription model where their users can pay a subscription fee and the bulk of this fee will be passed on to the collecting rights organizations who in turn will redistribute this to the artists...SNIP...And what about people distributing etexts of books? And pirated computer games? And...
I think that thinking about this in any terms other than "content creator factory direct to you the customer" is counterproductive. Any net of this type needs to contain clauses in its join-up contract that say things like

"To the best of her knowledge, the author warrants and represents:
i. she is sole author and proprietor of the work
ii. she is the sole owner of the rights granted here
iii. she has the full right, power, and authority to enter into the agreement and to grant the rights granted here
iv. that except for materials of others (which she has obtained or will obtain permission to use), the work is original
v. neither the work nor any material portion of it is in the public domain
vi. it infringes no right of privacy
vii. it contains no matter which is libelous
viii. it does not violate any personal or other right of any kind of any person or entity
ix. it contains no material that would violate any contract of hers, express or implied
x. it contains no material that would disclose any information given to her on the understanding that it would not be published or disclosed and it contains no material that plagiarizes or pirates any other work or infringes any copyright, trademark, or other proprietary right no recipe, formula, or instruction in it is injurious to the user or others "

Which is verbatim from the Stone Dragon Press Standard "Rich and Famous" Contract, to wit, if you don't own it, don't sell it.

Now let me generalize a bit...we've been talking about two things, asking two questions. Question one: "Is it technically possible?"; question two: "Will anyone use it?" We've been switching back and forth between them a bit, and I'm not going to refactor the page to eliminate that. Instead, I'll tell you about my experience in publishing-on-demand (POD).

Here's the curve POD followed:

Years ago: state
7: Technology available, but only very high end.
6: Technology reaches middle end, and articles begin on possibilities.
5: Low-end vendors like Xerox and Kodak enter market. Everyone now agrees POD good for creators, but impossible.
4: POD possible, but not feasible.
3: Feasible, but if it could really work, it would have already been done.
2: POD service bureaus appear.
1: National corporations make POD available to anyone with as little as $150.

So, I'd say we're in year 5--low end vendors have created an infrastructure, and everyone says it's good, but it can't work. Sample networks are in place, but folks are waiting for it to fail miserably one way or another. After all, it just can't be done, or it would have already been done.

cjs
"The Romans could have invented the bicycle, but they didn't.

<font size=-1>[ This Message was edited by: cjstone on 2001-07-14 14:23 ]</font>
lylebclarke
Frequent Poster
Posts: 53
Joined: Sun Apr 15, 2001 7:00 pm
Location: New Zealand and Denmark
Contact:

Post by lylebclarke »

Sean and cjstone,

I'd just like to say that I am very much enjoying reading your posts, and appreciate the attention you are giving this topic.

Secondly, regarding the middleman Sean eluded to in his excellent essay, I recently found out that CyberCash has been bought by VeriSign, who have plans on integrating it into at least one of their products. A couple of days ago I read that Microsoft are partnering with VeriSign, with VeriSign providing various services to Microsoft. I have also absorbed (from where I don't know) the idea that WinXP will require users to have a Microsoft Passport account by default. Microsoft Passport already has a wallet feature. I feel like a bit of a consipracy theorist, and am way out of my depth here, but would I be right in thinking that Microsoft might already be on the verge of trying micropayments?

I know that Microsoft trying something isn't a guarentee of success, but what do you guys think?

Lyle
cjstone
Forum Member
Posts: 9
Joined: Wed Jul 11, 2001 7:00 pm
Location: CJ Stone
Contact:

Post by cjstone »

I think MS is talking out of both sides of its mouth. In 1997, it said

http://slate.msn.com/CriticalMass/97-02 ... alMass.asp

and note there are NO--and I mean NO--technical hurdles in this critique. But MS is still against it.

Read it and see what you think.

cjs
User avatar
Greg Stephens
Forum Founder
Posts: 3862
Joined: Sat Apr 14, 2001 7:00 pm
Location: Los Angeles, California, USA
Contact:

Post by Greg Stephens »

On the other hand, that was 1997-- 28 years ago in dog years; infinitely more in internet years. Microsoft has been known to make radical changes in policy if there's money to be made.
Good morning! That's a nice tnetennba.
Guest

Post by Guest »

(Sean again)

Between Microsoft's avowed "toll-collecting" philosophy and the fact that four years is a long time in Internet time, who knows what MS thinks about micropayments, or what they intend?

Bottom line about the Slate editorial is he seems to be saying "why do micropayments when you have ad banners"--which may have seemed reasonable in 1997, but is a frivolous argument now.


Guest

Post by Guest »

(Sean again)

In response to cjstone's article:

Ok, let me see if I've got this right. Basically, you have one particularly model you believe in ("p2p [m]upay"), and you're responding to a number of my criticisms on that basis. I think I was making the mistake of trying to defend my criticisms in general instead of just on that specific point.

So on that specific point, I will say a few things:

<b>One</b>, there doesn't seem to be an example of p2p upay currently, so I don't know why you write things like 'indexing is solveable', when it's a really hard problem. I was on the "next-generation gnutella" mailing list for a while; it's a hard problem to do truely distributed--every single person with a proposal for NG-gnutella said "we can only guarantee that every peer can see a small fraction of other peers as the net grows" (and I will spare you my rant about the meaninglessness of improving Gnutella's scalability if that's the case); whereas providing a central server (or cluster of servers like IRC uses) will open things up to legal action.

<b>Two</b>, p2p <i>free</i> nets may avoid the success tax, demotivating users from the effort of getting into a p2p upay net, hence blocking p2p upay nets from succeeding (which will suck for people who want to make a <i>living</i>.)

<b>Three</b>, first to clarify, things like swarming are cool, but swarming is pretty much irrelevant to this discussion. To avoid the server bandwidth overload, you only need <i>replication</i>, not swarming.

Swarming, if I understand correctly, is a technique for getting fast downloads by spreading the bandwidth for a single download across multiple "servers" (peers); but to avoid the success tax you just need to spread the bandwidth for <i>multiple</i> downloads across multiple "servers"--that is, put the file on lots of machines and get people to download it from different locations. This is already achieved by social forces on Gnutella and Napster (there are ten zillion copies of popular songs out there, because people put them in their share, or download them and leave them in their share), and achieved through technology with FreeNet and, I think, MojoNation even before MN added swarming.

This all works because people <i>aren't</i> paying for content, and they <i>are</i> free to replicate it. I'm not clear how this replication is supposed to work if there is supposed to be a clear accounting for each copy, so that a micropayment can be issued for accessing it. (I suppose this is another example of "I don't see any proposals on the table for what a p2p [m]upay net really is".)

In general, a lot of the barriers to achieving micropayments are social barriers, not technological barriers, and I think a P2P upay net is still going to have all of the problems there--the fact it's not part of the browser, or it's a plugin which works totally differently; the chicken-and-egg problems, etc. cjstone addressed any number of these in response, and I guess it's just a case where it's all a matter of opinion, until we see how it plays out.

I'm not sure it's reasonable to discount everyone who's behind a NAT or firewall, but I don't actually know what percentage of users that is. But NATs and firewalls only pose a problem for P2P solutions.
cjstone
Forum Member
Posts: 9
Joined: Wed Jul 11, 2001 7:00 pm
Location: CJ Stone
Contact:

Post by cjstone »

About the 1997 MS micropayment article--

You've all hit it exactly. Their complaints are sociological, not technical. It's not that it can't be done, it's that no one at Microsoft wants it to be done; therefore, it's impossible.

Except that Oceania is now allied with Eastasia and not those other scumbag backstabbers we were never really allied with in the first place, and the Ministry of Micropayments has rallied around the widows and orphans of the war heroes...

cjs
cjstone
Forum Member
Posts: 9
Joined: Wed Jul 11, 2001 7:00 pm
Location: CJ Stone
Contact:

Post by cjstone »

Ok, let me see if I've got this right. Basically, you have one particularly model you believe in ("p2p [m]upay"), and you're responding to a number of my criticisms on that basis. I think I was making the mistake of trying to defend my criticisms in general instead of just on that specific point.
Yes, the 2nd paragraph of my initial post did read "Second, I want to frame my response in terms of a closed, peer-to-peer micropayments system." I did that in part to highlight that--at this point in the status of micropayments--general concerns have to be considered under a specific framework, or they can't be resolved.

For example, a common concern is the cost-per-transaction (CPT) that most CCPs bring to the table. Left to stand, that single cost completely undermines micropayments; therefore, to continue the discussion, we have to first answer the question "How can we get rid of the expensive CPT charged by CCPs?" Answer: "Make the micropayments net P2P, close the net, allow a central strongbox to which members can make one large deposit (a single CPT for the CCP), let them draw from the strongbox for zero or micro cost to pay for in-net content."

Now that's only one answer, but do note it completely obliterates all objections based on excessive CPT.; thus, some general items are only stumbling blocks in a general context, and I wanted to highlight that with my favorite specific context.

(Please, don't anyone write back about problems this specific solution might create. All solutions come with problems--no internally self consistent system can produce all statements valid inside that system (Goedel, 1932?); therefore, a set of patches will always be required to cover the universe of discussion. Evaluation of the patches is best reserved for the implementation threat team unless it's a killer: "oh, we'd have to deny everyone due process to make that work, so never mind", and I don't think any problems stemming from my example are killers.)
One, there doesn't seem to be an example of p2p upay currently, so I don't know why you write things like 'indexing is solveable', when it's a really hard problem...providing a central server (or cluster of servers like IRC uses) will open things up to legal action.
We may not be talking about the same thing. Right now, here's the specific thing I am imagining...the UI for the mupay net gives authors a dialog box that helps and limits their description of their content. Behind the scenes, the mupay software takes the inputs from the dialog box and generates an XML "index card" for the "card catalog" of all the content on the net. Because this index card is XML, it can also be exported outside the mupay net to the author's web site as bait.

To me, the hard part is "Where is the card catalog?" If it is distributed, too, it's possible for parts of it to be missing. Even if you add swarming, reassembling the catalog in any meaningful way might take too long. Again, I think this is a solvable problem even though the solution is not immediately obvious to me, and it is a killer problem for the reason you note (legal action).
Two, p2p free nets may avoid the success tax, demotivating users from the effort of getting into a p2p upay net, hence blocking p2p upay nets from succeeding (which will suck for people who want to make a living.)

Three, first to clarify, things like swarming are cool, but swarming is pretty much irrelevant to this discussion. To avoid the server bandwidth overload, you only need replication, not swarming.

Swarming, if I understand correctly, is a technique for getting fast downloads by spreading the bandwidth for a single download across multiple "servers" (peers); but to avoid the success tax you just need to spread the bandwidth for multiple downloads across multiple "servers"--that is, put the file on lots of machines and get people to download it from different locations.
Two things under discussion here: 1) what is swarming?; 2) making a living from micropayments.

Swarming does two things: it chops the files up, and it stores each chop in multiple locations. The chops are small enough for even little players--guys like me, in fact, guys with a 56Kinda dialup over the family phone line--can contribute a chop to a download in a reasonable amount of time and can receive a complete download without choking the dialup or calling attention to the size of the download. (MojoNation estimates this as 64K.)

Because the download is like clipping the words in your ransom note from lots of magazines and papers, no ISP should even notice what's going on. You make a complete sentence, but each reader of the source magazines and papers is only missing one word, a word the reader can probably deduce. (OK, two words, because mags and papers are printed duplex.)

Now, about making a living...if we make the binary assumption that people who are making nothing now will be completely supporting themselves the minnit they go to micropayments, it's a mistake. Some authors will be happy to get pin money from mupay, others need a full salary, and most in between. Some will ramp up fast, some slow. Some will have surprise success, and others will have surprise failure. While it's possible to explain to authors extensively in advance and get them to sign contracts before the net is started so there seems to be mondo content already burgeoning when J. Random Customer joins the net on its very first day of operation, it's not necessary if we will expand our view of success. Ultimately, many of them are receiving nothing for what they are doing, and the promise of receiving something may be enough.
This all works because people aren't paying for content, and they are free to replicate it. I'm not clear how this replication is supposed to work if there is supposed to be a clear accounting for each copy, so that a micropayment can be issued for accessing it. (I suppose this is another example of "I don't see any proposals on the table for what a p2p [m]upay net really is".)
Again, a specific implementation. On MojoNation, it's the author's computer that does the storing to other computers on the P2P net; and the author is the one with the resource descriptor (RD). When the payment token is offered, the author takes it and replies with the RD. The customer "starts" the RD, and it goes and gets the content and puts it on their hard drive. The RD knows how to assemble the content from all copies of all chops, so failure is reduced; however, a reputation manager is part of this equation, and should be used to judge the entire transaction (like the EPA mileage rating on cars).
In general, a lot of the barriers to achieving micropayments are social barriers, not technological barriers, and I think a P2P upay net is still going to have all of the problems there--and I guess it's just a case where it's all a matter of opinion, until we see how it plays out.
That's exactly correct. And I'm of the opinion that most sociological problems can be solved in a specific implementation. In fact, it's the sociological problems that drive what will be specifically implemented so those problems can be answered.

And when I go in front of Charlie (the VC to folks who aren't in-country) or an angel, I have to be able to answer their general questions with my specific implementation and convince them that any qualms they still have when it's over are normal startup jitters and the usual uncertainty of any new venture.
I'm not sure it's reasonable to discount everyone who's behind a NAT or firewall, but I don't actually know what percentage of users that is. But NATs and firewalls only pose a problem for P2P solutions.
What I said was, "I'm not worried about this RIGHT NOW. I'm not trying to make it work for people behind NATs and firewalls." emphasis added Like you, I also don't know what percentage of users are protected, and until I hear from somebody about that, I'm assuming people are doing this at home or from businesses where protection isn't an issue, and I'm keeping my assumption posted where I can remember I assumed that.

Hey, this is good fun. I'm really enjoying talking the ideas out. I hope you aren't feeling like, "Yeah, well, your mom dresses you funny and you smell bad, so there," cause I'm not trying to do that or anything.

cjs
Sean[cc]
Forum Member
Posts: 8
Joined: Fri May 25, 2001 7:00 pm
Contact:

Post by Sean[cc] »

Excellent discussion you've got going here, and a good, long, read to boot.
The big cheese @ <a href="http://www.cartooncommunity.com">CartoonCommunity</a> and <a href="http://www.cartoonist-resources.net">Cartoonist Resources</a>. Also the co-founder of <a href="http://www.fre--conversant.com/threadmo ... eadmole</a>.
Guest

Post by Guest »

(the other Sean)

cjs: I have no problem with the tone of the discussion. I realized that my first "defense" was a bit long and off point from your focus, so I wanted to make a better effort to get us (me) on the same page.

To address one thing I left out before, your comments about printing on demand are interesting--but unfortunately I don't think there's any reason to assume that success story maps onto micropayments, as oppose to any of hundreds of failure stories of "services some people wanted that never succeeded in the marketplace". But it's a fairly good example of why it certainly <i>is</i> possible that they've failed before but could still succeed. I'm not sure exactly how it maps though, e.g. what the chicken-and-egg problems for them were.

I still disagree with your assessment of swarming: it's goal is to address download speed, not server bandwidth--server bandwidth is adequately addressed by mere replication, which is a lot simpler, and already widely deployed. Swarming is only of interest to broadband users downloading from 56K users, which represents such a tiny population that I doubt it's going to impact the net at large, although it may be popular amongst people trading large media files (e.g. mp3s and movies)--but it's never to the benefit of the 56K users (except to the agree it, say, earns them Mojo), who can't see any increase in speed.

Moving on from responding to cjs, one observation about the whole credit card scenario that dawned on me while I was working out some of the math was the following:

(Now, this could entirely be a straw man in some sense. I'm not saying the following mechanism is the only plausible mechanism. But it's interesting to think about.)

Let's suppose that the way some micropayment scheme we're thinking about is going to work is by aggregating payments to avoid the transaction overhead. Let's assume that an acceptable overhead from a user/author point of view is something like 20%. (Yes, I'm making all these numbers up. And the numbers chosen make a big difference in the conclusion. Beware straw men.)

Let's suppose that the CCP charge on a credit card transaction of $10 <b>or less</b> is $1. (It's not a micropayment--it doesn't scale properly for small payments.) Let's suppose the micropayment provider pulls out another 10% to hit our 20%--that $1 on $10 is enough for the micropayment provider to cover costs and make money. (Notice I'm still making everything up. This is just an enormous thought experiment.)

Now, suppose we use any mechanism where a user gets charged once a month, as opposed to depositing some money up front which can last for several months. (Yes, this is a huge chain of assumptions.)

The interesting result: if typical users are making less than $10 in micropayments each month, the transaction cost starts eating into more than 10% of the 20% overhead, cutting into the profits and gross for the micropayment provider. By $5/month per user the CCP charge is eating it all up, and no money is going to the upay provider.

The end result is that if you end up with a upay system like the above, users <i>have</i> to be paying a fairly noticeable amount of money ($10) each month for the system to be workable. (I say noticeable in the sense that it's a significant percentage of a typical ISP dialup bill.)

So if you find lots of people on Slashdot or somewhere saying "I don't mind paying for some content, as long as it's, oh, $20 a year total for everything I read", that's going to be problematic for any system like the above. If, on the other hand, you think most people will be happy paying $10/month for content, it's no big deal.

And if the numbers all work out differently (I bought something through Paypal for $15 the other day and the service charge was $0.72, I think--I wonder what it is on demian5's recommended $3 donation), then of course it may be less (or more) of a big deal.

But I think it's kinda interesting to reverse the whole question and say "how much are people really going to be spending per month? ok, and how are we going to make that work?"
John2two
Regular Poster
Posts: 22
Joined: Sun Apr 15, 2001 7:00 pm
Location: Monroe, Oregon, USA
Contact:

Post by John2two »

Sean, I don't think you have built a terribly shaky straw man here. Any system that aggregates does indeed depend on certain average volumes from the consumers.

The wiggle room around this point is that credit card transactions are not the only style of macro transaction that can serve as the base for a micro system. A successful micropay infrastructure will have to allow different entities to devise different ways of converting the micros into external transactions. Therein lies the room for competitive differences that makes a market work.
  • Businesses (or micro-wallet product offerings) that are based on credit card transactions will have one floor for average use ($10/month, using your example figures).
  • Businesses or offerings that are based on electronic debits to the consumers' deposit accounts will have a different floor. Let's extend your example to pretend that that floor is US$6/month.
  • Businesses or offerings that are based on pre-pay accounts step around the time-density-volume equation completely since they have float on the balance while you take your sweet time to micro-nickel and micro-dime your balance away.
While you have a valid point, I think it only shapes the parameters of how various business models would need to work. I don't take it as a universal strike against the micropay concept. (Edit, after re-reading Sean's last paragraph.)Which I guess is your point.

(BTW, I'm really enjoying this conversation, too. I trust you don't mind if I jump in when I feel the urge. This is such a refreshing antidote to the logic-free swarming posts during the ICST#6 flame war.)

John

<font size=-1>[ This Message was edited by: John2two on 2001-07-17 08:33 ]</font>
Guest

Post by Guest »

Ugh, you just reminded me of something worse: one of the things that I think has to happen (as I state in Micropayment Barriers) is for people to not use micropayments for everything--e.g. to use subscriptions for content they're sure they want, and to use micropayments for one-shots and exploration.

But now if a micropayment system requires, say, $10 of use per customer to be successful, but most users spend $25 a month, but 90% of that on subscriptions...

Hopefully there will be some micropayment model where the minimum volume for success is more like $2 or $5, I guess.
cjstone
Forum Member
Posts: 9
Joined: Wed Jul 11, 2001 7:00 pm
Location: CJ Stone
Contact:

Post by cjstone »

Subscriptions
I'm not sure discussing subscriptions is germane. Magazines discount subscriptions because they can 1) get their money up front and plan their fiscal year; 2) ship large numbers of magazines to a single location for processing; 3) avoid the financial risk of sending a magazine to a newsstand and then have to take it back.

Thus, subscriptions allow them to control their variable costs, and they pass some of the savings to the subscriber as an incentive to subscribe.On the web, the variable costs of this type are virtually nil, so subscriptions don't make a lot of sense unless you are an online-only magazine, and you are then using the online subscription to cover your fixed costs.

Note: that's about magazines. It's true for newspapers, too, but it's not very true for an author creating a daily strip, writing a weekly column, etc., and selling it directly to customers for a micropayment. Discounting a $20 subscription 10% to $18 makes sense; discounting a $0.02 micropayment to $0.018 makes a lot less sense. Aggregating the daily strip, for example, on a standard 250-day work year means the subscription would be $5, and the discount would be $4.50; but who gets what out of that $0.50 savings?

At the grocery store, where that kind of discount is common, they are using the coupon in part to track demographics (who buys what where and who reads what advertising where). Magazines subscriptions also track demographics so they can sell advertising. In both cases, the discount collects demography, and the discount wouldn't be useful that way in a micropayment subscription--you already have your customers' demographics at the non-subscrption level.

We could get into loss-leaders and stuff, and we could argue about 250 x microcost-per-transaction vs. 1 x microcost-subscription-transaction, but the standard "fixed cost vs. variable cost + returns on cash up front + fiscal planning" doesn't seem to bear up at the micropayment level if the content is factory direct to the customer.

And now you know why physicists have such trouble unifying macrobehavior and microbehavior--different metrics.

cjs
Guest

Post by Guest »

The main argument for subscriptions (in my mind) is in response to the "cognitive load" barrier: paying for most things by subscriptions means you don't have to devote the mental energy of deciding to pay for those things any further.
cjstone
Forum Member
Posts: 9
Joined: Wed Jul 11, 2001 7:00 pm
Location: CJ Stone
Contact:

Post by cjstone »

Top-Down vs. Bottom-Up
Perhaps this belongs over in the "micropayments" thread, but it's had no new real input since the end of May, and we seem to be jumping here, so hit me with the clown-hammer if I'm off topic.

In that thread, they were talking about New Gen Payment Systems and Cartio (Cartio suggests you go to NetActuals to get the structural dope on them.) It seemed like there was a micropayment answer aborning at these sites.

First, all these things are actually one. Cartio has implemented NewGenPay protocols via NetActuals. The different sites are imparting the information in different ways to different audiences.

Second, it's a top-down approach. They want storefront-type customers to install their micropayment software and get their customers to install wallet software. They may succeed where others have failed because they are working on a W3C standard, interoperable wallet and micropayment markup protocol; and they hope that everyone will use that system.

Third, while their Merchant Thingy is free, it isn't easy. They say that themselves. They also say you need a relational database at your end to make it work. ("Database--stores all the data about clients, groups, and purchase orders...the actual RDBMS (Relational Data Base ManagementSystem) can be any product that supplies an ODBC interface. (Open DatabaseConnectivity)" and they favor MS-SQL and MS Access.) So most small people are out.

So, you have to have a certain kind of superstructure or be able to handle that kind of superstructure to make their deal work. Now, if you can handle that, it's a very good deal, because it means a telco can develop a billing server using their interoperable protocols, and if you buy something far away, you can have the microbill appear on your telco bill. That would be a good and useful implementation of top-down micropayments.

Packages like Morpheus, SwarmCast, MojoNation, Gnutella and FreeNet mutations, and so on are bottom-up, and don't require the kind of superstructure noted. In the case of MojoNation-type closed P2P network, anyone at any level can start with zero and theoretically earn the ability to buy content by sharing resources with the peer-to-peer net; thus, theoretically, a credit card is not even necessary. That would be a good and useful implementation of micropayments, too.

cjs

<font size=-1>[ This Message was edited by: cjstone on 2001-07-18 19:08 ]</font>
Locked