RepliCounts for New E-commerce: Paying Artists Online

content is free while the artists get paid

Introduction and Summary

Mission

To help artists, journalists and others make a living independently by distributing their work online. And more.

What's New Here?

Financial accounts that can replicate (reproduce) could easily manage hundreds of different owner services, public services, automatic actions, and other options within the account itself, for all sorts of uses. These greatly empowered online financial accounts will make new business models feasible (when they would be possible but difficult otherwise).

For example, mass sponsorship will let anyone, anywhere, for any reason, sponsor any number of copies of a particular song, video, investigative article, photos, database access, or other online content distributed this way -- making these copies free, registration-free, and hassle-free to end users, encouraging convenient free sharing of sponsored songs or other content (instead of criminalizing sharing), and delivering the sponsor's message (if any) to a uniquely targeted audience. Almost all the sponsorship money can go to the artists, with a small percentage kept to monetize the RepliCounts system. People will have many incentives (not just advertising) for sponsoring particular works of art, investigative journalism, or other content.

There's no "network effect" barrier to introducing RepliCounts for mass sponsorship of art -- no need to somehow sign up a critical mass of users first, before the system becomes useful to any of them. The sponsors and end users never need to know about RepliCounts at all, let alone have one. That's because end users already know how to click for free music or other content on the Web; and potential sponsors (anyone who can pay online) already know how to pay with an ordinary bankcard, PayPal, etc. Therefore the first artist to use RepliCounts could do so successfully, even if nobody else in the world had ever heard of RepliCounts.

RepliCounts™ is the name of our particular design for replicating accounts. There will be others, but we believe RepliCounts is the first (and so far the only one). Our RepliCounts design is freely available for commercial or non-commercial use.

Why Account Replication?

What's the point of the seemingly bizarre idea of allowing online financial accounts to reproduce, creating "children" accounts, grandchildren, etc.?

  1. Replicating accounts can feasibly manage potentially hundreds of services and options -- since new accounts can be "born" ready to go, with most or all of the needed options simply inherited from the parent. Without replication, setting up hundreds of options for each new account would be a nightmare. The benefits are endless; we'll show a few on this page, below.
  2. Replicating account will let owners create (and mark for proper self-destruction) as many accounts as needed -- maybe a dozen new accounts just for conducting personal business within a day or a week. This great flexibility allows ultra-strict, irrevocable security options that would be intolerable in conventional (non-replicating) accounts -- opening doors to new, useful tradeoffs between convenience and security. For example:
    • An account might only have $5 in it, and the owner might choose to risk that amount by sending money in ordinary email, without bothering with encryption.
    • Note that $5 is enough to get 100 emails past a 5-cent paywall (paybump?) for spam control -- enough to stop typical spam, which cannot afford 5 cents per delivery ($5,000 per hundred thousand spam emails). So this tiny paybump could let people known in their field publish special email addresses, to receive email from strangers willing to pay 5 cents for the communication. This is totally different from AOL's disaster in trying to charge for email. For starters, it only affects special email addresses set up for this purpose -- and the recipient sets the price and keeps the money.
    • For instant, spot consulting, the email might deliver a larger amount, like $50 for half an hour's best effort within an agreed time (such as one day or even less, if a calendar maintained by the account itself shows that the time is available). The payer could buy accounts restricted to pay only one particular account belonging the email service -- allowing the owner to casually and safely email almost any amount to the management of the special premium email addresses. Imagine the benefits to projects and organizations from almost instant, hassle-free professional advice from specialists of their choice -- such as resolving a critical question outside the project's field of expertise right away. The accounts themselves could also manage the reputation system, to let users know something about how well each consultant has performed. Our ever-more-specialized society needs services like this.
  3. An owners' changes to account options are normally inherited by future generations, like biological mutations -- allowing a kind of grassroots evolution, in which each account can contain wisdom of many owners of its ancestors, and evolve toward usefulness to people.
  4. The software will be easy to implement and introduce. For example, RepliCounts software can run entirely on one server, compatible with all major operating systems and browsers, with no other software anywhere. (Apps will be convenient later, but are not required for proof of principle.) The dozens or hundreds of services available are modular, and can be added as needed at any time -- even while the accounts are in widespread public use.
  5. Most importantly for easy introduction, the great majority of people using RepliCounts need never own one, know anything about them, or even hear about them. For the most important applications of RepliCounts, users will just click and/or pay online as usual. So there's no learning curve at all -- except for those who are selling their work, or otherwise motivated. And for these applications there's no critical mass of users. For example, the first artists using RepliCounts could be successful even if nobody else in the world had ever heard of them.
  6. "Monetizing" RepliCounts is trivial (unlike Twitter, for example). No need for conventional ads. No need for any upfront payment by artists -- just deduct a small percentage of each sponsorship as it comes in. Hopefully 1% will be enough -- leaving 99% for the artists.
  7. But the most important practical advantage of RepliCounts may be the smart URL. On this site we use the term 'URL' in its popular sense, as a Web address -- even though the "smart URL" is not really a conventional Web address, because it points to a database record instead of a page.

