• Home
• Mass Sponsorship
• More Examples
• How It Works
• Alternative Money Search
• About This Site

How RepliCounts Works

This page covers lots of information, for someone who wants to know about the internal workings of RepliCounts. Others can skip this entire section.

Background Details

New accounts can be "born" with the ability to accept many forms of payment, manage permissions, download content, save accounting and other transaction data and print various reports on demand, do business in the each user's choice of many different languages, send messages or publish information at a future date (and/or at the occurrence of other specified events, such as a war), and do many other application-type services within the account itself. For example, these accounts could automatically compute and pay taxes, commissions, royalties, charitable tie-ins, etc. -- immediately after sales become final, giving artists less paperwork to worry about. The infrastructure for these and other services need be developed only once, and then can be inherited by thousands of accounts, used in hundreds of different businesses or projects. (There are also non-financial uses of RepliCounts, which do not involve money.)

Each new account will inherit most settings of its parent; the new account's owner need only enter the new or changed information. To minimize the changes, artists (for example) could get a starting RepliCount from other artists who had used its parent for doing similar business -- or from a commercial service that sets up starting accounts for artists in various business situations.

Account owners will use a dashboard (control center) to make changes to the information in their account. (However, certain security settings will be binding on all descendants of that particular account. Otherwise an account owner (or someone who stole owner's access) could evade many restrictions, by creating children accounts without them.)

Important: special public accounts are RepliCounts that can only take money in (and deliver it to a secret destination, usually another RepliCount); public accounts are born with the restriction that they can never give any money out. They can give out valuable content, however, and perform other services. Often the artists, sponsors, and anyone can share public accounts widely, or even publish them online or elsewhere for anyone to use. Public accounts will usually appear in a clickable form, as a smart URL; an example of a smart URL is the RepliCount noted above which distributes a song, www.automatic-accounts.com/OurBand/OurSong. Each public account will have a (usually minimal) public dashboard, reached by clicking on the account, which allows the public to interact in ways the account owner chose to allow.

Here's how it will work in practice:

• For mass sponsorship at least, most people will only interact with public accounts, and never see any other kind of RepliCount (the account names will normally be kept secret by the account owners);
• Public accounts will usually be clickable (for example, www.automatic-accounts.com/OurBand/OurSong -- where OurBand is the account name the artist(s) signed up for, and OurSong is the title of the work, or whatever else the artist(s) choose;
• Clicking the public account will display a public dashboard. For example, it may include a big green button if any prepaid copies are currently available in that account, with the button small and grayed out if no prepaid copies are currently remaining);
• Note that usually a public account will only deliver a single song or other work (or possibly an album, or a choice among several works). To distribute a different song or other work, the artists will create a different public account;

The non-public (and usually secret) kind of RepliCount might look like this: 639373597628118 -- a random number selected by the server that manages the brand of RepliCounts. Fifteen digits is enough that even if everybody in the world had 10 RepliCounts (and usually an artist or a band would only need one, while most people who use RepliCounts would need none at all), the chance of a random guess hitting any one of them would be less than 1 in 10,000. Only the server will know which account names (numbers, in this case) are correct -- and the server can certainly make it difficult to submit thousands of guesses. In addition, even a correct guess would reach an unknown, random account, which usually will not have any money or other value accessible to the stranger that found it (see Security, below). The non-public RepliCount will not normally be clickable, since it would be insecure to access it that way; instead, the owner will usually be using only a single server (a single brand of RepliCounts), and can easily remember it. The owner controls the account by visiting the server's home page or other Web page provided, and entering the account name (number) in a box provided, for secure SSL communication with the server.

The owner can also use the control center to set any confidential information in the account to not be inherited by any children accounts.

Once created (by the owner of the parent account), each new account is independent of its parent, and can be used by the owner, or sold or given to others. The parent account has no further control -- unless the account owner who requested the replication set that up for special purposes, in which case the server will always disclose it. Anyone who buys or otherwise receives a RepliCount can know for sure if the parent account has any further involvement -- and normally would not use a RepliCount with any parental management under a different party's control.

Security

Look Ma, No Passwords!

We made a design choice not to have passwords at all in the basic RepliCounts system (however, they can be available among the dozens or hundreds of potential services of the account, and requested for additional security). Instead of passwords, the secret name of a (non-public) RepliCount also serves as the password. This is the system used in the traditional Swiss numbered bank accounts; if you have the secret number, you can take money out. The usual drawback of this system is that while the account can hold money for its owner, the secret name cannot be given out to anyone else, so the account cannot be referenced or used for general commerce, only for transactions between its owner and the bank.

But RepliCounts can reproduce. So the owner, using the secret account name (usually a number, for international convenience) can use the dashboard to request replication to create a new "child" account that is a public account (meaning it can receive money, but never give any out). By default, every public account will deposit any money it receives in its (secret) parent account; only the account owner and the server will know the destination, and the server at least will never give it out. Basically, the public account serves as a public face for the secret account; it can circulate, allowing general commerce. Anyone can us it to pay the account owner.

This is a legitimate use of the parent account maintaining some management capability over the child.

We could have chosen otherwise and used the ordinary account-password system -- and other designers may choose that route. However, when new accounts are regularly being created (sometimes by the hundreds or even more, with a single command), managing all those passwords would be a hassle. Since account replication provides an alternative road to general commerce, we decided to use that instead.

Conventional Security

The server will never run any unknown third-party software, or spend money without receiving an encrypted authorization. It will keep an audit trail of course, and use SSL, hashing, and other standard security as needed.

Unconventional Security

Also, easy replication opens doors to new security options. For instance, RepliCounts can use security restrictions that would be intolerable for ordinary (non-reproducing) accounts. For example, an account could be hard-wired to handle no more than $5.47 in its entire life -- not much incentive for theft, but enough to send over 100 emails through spam control at 5 cents each (see Examples, below). Or an account could have a single, hard-wired payee, or secret list of payees, or secret time limitations, or secret reporting or approval options. Or it could self-destruct after its first and only purchase -- again discouraging theft, since the account might only exist for seconds and then be gone forever. Accounts could self-destruct under any number of conditions, automatically returning any remaining funds to the owner through a hardwired (unchangeable) secret destination -- allowing retrieval of money from lost accounts, for example, since they could expire on a certain date, and/or after a certain period of inactivity. Such tools will allow accounts with money in them to be sent easily, by unencrypted email or other unprotected means. Usually only the recipient will have the context or knowledge needed to use the monetary value in the account.

Hierarchical Passwords (Using Account Names)

Hierarchical passwords to any depth will protect against accidental loss of account credentials (no need for an email address to restore lost access) -- and also allow full owners' privileges to be shared with others, subject to later withdrawal if necessary. Hierarchical passwords should be used much more widely in general software. It means that a master password can reset or otherwise control a collection of passwords (or just one). And one or more master passwords can have a master-master password as well -- and this hierarchy can be repeated to any depth. We have not seen full hierarchical passwords in software, but they must be in use, since the idea is obvious.

Hierarchical passwords could have many of uses. For example, one party (A) could give B master access to accounts for use only in event of A's death or disability -- while keeping a master-master, to revoke B's access in case of abuse. If A's plane crashes and all A's passwords are lost (including the master-master), then B will have ultimate access to the accounts, as intended. Or anyone can have a master password controlling some or all of their other passwords, and lock the only copy on Earth in a safe, for emergency use only -- to restore access in case an everyday password gets lost. The server will not have a copy of any of these passwords (they are actually RepliCount names), only a hashed (encrypted) version. If the safe is destroyed, no problem; the everyday passwords still work, and a new master could be created. If the safe is stolen, then hopefully the owner also created a master-master password hidden somewhere, which can revoke or change the master password, making the stolen one useless. Someone else finding the hidden password accidentally probably could not use it -- especially if it required a PIN that would kill the account after some secret number of wrong guesses. (Killing the account will return any money to a secret destination that the account owner set up.)

Since RepliCounts does not include any passwords in its design, the hierarchical password functionality can be achieved by master accounts instead of master passwords. All RepliCounts will have the ability to manage access to other RepliCounts belonging to the same owner. The account names will be secret, and serve as the passwords. Therefore "master" RepliCounts are not different from any other; the "master" concept only has meaning for a relationship between two or more accounts. And any depth of hierarchy of master accounts can be created.

Other Protections

In practice, most owners will only use non-public RepliCounts to receive money, not spend it (in two of the three examples below, for instance). Revenue will enter through standard e-commerce payments, and instantly credit the account owner and/or others. Owners could get money out by having their account send checks automatically under certain conditions, e.g. monthly if the amount is above a specified minimum -- or by EFT or other electronic means. They could also spend the money directly from the RepliCount, to pay other RepliCounts, or any payee who chooses to set up a RepliCount for this purpose.

And as noted above special "public" accounts will be hardwired so that they can take money in, but never give any money out (except through the owner's secret destination). They can give out valuable content -- but there is little incentive for someone to steal, say, 500 identical copies of a file. Usually public accounts can be openly shared with anyone, even if they have collected substantial payments. We suspect that in practice the great majority (maybe 95% or more) of RepliCounts in circulation will be these public accounts, which carry little if any security risk. Usually they will be in clickable form, as a "smart URL." One click takes users to whatever environment the account owner wanted to set up, for doing business with the public.

Ultimately, the management (the organization that runs the server) must maintain public trust. Artists will tell their sponsors (who can be anybody) to pay them only through the domain they are using to distribute their work, not other domains that could have fraudulent accounts pretending to belong to the artists. And the management will continually guard against fraud (such as "typo squatting," using an account name that looks like a legitimate account to fraudulently sell the artist's work).

Note that only the sponsors (who put money in) need to be concerned about paying into a fraudulent account. We guesstimate that 98% of users will pay nothing, since they will only download sponsored content -- greatly reducing the security problem.

---

[draft] Technical

Using Multiple Languages

1. Without Machine Translation

Many Web sites and other software already work in multiple languages. For example, in Macintosh OSX 10.5 you have a choice of 18 languages in which system prompts will appear (under the "International" system preferences), and some applications will also use the language you select. This works well without machine translation, because the universe of commands required to run the operating system is fairly small and unambiguous.

Some considerations in applying this to RepliCounts:

First, a "public account" in RepliCounts is likely to be used by many people around the world, sometimes simultaneously. Therefore, it should not remember its current language setting. The language needs to be remembered for each use of the account. A handy way of doing this would is to use conventional short abbreviations for languages, such as en (English), es (Spanish), or zh-Hans (Simplified Chinese) -- right in the smart URL, replacing the www.

For example, under the Artists tab on this website, we used an example of a clickable public account: www.automatic-accounts.com/OurBand/OurSong. Anyone can click on such a link (a smart URL) to get a free copy of the song, video, report, or other content it delivers, provided that any paid sponsorships are currently available in that RepliCount. Then, to convert this link to work in French, for example, just replace the 'www' with 'fr', getting fr.automatic-accounts.com/OurBand/OurSong. End users might do this simply by clicking a French flag or other link at the account's public control center.

The new link still goes to the same RepliCount; the server processing this account has access to the language prefix, so it can set the language to French for this particular transaction (and to any future transactions caused by clicking on the new URL with the 'fr'). Users will then see French phrases for the limited set of standard meanings that a sponsor or end user needs to operate the RepliCounts system -- meanings like "click here for free download", "click here to sponsor bulk copies", "shopping cart" (within the "sponsor" page), etc. The "www" could simply default to whatever language the RepliCounts system was written in -- so that a simplified RepliCounts system (perhaps for testing) could use only one language, and ignore the issue entirely.

Probably about 100 meanings in the language table would be enough for people to navigate the RepliCounts system: doing free downloads, sponsorships, credit-card payments, uploading art when creating a RepliCount to deliver it, printing basic accounting reports with proper labels, etc. More meanings could be added to cover other specialized uses of RepliCounts (such as fundraising), which need not be supported by all RepliCounts servers. The server will need a table giving all these supported meanings in all the supported languages. Note that this way of using just one account for all the supported languages, and specifying the current language in the smart URL (Web link) itself, means that copies of the link set to any supported language can now be shared within a country (within a single language group), with no attention to language until one of the users needs to change the it again, in order to send the Smart URL to someone who speaks a different language. The clickable flags in the public control center should always be visible there, to let anybody change the language very easily.

Note that error and other messages from shopping-cart or other bankcard software will not need to be translated, since sponsors and others who are making payments to a RepliCount can be directed to a shopping cart in their own language.

Technical: We should mention that allowing multiple access to the same account, using either the same or different languages, will be considerably easier to implement in software than it may seem -- since the big problem of multiple transactions changing the same database record simultaneously can largely be sidestepped. Multiple simultaneous accesses will only be allowed for public accounts -- that is, for the greatly simplified control center (dashboard) provided for public use. Public users will be able to make very limited changes -- for example, to decrement the count of free downloads remaining within a certain sponsorship (by obtaining a free download), or to create a new sponsorship when paying for it. In each case, the RepliCounts record will be locked against changes for the microsecond or so required to subtract 1 from the free-copy count, or for the millisecond at most required to write out the new sponsorship record, after it has been created. No other transaction will need to wait very long in the queue.

Meanwhile, the other RepliCounts (that are not public accounts) will be used very differently; they will only be changed by the owner, or an authorized agent of the owner. Therefore there is no need to allow simultaneous transactions at all for these accounts.

A little programming thought will be needed to allow the owner of a public account to go in through the back door and make changes, while the account is live in public use. At worst, the public could be locked out when the owner is making changes. But this may not be necessary, because there will be so few changes that the public is allowed to make to these accounts. It should not be hard to avoid conflicts where changes are partially made, then erroneously overwritten.

2. With Machine Translation

Sometimes the method above for supporting multiple languages will be impossible or clearly unsuitable. For example, to allow multi-language access to a sponsor's personal message would require the sponsor to get translations of his or her message into all supported languages that sponsor chooses to provide. And for content, while songs seldom need translation, someone providing, say, investigative news reporting could hardly be expected to get it translated into a dozen or so languages.

For these purposes machine translation is needed. Fortunately, the field seems to be advancing rapidly at this time. Google has developed its own new statistical machine translation, now available as Google Translate, which already seems to work at least as well as the classical rule-based translation (available in Yahoo! Babel Fish, for example) -- even though Google's system is at a much earlier stage of development. Google Translate has largely caught on in the technical world. In seconds you can translate any page of this site into more than 30 different languages, just by using the Google Translate box near the upper right of each page.

Our question now is how to write content in ways to help Google Translate do the best job. We are looking for a simple set of rules for the writer -- and also for some way to enter a table of translated words and phrases for key concepts in a technical field that Google Translate may not yet be familiar with. If you have information on these questions, please let us know.

Other

This section is a work in progress. The page below is mainly text removed from other pages on this site. We will organize it better in the future.

[Advanced: a subtle point here is that though the name of a RepliCount looks like a URL, and sometimes is called a smart URL that can even can be clicked and then acts like a URL, it is not really a URL. Instead, we just borrowed the standard URL format for RepliCounts because so much Web software, email software, etc. is familiar with that format, and knows how to pass it along without choking on it, such as getting confused by certain special characters it may contain. In the example we develop below, only the www.server.com part is a real URL; the rest of the name is simply copied and used as data by the RepliCounts site. What looks like a directory structure in the name might sometimes correspond to a real directory, but usually it will not. And in the case of a language code, like en.server.com... or es.server.com..., it just comes in as a field to tell the account which supported language to use when it instructs the user on how to enter payments, how many free copies are available, how much it costs to sponsor N copies, or the few other instructions for using this system that have been entered at the server in every supported language. In case the language code is invalid, the server will give the user an error message in every supported language, plus the correct code for that language. Note that while RepliCounts will probably use the same two-letter codes, this is different from Wikipedia, for example -- where the English, Spanish, and other language codes take users to different encyclopedias for each different language. A RepliCount smart URL en.server.com... or es.server.com... is the same account, delivering the same art, and holding the same sponsorships -- allowing users to change the language at will, and distribute the smart URL that way among friends who speak the same language, but anyone can change it when a copy crosses a language barrier again.]

Re Spam Control

For selling art online, we highlighted "public accounts" (accounts irrevocably restricted so that they can never give any money out, allowing these accounts to be widely shared). But in our spam-control example, the concept of public accounts does not appear at all. Instead, the RepliCounts used can pay money, but are restricted in other ways, such as only paying for email, and having too little money in them to be worth stealing. So these accounts can also be emailed conveniently, without encryption.

Also, in the first example, the RepliCounts appeared in the form of a clickable URL; in the email example, a RepliCount was an 8-digit number (in a more general context, an identification of the server would be required as well -- perhaps a 3-letter combination could be used).

Many More Uses

What we have seen so far is just a sample of a huge range of new approaches to solving common problems, made feasible or at least much easier by reproducing accounts. These new methods will not solve the problems we face, but can be helpful when used together with more familiar and conventional approaches. For example, the mass sponsorship we propose will not save newspapers, but could provide an income stream by funding some investigative reporting delivered online. One possible business model here might be to find investors for a particular investigative article; the investors could put up the early money and profit if the story is a hit (getting possibly millions of video viewings, say, free to end users only when sponsors who appreciated the story had paid, say, 10 cents per view). The sponsors could give the access they fund to any of thousands of different audiences the sponsors want to support -- or want to reach, and deliver their personal, cause, advertising, or whatever message to the chosen audiences. Or sponsors just interested in the story could release the prepaid copies they buy to anyone interested. If people have problems finding free downloads or views, then that's an incentive to find more sponsors who can buy hundreds or any number of copies in bulk. And it's also an incentive for potential sponsors to instantly turn on public access all over the world (or anywhere they choose), playing the hero and saving the day for the important story and for many interested readers, either anonymously and perhaps in support of a cause, or otherwise.

All this becomes possible because each new account can inherit services of almost any complexity, instantly and effortlessly. Family trees of accounts can grow over generations. Professionals and other experts can program the features -- but anybody can change their work (in most cases), or do similar setup. The accounts and features that prove useful will tend to become popular, and also provide a new basis for further changes -- allowing grassroots control of these financial instruments, which can provide endless other services as well, in an environment where financial infrastructure is always conveniently available for use.

The RepliCounts as we propose them will not contain computer code (a helpful barrier against malware), so they will not distribute software. Instead, along with data, they will distribute settings that basically choreograph hundreds of routines that already exist on the server that manages the accounts. The software can be changed only by the company that manages the server, which (for security purposes) might not allow remote programming at all. But the very flexible inheritance of potentially hundreds of services and settings (many of which will be unused for any particular account) does provide a platform for distribution of computer services. And new routines can be developed and added to the server at any time -- even added to accounts that are "live" in public use.

An important advantage of distributing computer service through accounts instead of through operating systems or browsers is that the accounts already know about money, such as how to accept various forms of payment in various major languages, how to apportion transactions among different payees, how to keep accounting information and prepare standard or other reports on demand, how to communicate with account owners by email or phone when necessary, how to arrange for the mailing of paper checks, how to charge for such services, and much more. Financial transactions and other functions can be automatic in many cases, based on options that account owners have chosen, or have allowed to be chosen for them by default -- avoiding much of the need to stop the process and do something different once money is involved, like having people reaching for credit cards or filling out forms online. Instead, people moved by a song or a cause can support it immediately, while the song still plays. Sending email for doing so is described above, but there are easier ways.

Page updated 2010-03-23