Introduction and Summary

Figure 1: A Typical RepliCount

Click the image below, or click here, to see Figure 1, which explains the anatomy of a RepliCount, and the kinds of services it can offer.

Different services (the different ovals in this diagram, explained in Figure 1) will be used for different purposes, such as:

• downloading music;
• downloading video;
• accepting many different forms of payments;
• doing business in any human language that the server supports (allowing any user to change the business language for a particular account, and then distribute any number of copies of the account in that language -- while the same account continues to do business in various other languages simultaneously, for other users);
• tracking demand for the content;
• providing accounting, Web metrics, and other reports to the owner (and also provide the owner's choice of reports, if any, to the public);
• interacting with the public (to sell sponsorships, provide free downloads, show data graphically or musically, or for other purposes);
• or making automatic payments (to charities, marketers, tax authorities, etc.) as sponsorship sales become final.

Some of the later diagrams (Figure 2, etc.) will represent each RepliCount as a much smaller circle. This is simply to show many accounts conveniently on the same page, in order to illustrate relationships. The size of the circle has nothing to do with the amount of money the account contains, or anything else.

Figure 1 Bottom Line

Figure 1 illustrates the flexibility of a RepliCount, which can contain far more services, owner-changeable options, automatic actions, and other capabilities than conventional financial accounts, online or off. As we will see, such accounts can circulate publicly (providing whatever access the owner chooses to provide to the public) -- making certain new business models much easier than otherwise (including the mass sponsorship for artists and other content creators, which we describe).

Account replication manages complexity well, by allowing new accounts to be "born" without effort, with almost any amount of complexity already set up and ready to use.

Replication also allows an endless supply of new accounts -- as many as the owner wants. Therefore, each song, etc. can have its own RepliCount, and anyone who has a copy of its smart URL can make more copies and send them to others -- creating a unique social network for that song. (The network is defined by whoever has the smart URL, the publicly circulating name of the account, which anyone can share with anyone else by email, Facebook, or other Social Networks. (We capitalize the overused phrase here to show that these social networks are proprietary brands, often walled corporate gardens -- distinguished from the natural social networks that develop among friends and associates, who might share the same smart URL with each other, through Social Networks, email, short messages by telephone, publishing it in a newspaper, or in any other way. (Smart URLs will usually be short, so they will fit in Twitter or SMS messages without needing to be shortened by Bit.ly, TinyURL, etc. -- a security advantage.)

Also, the huge supply of accounts opens doors to new approaches to security, with accounts deliberately crippled by specialized security restrictions -- such as accounts that can never pay money to anyone, or which vanish forever after one transaction, or which have only a small amount of money (such as $5), and may also be restricted to a single payee, or a short list of payees, and/or may self-destruct on a certain date, automatically returning any remaining money according to instructions of the owner.

Spam Control

For example, $5 single-payee RepliCount could be used for spam control, as we will explain later. An unencrypted account could be pasted into emails to pay the recipient 5 cents to receive the email and maybe look at it -- a price that would stop almost all untargeted spam. The person who bought the $5 account could then send 100 emails, typically to public email addresses posted by experts, celebrities, or others that today must stay hard to reach. And if criminals harvested the account (while it travels through unencrypted email, or is sent to a fake celebrity address), they could never get more than $5 out of it -- and could only get that in the form of allowing their spam to go through, at a single forwarding service. But as soon as recipients complain of the spam, or complain of a fake celebrity address, the service will suspend the account, and send a new name to the owner who paid for it, instantly cutting off more spam, while the legitimate owner can still send email normally. Also, the owner could have the account self-destruct at a secret time, or tell it to self-destruct immediately and just start using a new name then; no need to coordinate with user's email recipients or anyone else, since the mail goes through as long as the recipients get their 5 cents, and they don't care what code pays it. The owner could also have the server send a new code (a new account name) for the same account every day, or every hour -- and then just use the most recent one to send any email, making it even harder for the spammers.

There are always tradeoffs between convenience and security. This is just one example of how an endless, easy supply of oddly specialized accounts, simple to use though of any internal complexity desired, will open doors to new tradeoffs, with important practical results.

Illustrations

People find the idea of account replication confusing -- but only because it has never been done before. Thousands of years of handling money only in one way (non-reproducing accounts) leaves deep ruts. But the basic idea is simple. You picture a replicating account on the server as one entry in a large database table; this entry has many separate fields (and complex data structures when needed), for all the parameters and other data needed by all the services and capabilities offered by this account. The database itself may manage thousands or even millions of accounts, each with its separate entry in the table.

Then account replication and inheritance consists mainly of making another copy of the account in the database. Of course the copy needs some changes -- a new, unique name, for example, and either 0 for the amount of money it holds, or an amount (specified by the owner) that is inherited from the parent.

Pictures may help, so we used OmniGraffle software to generate the diagrams on this site.

Technical: What's New Here?

In thousands of years' history of money, no financial account ever could reproduce and inherit in this way. No such account could have possibly have worked before computers and e-commerce. And we have not found any modern examples, despite considerable looking (of course we might have missed some).

The new "children" accounts can inherit money from the parent. But much more importantly, they can inherit any number of settings, services, and automatic actions. This setup is effortless, instantaneous at the birth of each new account. Therefore these accounts can manage far more information and capabilities than ordinary (non-replicating) online accounts -- since the work of manually setting up many such accounts would be prohibitive. Note that a single account can include know-how from many human owners of different generations of its ancestors.

Owners can easily open many new RepliCounts in a day -- and/or close them forever, or let them close themselves. This flexibility makes new security approaches feasible, allowing new tradeoffs between security and convenience.

Also note that these accounts will likely evolve through everyday grassroots use, as those that work best for people are most likely to become popular, and therefore reproduce and spread.

Many, probably most, account actions will happen automatically, with no need for any human attention or awareness. Yet account owners will retain ultimate control and responsibility. Account replication, inheritance, and evolution will let people manage complexity more easily. And they will allow customized financial infrastructures to be re-used easily for many different purposes, without need for reprogramming.

Some of the modular account services (the ovals shown in figure 1) may be substitutes for ordinary applications (the services that we labeled in figure 1 are not examples of this; instead they are functions needed to make the RepliCounts system work). This way, the account can join the operating system and the browser as a platform for applications. The advantage of using the account platform is that it already has necessary money functions integrally built in -- unlike most operating systems and browsers. Using a common financial infrastructure will allow different applications to communicate financially with each other.

Status 2009-12-15

The RepliCounts design is ready to go. Sorry, no software yet. I'm hoping to find or assemble a team to develop an open-source proof of principle system, good enough for people to test, and actually use with small amounts of money.

It will easier than it looks. Note that no software whatever needs to be written for all the different browsers and operating system out there (well, maybe a different display for very small screens on mobile phones will be worth doing). Also, the account replication (which is the heart of this system) consists mainly of copying a record -- requiring not that much more than one instruction. Disk storage is manageable; a fixed-length 1 kilobyte per account should be plenty for a proof-of-principle system at least, meaning that a million separate accounts will only take 1 gigabyte of space. Expand that to 2 or 3 GB and you can use a sparse file allowing very fast hashed access for up to perhaps half a million or more accounts. For security, the actual account names will never be stored on the server, only a hashed (and encrypted) version of the name, as is done for credit cards, etc. This workhorse of the system, the accessing and changing of accounts, is designed to use classical programming methods -- usually avoiding the overhead of relational databases. It should be extremely efficient -- unnecessary for the proof of principle, but important later on for handling heavy traffic.

About this site: The other pages linked from the navigation bar above are accurate, but they are older or incomplete. We are revising them now. The archived pages (with "archive" in the URL) are historical; they can be incompatible with the current RepliCounts design, and will not be rewritten.

Page updated 2009-12-19