The "Smart URL" -- An Account's Public Face, Public Dashboard, and Online Sponsorship Store

Introduction: A smart URL is a clickable, public or semi-public name for certain RepliCounts. It is the public face of the account. Anyone who has a copy of the smart URL can click it, to reach a simple public dashboard chosen (or created) by the account owner. If the smart URL is distributing art or other content, the dashboard will showed a free-download button (faded or with other changed appearance if it is inactive because no sponsored copies are currently available in that URL). It will also include a small sponsorship box that is always active, in which potential sponsors can choose how many copies to sponsor (or alternatively choose how much to pay -- not trivially related if the account owner chooses a complex bulk-discount formula), enter their sponsor's message (if any) to go out with the free copies, and change defaults if desired on a few other sponsorship options.

Security: For security, RepliCounts will not respond any smart URL unless it is a public account - a RepliCount irrevocably restricted from birth so that it can accept payments and take money in, but cannot hold any money or give any out (it can deliver valuable content, however). Instead, all money taken in transfers immediately to the account owner, at a secret, irrevocable destination (often another RepliCount, which of course cannot be a public account). This security feature allows a public account to be published for anyone to use (on a blog, for example, or even in a newspaper), or to be loosely restricted to a certain group (such as students in a particular class, who need access to proprietary content). All a thief could do with it would be to download many identical copies of the same content (whatever content that public account delivers). There isn't much motive for that, and the owner suffers no financial loss.

The Dashboard Speaks Many Languages: In most cases the dashboard can contain arbitrary graphics, but only standard text labels, chosen from a list provided by the particular RepliCount system (hopefully standardized among most or all companies or other organizations offering RepliCounts). The advantage of using standard labels is that the dashboard can then appear in the user's choice of many different supported languages. All that's necessary to add a new language (at the server) is to obtain translations of all the standard labels into the new language. When the user changes the language, the URL itself will change, so that it can be distributed seamlessly in the new language (any later user can change it back, or to a third language). For example, if the dashboard were in simplified Chinese, a U.S. user might not recognize the language, but that would not matter; the user could click 'English' in a list of languages in the dashboard for an immediate change (to showing the English versions of all the labels -- no machine translation required). The URL would change to an English version that reaches the same RepliCount -- and this version could be distributed in the U.S., and used in English-speaking countries as if it had always been in English. The practical result is that a song, say, might develop a completely unanticipated following in some other part of the world -- with no expense or extra work from the artists.

Note: Many applications of RepliCounts do not use any smart URL or public account at all. But the smart URL is crucial for the distribution of paid content free to the end user. We expect that for a large majority of users, the smart URL is all they will see. They will never have heard about RepliCounts.

A recommended design goal for the public dashboard is to keep it straightforward enough that all users can do what they want with it, without needing any instruction or training.

What Do RepliCounts Look Like?

Part 1, a Smart URL

