Notes

Introduction and Summary (Home page)

1. One key problem: it's hard to handle small payments well. Most efforts to fix this for independent artists have failed (e.g. Bitpass) or had only limited success. Small-payment systems so far work mainly for corporations (like selling phone apps or ring tones, where the billing already exists -- or for companies like Apple that can get millions of people signed up). We also need systems that work for independent artists who are not celebrities.
2. We guesstimated that only a small percentage will pay to sponsor, from an observation published several years ago that if a free website asked for contributions, about 2% of visitors would contribute and 98% would not. Also, the 2% translates to an average (mean, not median) sponsorship of 50 copies, which seems reasonable, especially since any very large sponsorships will move the average strongly higher. While the 2% might appear optimistic today, remember that mass sponsorship is not a purely voluntary, pay-if-you-want system; free copies stop whenever sponsorships are exhausted, creating new incentives for sponsors to act immediately. Also, RepliCounts lets sponsors send their own messages to their own social networks, or to 3rd-party networks if they choose -- unlike the usual "tip jar" arrangement.
3. New accounts can be "born" ready to go, with dozens or hundreds of services, settings, capabilities, and other options already set up like the parent account. Doing this much setup manually for many new accounts would be a nightmare. So replication makes new business models feasible, when they would be possible but difficult otherwise.
4. For example, an account could be born irrevocably restricted to never pay more than 5 cents at a time -- or to make more than 10 such payments a day -- or to pay the 5 cents or less to anyone other than a single party, at a RepliCount set up for that purpose. Even the owner could never change these conditions (although the owner could kill the account, automatically receiving any remaining money at a secret, unchangeable destination). Such an account, too small to steal and/or too restricted, could (for example) establish an email "paybump" (a small paywall, maybe just 5 cents) to stop most spam -- letting you get through to prominent people more easily, at special addresses they publish for that purpose. You could put a "live" 5-cent payment in the signature, with no need for encryption or other security -- since the ordinarily-absurd security restrictions on these accounts make theft unprofitable.
5. Evolution happens because an owner's changes to an account are inherited through future account generations -- like mutations in biology. The "fittest" accounts are roughly those whose owners like them enough to use and distribute their offspring most widely. Of course this evolution of account settings is constrained to capabilities provided by software on the server. But in practice, competing RepliCounts services will have strong incentives to follow customer demand -- usually allowing account evolution to go where customers and communities want it to go, ultimately, even if financial institutions would have preferred something else.
6. A smart URL is really a RepliCount name in clickable form -- although only some RepliCounts, called public accounts, can ever have a smart URL. Instead of pointing to a Web page, a smart URL talks to the database record that represents the RepliCount. Normally, each smart URL handles only one song, video, article, or other digital file; to distribute a different work, the artists create a different smart URL. [Note that the smart URL is central to the mass sponsorship discussed here -- but is not used at all in many other applications of RepliCounts.]
7. Pirate copies will have to compete against equally free legitimate copies that do pay the artists, which of course most people who like the artists will prefer. And legitimate access may also be easier than piracy, since no party needs to be evasive. In case there are not enough sponsored copies to go around, then the artists need to lower their prices -- which helps in two ways to reach a balance, by creating better bargains for sponsors to get their messages out, and also by making each sponsorship go further. On the other hand, if there are too many sponsored copies for the fan base, then the artists must raise their prices, to restrict the number of sponsored copies enough to make sure they all get used, so that sponsors get their money's worth. Note that this dynamic can actually make it unethical for artists to charge sponsors too little per copy -- since then some sponsored copies would never be used, so the sponsor's message would not get delivered as agreed. No one gets hurt by the higher prices, since access is free to end users anyway. Sponsors pay more; but they don't buy unless they want to, and their higher price is for their own benefit (although it also benefits the artists, of course).
8. For monetization, each RepliCounts (or other replicating-accounts) system can fund itself by subtracting an agreed percentage from sponsorships and other money coming in. About 1% should be enough; this is about what debit cards charge merchants today. The other 99% will go to the artists.
9. Except for trademarking our name, RepliCounts™ to prevent confusion -- and the Creative Commons Attribution 3.0 United States License.

Sponsors

No end notes for this page.

Artists

11. Publishers no longer bother to do their basic marketing job -- since they make their money from just a handful of superstars, and lose money on their other artists. No one can reliably predict who the superstars will be, so a publisher signs up rights, waits to see who emerges, gouges them -- and ignores the rest, who may be prohibited from independent work by licensing terms. It's a bad deal for everyone; no wonder most artists leave the field before they are 30. It's one of the many rotten business models maintained by big-money, corporate corruption of official Washington.
12. RepliCounts will work equally well with basically any operating system, browser, and/or telephone (even a Touch-Tone landline, for some purposes). Mobile or other apps could be added later, but are not necessary for a useful proof of principle.
13. Automatic-accounts.com is in fact a domain name we reserved for this purpose.
14. Software experts may note that our "smart URL" is not a real URL (Web address), though it is dressed up to look like one. For example, in a real URL the slash (e.g. in Our-Band/Our-Song) would imply a directory structure at the server. In the smart URL there is no such directory structure; the whole text of "Our-Band/Our-Song" (including the slash) will hash directly into a huge, sparse file of accounts. There's no need to keep the different RepliCounts for the same band (the different songs, in this case) physically adjacent on the disk or other memory. The reason for making the smart URL look like a real URL even though it isn't, is that lots of software (and warmware) out there is already familiar with this format -- and at least can copy it from place to place without choking on unfamiliar characters, etc. Another difference is that capitalization never matters anywhere in a smart URL. Incidentally, the use of the dash to separate words in the name of a band or a song is up to the artists; they could use underscores (Our_Band/Our_Song) or nothing (OurBand/OurSong) instead. The choice will usually be made for search engine optimization; for example, using the dash is best if you want Google to index the different words in the name separately as well as together. Notice that the URL format required of the smart URL does impose constraints on the band's public name; it cannot contain any spaces, for example, though the real names of most bands do.
15. In this case, twenty digits gives excellent security. That's enough numbers so that if every man, woman, and child on Earth had 10 billion different RepliCounts managed by this server, there would still be more to be assigned. If someone tries to guess your RepliCount, the odds are against them. In other contexts, computers could try all those possibilities, for brute-force decryption. Here that will not work, because only the server knows if a guess reaches any actual RepliCount, and it will not let anybody try billions of billions of guesses. (Actually, the server does not know the random-number name of any RepliCount, except some for internal use; the users' random account names are hashed for encryption, a familiar process standard for credit/debit cards. The advantage is that even if criminals secretly steal a complete snapshot copy of the working database, they cannot use that information to enter anyone's account on the live system.
16. A RepliCount can only become a public account at birth; and then it can never change into an ordinary RepliCount. No one including the owner can ever change the secret destination that receives the money. (If this destination becomes compromised or otherwise must be changed, the owner can kill the account entirely and start over. The public will not notice any change. But behind the scenes, the new account will have a different destination for any money it receives.)

Page updated 2010-06-11