RepliCounts are online financial or other accounts that can reproduce (replicate) indefinitely, when their owner wants them to.
Reproduction lets each new account inherit services (any amount of setup and other information) from it's "parent," instantly and effortlessly at "birth" -- making new financial infrastructure feasible. Since each owner's changes can be inherited, replicating accounts can evolve in decentralized community use, as they are selected for attractiveness to users.
For example, accounts can inherit the know-how to accept many forms of payment, do routine business in the user's choice of language, and do their own accounting (letting the owner choose among dozens of accounting, statistical, and other business reports, with little or no advance setup needed). Accounts themselves could know how to do many applications -- such as managing a fundraising contest or game. A clone of an account from a successful project can serve as a starting point for a new, similar project.
But our focus here is mass sponsorship, a new way for artists to sell bulk, prepaid downloads of digital work to sponsors -- making music, videos, etc. free and registration-free for the end users, while the artists still gets paid. Sponsors (anyone) can buy prepaid downloads of a particular work they care about, in bulk -- dozens, hundreds, or thousands of downloads or streamings at a time. Then a sponsor can use a special URL to send his, her, or its own short message (commercial, political, personal, or other) to large audiences they could not reach in any other way.
How to make replicating accounts work in practice is not immediately obvious. Here is one way to do it.
The most important single idea for making RepliCounts practical is "public accounts" -- described in (3), below. The most important single application of RepliCounts (at least for us) is mass sponsorship for artists to get paid for digital work online -- described in (4), below.
Note our 650-word introduction at www.replicounts.org.
The well-known numbered Swiss bank accounts are identified by a large random number (or other code word) only. You could be anybody (at least traditionally), and if you brought that code in, you could take the money out. (These accounts still exist, but they can no longer be anonymous, as Swiss banks can be legally compelled to reveal who the owner is.) No separate password is needed to authorize access to the account, just the single code.
We decided to use this password-less system for RepliCounts, mainly for two reasons:
For now, the default account name created by the RepliCounts server is a large random number -- exactly 40 digits, never beginning with zero. We chose this format because 2 to the 39th power provides over 128 bits of security, considered adequate today -- and '40' is easier to remember and discuss than '39'. We used digits only because they are the same in all languages. Not allowing any leading zeros (to avoid user confusion) subtracts exactly 10% of the names available. (Note that an account's default 40-digit number is really a 40-character name, since these random numbers do not use arithmetic, sequence, or any other properties of numbers.)
Forty digits is a large number. The account owner will almost certainly have the only copy of this 40-digit name that exists anywhere on Earth (and probably anywhere throughout all known galaxies, as simple computations suggest, assuming an average of no more than a million human populations of number-using creatures per galaxy). The server that generated the number will keep only a hash of it -- after using SSL (which is good enough for bank cards) to send the number only once ever to the account owner. The owner can then use SSL to send the un-hashed number to the server, when necessary to authenticate access to the account.
Of course 40-digit numbers are not convenient for everyday use. So the account owner will be able to create other names (aliases), of any reasonable length, and using any reasonable Unicode characters. (Our current plan is to allow an alias length of at least three and no more than 100 characters, and not allow non-printing characters in the account name. We suggest having a maximum length, to close off certain opportunities for malware.) An account owner can decide how long an alias name to use, depending on how much security the owner needs for that account; longer, more random sequences are more secure, but also less convenient.
Note: we expect only about 2% of all RepliCounts users to ever create a new account (an example might be a band that wants to sell its songs online, using mass sponsorship). The rest will use accounts created by others -- and not experience any difference from ordinary browsing on the Web. So we expect that about 98% of users of RepliCounts may never hear about RepliCounts, never need to know that any such thing exists -- an advantage for early adoption of the system, since the learning curve for most users is zero.
For those who do create an account, the process is as follows. First, an artist or whoever wants to start an account will visit a server (such as our demo at www.RepliCounts.COM -- currently this demo runs but is not ready for practical use). That site contains an empty box in which an account number or other name can be entered.
To create a new account, the artist or whoever just leaves the box blank, and clicks on the associated button. That one click creates the new account, and returns its 40-digit name to the artist. One click, done -- and this is for the 1% or so of RepliCounts users who actually create a new account.
Account creation leaves the creator authenticated (logged in), and at the owner's dashboard (explained below) of the new account. The owner can now start managing the account -- such as creating one or more aliases, or uploading a song, video, or other art, along with price and other information.
At any time later, the artist or other account owner can get back to the dashboard by visiting the server again (www.RepliCounts.com for example), but this time entering the 40-digit account name (or an alias) into the box, instead of leaving the box empty to request a new account.
Our recommendation is that the account owner create an alias, then save the only copy of the 40-digit account name in an office safe or a hiding place, and use the alias for everyday account management. Then if a account is lost or stolen, the owner can use the 40-digit name to regain access -- and delete any aliases if necessary, to lock out unauthorized users.
But note that the owner remains free to ignore the 40-digit name entirely, and instead create an alias with higher priority [explained later] than any other alias, and use it for emergency access to a lost or stolen account. This helps with the practical problem that many laser and probably some other printers forever keep a copy of everything they print -- while copying a 40-digit number by hand can easily lead to errors. This issue illustrates an operational problem with the end of privacy, and the hollowing out of any personal sphere or rights that official or other predators are required or inclined to respect.
RepliCounts allows an account owner to extend the hierarchy of aliases (and/or a superior hierarchy of 40-digit account names) to any practical depth. Therefore an account owner can give master access to an account to somebody else, to keep a business or other project going in case the account owner and all of his or her access names are wiped out -- yet take back control if necessary by keeping a superior master, in case a falling out happens before a wiping out (the more usual case, thankfully).
All these account names up and down the password hierarchies give the same access to the same data; the only difference is that in case of a potential dispute, there is a one-way hierarchy of which name can revoke the other. This kind of password hierarchy should be much more commonly available than it is (note that "hierarchical passwords" usually means something else, letting some users have different views and access to the data than others).
Also, by using replicating accounts instead of ordinary passwords, a "password" can have an expiration time and maximum number of uses, and keep a record of how it is used.
RepliCounts will not require any use of email. So what can be done for the common situation where a user loses access to an account, and conventionally clicks a "forgot password" link to be emailed instructions to reset the password?
The answer is that nothing can be done -- but this isn't a problem. RepliCounts allows users to create a "password" hierarchy of any depth -- in fact two or more of them, since the 40-digit number and the aliases can each have a separate hierarchy (with access codes anywhere in the former hierarchy always having priority over any codes in the latter). If the alias is lost it can always be re-set by the 40-digit number (or any member of its hierarchy); if the 40-digit number is lost (but not stolen), the alias still works, and can even create an effective substitute for the lost 40-digit code. If all access is lost then the owner is out of luck; the account is forever inaccessible. But the owner has plenty control to prevent this from happening (by having various aliases in different places, for example). And the RepliCounts documentation and defaults will help the owner make sure that any account that would be costly to lose is well protected against becoming inaccessible.
Aliases, like the default 40-digit account names, are only saved in hashed form in the server.
This system is more secure than the conventional one, where an attacker with surreptitious access to the owner's email might use the reset instructions to change the password, then change the email address. Also, this RepliCounts system lets an account owner get the account back even after it has been stolen, by using a high-level alias, higher than the one stolen. In many situations this recovery could be important, even after any money in the account had been drained. And the retrieved account could record how and where the stolen money had been spent.
The great limitation of the numbered-bank-account system is that it cannot be used to do business with third parties. Obviously the account's secret number (or other access code) cannot be given to an untrusted third party, since it gives full access to the account, including all its money. But account replication allows a new way to bypass this problem.
"Public accounts" are RepliCounts created with an irrevocable option, so that they can never give out money (though they can take money in -- and then money does not stay in the public account, but goes into its parent account, or other account designated by the parent's owner). While they can never give out money, public accounts can give out valuable digital content. And they can keep count of how many copies remain of those they have been paid for (and therefore know if they can currently give out any free downloads or streamings), and other information as well.
Also, most public accounts will have names that can be used as part of a URL. This restricts the account name in some ways -- for example, the name cannot include a space.
The reason for offering public accounts is that can be distributed widely -- even published, although the owner might choose to distribute it only within a certain group (such as students in a class -- or anyone in certain social networks, friends, their friends, etc).
For example, a band might create it's first account, which will have a 40-digit name, such as:
2970146448502393250078498309013043701524
For day-to-day management of the account, the band could create a shorter name (an alias), such as:
ManageOurSong
Capitalization is ignored and doesn't matter, in the entire RepliCounts system. The band can make this account name as long and complex as it wanted (up to 100 characters, currently) -- probably depending on how much money, reputation, or other assets it may contain.
The account
2970146448502393250078498309013043701524
can produce as many different public accounts as the band wants. Usually the band will choose its public-account names to be usable in a URL, for example:
www.replicounts.com/GreenTrees2012
where the part before the slash addresses the server where this account exists, and the part after the slash can be whatever the artists want it to be -- in this example it may represent the song title and publication year.
Sponsors [described later] who choose to put their money into a new public account that they ask the server to create (instead of into an existing public account) can change the last part of the name. The artists can restrict this ability if they want; in the above example, they might require that the first 11 characters of any sponsor's public-account name for that song be:
'GreenTrees-'.
Our proposed mass sponsorship is just one of endless possible applications of RepliCounts.
Mass sponsorship is a way of distributing digital art that combines advantages of free and paid. The idea is to sell the art to sponsors (anyone), who might buy hundreds of copies of the art in the form of a clickable smart link. The smart link will keep count of how many copies are left, and provide that many free copies to the first people who click the URL and then choose to download a copy. The same public dashboard reached by anyone who clicks the link might also include a highlights/trailer/free sample, so that even if all the prepaid copies have been used, visitors can still see or hear some of the art, and decide if they want it enough to pay for a copy, or to sponsor many copies at a reduced per-copy price. Any sponsor can also provide his, her, or its message to anyone who receives a copy that sponsor paid for; the message could be delivered non-intrusively, and be required to be fairly short (e.g. 700 characters maximum, equal to five tweets). The artists will be able to set the maximum message length; often it should be longer than an Adwords or a tweet, since many sponsors will not have a Web link to include.
The sponsor can distribute the link through any social networks desired. Whoever receives it can then pass it on. Anyone who clicks the link will also be offered the opportunity to buy more sponsorship if they want (regardless of whether or not free (prepaid) copies are currently available).
Unlike ordinary advertising, with mass sponsorship the free downloads stop once all sponsorship in that link has been used up. But anyone in the world who can pay online and has the smart link (or can find its address) can buy more sponsorship at any time -- instantly reviving all copies of that link around the world. This system therefore creates a new motive for buying more sponsorship and supporting the artist -- play the hero, building gratitude for your message. For additional motives, see archive/archive2007/index2007-03-22.html#incentives.
RepliCounts and mass sponsorship are also very low-bandwidth and efficient. Since this project is free and open-source, different organizations providing mass sponsorship will be competing with each other, so almost all of the money paid by sponsors will likely go to the artists -- perhaps 98% or more. (Re bandwidth efficiency, see Affinity99.org, an offshoot of the RepliCounts project. It loads a page of text over a poor connection faster than most sites will return anything, even an empty Google search box. You can bookmark this address to quickly test the wi-fi network at coffeehouses, etc.)
To continue the example above, suppose that GreenTrees is an artist's freedom song. Someone likes it, visits www.replicounts.com/GreenTrees, and checks the prices for sponsorship. Suppose the price scale allows sponsorship of 200 copies at 40 cents each, or $80. The sponsor sets a name for a new smart link -- assume it is:
www.replicounts.com/GreenTrees-HandsOffJulian
and pays $80, using a credit card or any other convenient payment method (we will probably start with a conventional shopping cart, and add other payment methods such as Dwolla and Bitcoin later).
Then the sponsor sends the smart link to interested people, by email, and/or publishing it in blogs, in comments, or through Facebook, Twitter, etc., or even in a newspaper. At least the first 200 who click the link and download the song will get it free.
But probably many more will get free copies as a result of the sponsorship, and the artists and/or the cause will get more than $80, because those 200 people will also have a chance to add their own sponsorship to the link. One smart link will be able to handle any practical number of sponsorships simultaneously (we will set a maximum, only to help defend against malware).
Note that these links need never expire, even if empty; as long as sponsors are found, they will circulate indefinitely through social networks, paying artists as they go. And this social-network circulation can locate new pockets of interest, unsuspected by the artists or their marketers, as sponsors and end users in potentially endless chains keep sending the smart link to friends and associates likely to care about the particular song, video, journalism, or other art that link provides.
Anyone can easily change the language of the link, for distribution in China, for example. The language change could also change the default payment methods offered (to be more appropriate for China), or these might be changed separately. The language for instructions on how to make the payment will also change similarly. Whatever these settings, new sponsors who choose to make their own new links will inherit the settings, and then can change them, to make the link they distribute most suitable for their social networks. Any end user can also change the language of the link they receive; this change only affects their copy and other copies they circulate. The same song can be sold this way simultaneously through multiple different links, multiple copies of each link, and all the different language supported for payment instructions by the particular RepliCounts system.
What about "pirate" or unauthorized copies? RepliCounts does not use DRM (digital rights management, meaning copy restriction) -- but does not forbid it either. That's up to the artists.
However, if enough sponsors can be found, then pirate copies that do not pay the artist will have to compete against equally free legitimate copies that do -- which fans of the artist will usually prefer. This is different from commercial content distribution today. The main incentive for piracy (not being left out among your friends) is gone -- since no one is left out for financial reasons, including children, persons in poor or restricted countries, and others who cannot spend any money at all online.
Will there be enough sponsors? Only time will tell. But in the example above, a sponsorship of 200 copies for $80, only one such sponsor would pay for 199 users, meaning that only half a percent of users need to be sponsors at that level. It is likely more than one in 200 who believe in the cause, or the artists, or the music, will have the money to spare.
Why would sponsors pay for music, etc. downloads to be used by others? Here are some possible reasons, in no particular order:
Also, the artists can use the price per download to help balance the sponsors vs. free end users. A lower price is more attractive to sponsors (get your message to more people for the same money, likely increasing sponsorship), and also the same money in sponsorships reaches more free end users at the lower price. Of course a price increase must not affect the prepaid copies already sold at the lower price; however, a price decrease could affect sponsorships already purchased (by simply adding more copies to them), instantly helping to correct for too little sponsorship, avoiding imbalance so that the system keeps running smoothly.
The owner's dashboard is where the owner controls the account. When RepliCounts is used for mass sponsorship, for example, the account owner (often the band or other artists) will use the owner's dashboard to upload their artwork, set bulk-price schedules, request accounting and statistical reports, change the look and feel of the public interaction, and more. Each account may have hundreds of different possible settings -- which are usually inherited from parent to child account when the parent reproduces.
In mass sponsorship, each account normally distributes only one song, video, news report, or other work. When the artists have another work to distribute, they start a new account for it. This lets a sponsor pay for a particular work that may move him or her, or attract an audience he, she, or it wants to reach.
The much more limited public dashboard (used in mass sponsorship and some other RepliCounts applications) is what anyone sees when they click a smart link. For example, there may be a large green button to download (or stream) a song, provided that paid sponsorships are available in the particular smart link that was clicked. Otherwise, a small red notice might say that no free copies are currently available. The visitor could buy one copy, buy a sponsorship at a reduced per-copy price, or just come back later for a free copy when someone else in the world who has the same smart link may have purchased a sponsorship, and it may happen to have at least one free copy remaining.
This section needs its own writeup (or maybe a book). Meanwhile note:
Until we rewrite the full documentation, here are some archived links to earlier writeups:
Page updated 2012-07-03.