Since we believe that the great majority of RepliCounts users (maybe 95% or more) will only see a smart URL (and never any other kind of RepliCount), we will explain that first. A smart URL is simply the public (or semi-public) name of a RepliCount (only a "public account" can have one -- a restriction for security purposes, noted above).

A smart URL will take the following form: http://www.automatic-accounts.com/OurBand/OurSong, where the names OurBand and OurSong are chosen by a band or other artist or organization that wants to distribute online content this way, selling sponsorships that provide bulk free access to end users. Note that this looks like a real URL, but actually is not. There's a reason for that.

The first part of the URL, http://www.automatic-accounts.com/, is indeed an ordinary URL. In fact we reserved the automatic-accounts.com domain name for this purpose, to run proof-of-principle software there during early public testing. For now, it just forwards to http://www.replicounts.org.

The second part of the smart URL, OurBand/OurSong, was designed to look like an ordinary URL, so that both people and standard software will know how to handle it. But with an ordinary URL the slashes after the domain name would imply a folder structure. In a smart URL they do not.

Instead, we think the simpler, faster, and safer software implementation would take the rest of the URL after the slash (OurBand/OurSong) and use it to "hash" into one huge file -- which holds thousands or even millions of different RepliCounts, and has plenty of empty space as well, to make the hashed file access efficient. There is no reason to group the different accounts (songs) of the same band together, as in a folder. With reasonable extra empty space in the file, hashing could reach most records with a single disk access -- no matter how big the database. And hashing, if done right, can provide encryption as well as file access, as it does for bankcards. Even someone who managed to steal a running copy of an entire credit-card (or RepliCounts) database could not use that information to find credit-card numbers except by trial and error -- or to get RepliCounts access on the legitimate server, the one that controls the money.

Before the second part of the smart URL gets hashed, its format is standardized in simple ways. Upper case is converted to lower -- so that the artists or others can use whatever capitalization they want for communication, to make their meaning clear, but people seeing or typing the URL don't need to remember what the artists capitalized. Also, any final slash is removed before the hashing is done, to eliminate the possibility of this confusion. So it doesn't matter whether the user includes a final slash or not on the smart URL.

The smart URL specifies not a printable page, but a particular account (a RepliCount) -- a single record in a huge database. The browser never displays that record. Instead it is processed by the RepliCounts system software, which runs 24/7 on a dedicated server and handles each smart URL as it comes in. (The system software also lets the account owner change settings directly, using a private dashboard, as described below.)

You can visualize the RepliCounts database as a giant spreadsheet: the rows are the accounts, and the columns are settings for the various potential account services (most of which the account owner can control, through the private dashboard described below). There could be millions of rows, and hundreds of columns. The services that use the columns exist as software modules on the server. Note that there are almost no system default settings for the spreadsheet cells, since every account in the system except for the first one is "born," inheriting most cells' contents from the corresponding cells of the parent account.

Part 2, Any Other RepliCount

The smart URLs (above) are designed for public circulation (for distributing online content free to the end user while the artists get paid, by sponsors whose have many potential incentives beyond access to the content). Therefore the artists may choose names for public accounts to promote their work and to be easy to remember.

The other RepliCounts (that are not smart URLs) are very different; they must be kept secret in most cases. So there's no need for them to be promotional or memorable to the public (although occasionally an owner might want to request special names easy for him or her to remember). It's usually best for the names to be all-numeric for international use, and also for easier entry into a telephone's numeric keypad on occasion.

So we propose that when an independent band, other artist, etc. opens their non-public RepliCount (often one such account will be enough for one artist or band), the server will suggest an account name that is a random 15-digit number not already in use. The artist can either accept that name, change it to any name desired (not necessarily 15 digits), or reject the random number if they don't like it (for including 13, 666, 911, or other undesirables) and have the system suggest a new random number. Fifteen digits is enough that if somebody could test 100 numbers per second, it would take more than 100 centuries to test them all. In practice the server would be aware of the attack well before the 100 tries. And only the server can tell if the number is right; therefore even infinite computing power outside of the server would not help, unless it also had access to internal data stolen from the server's memory. Even the server never keeps a copy of the random number it suggested -- only of its hashed equivalent.

