Ideas are cheap

Every so often I have a "good idea" that I know I will not have time to implement. This page is a place for me to describe these concepts in the hope that someone else will be inspired enough to take them further.

Stamp Server

Spam mail continues to be a serious overhead in doing business. Over the years a number of ways have been tried to remove it. Closing our email relays, blackhole lists and tagging message signatures have all been circumvented by the spammers. Bayesian filtering looks like a good technique at the moment but how long will it be before spammers find a way to defeat that?

The fact is there is only one way to stop spam, the spammer has to pay for mail delivery. There has to be a reasonable way to make the message sender pay for mail, then the strange econimics of spamming will break down and no one will send spam any more. But if the spammer pays doesn't that just make life more difficult for the rest of us? Not necessarily as we shall see.

What I am proposing is that every email comes with a "stamp" which costs real money. The difference between this "eStamp" and the one you get down the Post Office is that when you recieve an email with one of these it credits your account. This means that ordinary people, who get as much mail as they send, will end up having to pay (approximately) nothing while those that dispatch much more email than they receive will have to pay for the resources they are using.

The ammount that you pay to deliver an email need not be large. If for example the average charge is $0.01 per message then a spammer dispatching a million messages would have to pay $10,000. Any user that sends 100 messages and recieves 90 would have to pay $0.10.

A distributed set of "StampServers" could be set up which would hold user's accounts. Each user would pay say $5 to top up an account and every time an email is delivered the appropriate fraction of a cent would be transfered to the reciever's account.

Every stamp transfered would have to pay some "transaction cost" to fund the StampServer. Because all the interactions are internal the transaction costs could be set very low (for example $0.0001 per transaction would mean the customer would have to pay $1 to deal with 10000 email messages, however from the service provider's point of view a sigle system able to average 10 transactions a second over a year would generate more than $30,000 a year in revenue).

One critical element is that when you join up there can be no "free credit", otherwise spammers will just create thousands of new accounts.

With any such new proposal an obvious question is "how do we get there from here". In this case I think the answer is quite clear, once the StampServers are available users can continue to accept email without stamps but will arange to deliver these messages on a lower priority channel (for example into a different mailbox). Any emails which have stamps will naturally get more attention than those that don't. This will encourage users to adopt tools that make dealing with stamps easy. Once most people are using stamps on thier email they will find that they look at the "non stamped" emails less and less frequently until eventually they almost completely ignore it.

Another element that follows is that there must be the ability for a number of StampServers to compete (at least in the early days). This will allow different providers to charge different amounts for transactions and may be beneficial for dealing with different "home currencies". I would propose that the servers form a tree (like DNS) and that transaction costs are charged for every step from the payer's to payee's account. This ensures that everyone who runs a server gets the revenue they require, but may also encourage payer's and payee's to hold multiple accounts to reduce transaction costs.

Given that email is not secure the obvious way to handle these stamps is for the sender to specify the maximum they want to pay, thier "account number", the target's identity and some form of message digest. This will have to be encrypted into a special message header (public key encryption would be the obvious thing to use). When the reciever gets a message it unpacks the "Stamp Header", passes the account and value information to the stamp server and upon getting confirmation classifies the message accordingly.

Mail list servers and other valid bulk emailers could function by requesting that clients sponsor the delivery of thier mail by providing them with prepaid stamps. Then each client of the mailserver would specify how many "paid messages" they wanted from the mailserver and have to "opt-in" to more when that set of stamps run out.

I realise that this is just a rough outline and the technical details will need work (which I don't have the time to do at the moment).

Will this work? What needs to be changed to make it viable?

I attempted to post the above message on SlashDot in 2002, but it was rejected as being a rant against Spam

Are there any groups out there that can take this and run with it? Would you be interested in contrebuting? Would your organisation be interested in developing or running a StampServer? How about ajusting you MUA to use stamps? If you want to take the idea further you could either just go for it, or (better) contact me here.

Ship Simulation

Before the Wright brothers the most complicated vehicles in the world were steam trains. Before railways the sailing ship provided the greatest handling challange. For many people the the sailing ship is still the most facinating mode of transport there has ever been. The success of the film "Master and Commander" and the "Pirates" films shows the alure of technology that was superceeded more than 150 years ago.

Yet while aircraft simulations abound, and even train simulations have their place there are no realistic sailing simulators.

Imagine having software that could simulate: the voyages of Columbus and Magellan; the battles of Nelson; the career of the pirate John Avery; the founding of colonies in Jamestown, Plymouth and New Amsterdam; Piet Hein's capture of the Spanish Treasure Fleet in 1628; Cook's voyages in the Pacific; the voyage of the Bounty (from both Bligh's and Christian's point of view) and the early trading forays of the Dutch East Indies Company.

There is a large and loyal market for recreational simulation software. This has been proved by the revenue generated by aircraft and train simulations. More mature users crave realism over simplicity and want open ended software toys rather than limited games.

I believe that software that simulates oar and sail powered ships has a good potential. A good maritime simulation would be complex enough to be challenging, have a wide enough scope to be interesting and there is a high level of public interest. In addition no quality software has yet been created. There is a vast potential range of interesting scenarios and campaigns which could be exploited, from the battle of Salamis to the voyage of the Beagle.

The simulation software will need to provide a visually compelling experience including the appearance of shoreline, cloud formations, waves and most importantly vessels. The control interface must allow for a range of users from those that want to quickly fight a simple ship to ship engagement to those that want to experience all the challenges of planning, equipping and executing a realistic sixteenth century circumnavigation.

The undelying engine would have to be able to simulate realistic ship handling, winds, tides, ocean currents and interaction with other vessels and shore based facilities. Finally of course there should be enough "hooks" to create multi-player scenarios, operating over the internet or using local connections.

The software should include a range of tools for scenario definers. Allowing users to create new campagnes where they control the appearance and behaviour of vessels, the availability of charts, historical changes in scenery, the weather during the engagement, the way that stores deteriorate and the loss of men due to disease or attack. If good enough scenario building tools are provided there will arise a fertile secondary market in "extra scenarios", which will greatly enhance the value of the basic software and will ensure a ready market for subsequent compatible versions.

Having though about this for some time (without having enough time to get started on development) I have a range of notes on everything from simulating weather patterns to the Roman sea trade with India. If you are interested in doing some of this or if you want to access my notes contact me here.