So an ordinary (not public) RepliCount might be: 268893502789751

No Passwords

Such an account name can also serve as its own password. In developing RepliCounts, we decided to avoid separate passwords entirely in the basic system (passwords and PINs can be added later if needed for special purposes). We could have decided to use the usual account name and password, but did it this way because with lots of new accounts being created, managing all those passwords would be a hassle. This non-password system was secure enough for the traditional numbered, anonymous Swiss bank accounts, where anyone who brought the number in could take the money out.

Of course the limitation of such accounts is that they cannot involve a third party; it's just between the account owner and the bank. For the numbered Swiss accounts, that was good enough.

RepliCounts solves this problem in its own way. Since a RepliCount can reproduce, the account owner can have it create one or any number of new accounts -- checking a box to specify that they are public accounts (which are generally used only as a smart URL). Public RepliCounts can accept money but never hold or release it, a security feature noted above. By default, it is the parent account that receives this money paid by online purchasers into its public-account child. But there is no way to discover what the parent account is; only the owner knows that. And once the new public account has first been used, then no one, not even the account owner, can change where the money goes. That's so that someone who steals the owner's private access (to the public account) cannot any money out.

By the way, the widespread campaign today to force people to use fancy passwords with both small and capital letters plus special characters and numbers, is misguided and will clearly be recognized as such. Mathematically, any format can be equally hard to guess by trial and error, if the password is long enough; therefore it makes more sense to choose the format that work best for the human mind, rather than trying to pack as much variation as possible into a slightly smaller number of characters. Our guess is that the best format for passwords is alphanumeric (no special characters, not case sensitive). Arbitrary capitalizations is especially hard to remember; getting rid of it would change a 5-character password to 6 characters, or 10 to 12, etc. -- but make the longer ones easier to remember than the shorter, and therefore less likely to be written down where they could go astray. RepliCounts suggests all-number names (except for public URLs, which should be easy to remember, not hard to guess). It's as safe as any other password format if used sensibly.

The Owner's (Private) Dashboard

The private account name (usually a number) generally cannot be given to third parties. So generally the owner will use it only to enter the owner's dashboard. Here is where the owner can make changes in the setup of the many services the account provides -- if not satisfied with the settings the account was born with.

This private dashboard will be far more entensive than the minimal public dashboard of a smart URL. Fortunately most owners will only need to use a small part of it. For example, a band that may sell music and videos would not need to know how to use account services for completely different purposes -- such as managing a global fundraising campaign, or sending out messages and/or payments in response to certain event, possibly years or even centuries after the account owner has died.

RepliCounts with significant money in them (if any -- this system is designed for small or specialized payments) would be kept in a safe place. The owner won't need to use it very often. To use it, the owner would simply visit the home page of the RepliCounts server -- www.automatic-accounts.com in the example above. A small box will allow the account name to be typed in, and the owner types the 15-digit number (or other name, of any length), to reach the account's private dashboard.

At the dashboard, the owner could do many things, for example:

Note that there's not much use for the home page of the RepliCounts server, except for access to the (non-public) dashboards of accounts. The sponsors and end users of other content, for example, never need to visit. There must of course be a link for artists, etc. who want to get started setting up a RepliCount, and may not have someone in the same field to give them a partially customized RepliCount to start with. Also, especially as RepliCounts are introduced, there needs to documentation (FAQ, Getting Started, etc.], and a discussion forum for mutual help, or for anyone interested in RepliCounts. The page could use the rest of its space for various offers and promotional materials (especially from artists using the accounts, for example), for the curious who wandered in.

MORE TO COME ...

Hierarchical Passwords (RepliCount Names)

Lost Account Recovery

Miscellaneous

Page updated 2010-04-11

This RepliCounts software design by John S. James is licensed under a Creative Commons Attribution 3.0 United States License.