Inventions

There’s no common standard for an invoice, a cheque, or sending money (as much as paypal tries to be just that… they’re still a company, charging fees).

The problem with money is that payment is implemented differently all over the globe.

In Britain, for example, the bulk of payments happens through cheques. That means, an employer goes to the bank and brings her earnings (in cash or as cheques) to be paid into his account. He then writes cheques for his employees and either hands them over or sends them by post. The employee takes that cheque and goes back to the bank to issue the transfer, and again writes cheques to pay his rent to his landlord which walks to the bank… Ok, you could send your cheques to the bank by post I guess, which makes it a bit simpler. But still, the british system requires two postal letters for one payment.

In Switzerland, the bulk is paid by bank transfer. We have payment slips attached to the invoice which have a reference number. Online and offline banks use that number to identify the receiver’s account and optionally if the amount is correct, and then forward the embedded transaction id back to the issuer of the invoice. It is a bit better than the cheque system, but it still requires one letter (which can be replaced by e-mail if the slip is paid with an online bank).

In Germany, people mostly use Direct Debit. As a service provider, you send an MT940 formatted file to the bank which just imports that file, issuing withdrawals from all customers mentioned in the file (with bank details and account numbers). There’s no confirmation, only after the customer receives her bank statement she can claim that the transaction was faulty and the service provider is notified of the cancellation.

Credit cards charge (depending on the volume) a few percent of the transaction to run their operations and to cover themselves against theft. Paypal charges a few percent, which is good for many small sellers, but kills the method as soon as you go into big volumes.

The system definitely needs an overhaul.

So what can be done?

We need some standards to move money into cyberspace. First the objects have to be defined. One important object is the invoice. An invoice has a seller and a customer (both identified by e-mail address first and account details after). Actually, the invoice also has a signature of a seller. Anyone can send invoices around, as long as no one pays them nothing happened – the signature does not even have to be verified. The critical point is the payment. That needs a signature from a buyer. The buyer gives a signature to an invoice if it has the right amount and the right issuer and generally looks like the one invoice he expects (if there’s two you have a problem and you won’t pay it).
The invoice is a specialized, unconfirmed special case of a transaction. Using double bookkeeping, a transaction touches two accounts, so taking money out of a teller machine increases cash, decreases bank, for example. This way no money drops between accounts. But a transaction can look different for me as a consumer than for a seller – so a transaction between two parties touches two of my accounts and two of the sellers accounts. There money can drop, and often does (like the fees charged at the end of the month or even year for all the withdrawals you’ve done using the wrong teller machine). This is much harder to track.

So generally speaking, you can use your own bookkeeping (if you will), the seller can use her own bookkeeping, and the transactions only have to match when money changes hands. How could that be acheived?

Imagine an online repository of transactions. Those transactions can be unpaid or paid bills or any other transaction in a bookkeeping application. Sending an invoice would then mean to put a transaction from customer to seller into the repository and confirming it from the sellers side. The customer also goes into the repository (guided by a link) and validates the transaction. Then a payment provider can execute that transaction, and everyone’s happy.

Again, in slow motion: Using a freeware MT940-to-money-central-translator, the Merchant A uploads his invoice list to a web server he has chosen because it supports certain payment methods. The web service would actually allow to import an MT940 file, but then Merchant A would have to enter the email addresses of the customers afterwards which he does not want to do, so he uses the freeware. Merchant B would probably call the web service right out of his webshop.

The result is a file on that web server for that transaction. The transaction has got an id now and the customer needs to be notified that the transaction is filed and signed by the merchant. Merchant A does that with an email containing a link. Merchant B just sends the customer over to the site using a redirect. Now, what’s needed is the signature of the customer. Again, it does not have to have gone through an authority. Just a signature is good enough – only the bank has to know that signature.

Now the payment provider comes into action. A customer has several ways she wants to pay – maybe it’s a credit card payment provider which charges her a fee. But maybe it’s just an online bank which can work without charging fees, or it is someone who accepts cheques and issues bank transfers. The invoice becomes the transaction for the payment provider who then signs the transaction as well, as soon as the payment is done. When the Merchant checks the transaction again, he will see that it is signed by a payment provider and the deal is done.
All this can happen real time. The repository which stores the transaction never touches the money. The merchant only has to trust the payment provider, not the customer. Multiple payment providers can compete for transactions, and customers can even select the payment provider they trust. The repository can be anywhere and several repositories can coexist. Payment providers can help customers to migrate to cheaper or faster methods. Merchants can sell everywhere in the world with the payment methods available to the customer (even if it is only cheques).

Everything is moving onto the web. A year ago it was faster to find mails when they were downloaded onto your computer by IMAP or POP, but these days, you’re better off finding stuff if it’s with google mail. Pictures are online (flickr), Movies are online (myspace), Mail is online (google), so more and more we don’t seem to want anything more than a browser to use somewhere to be online.

What’s missing is speech. Rarely someone installs skype in an internet café or on a computer of a friend just to call someone. Maybe because you don’t want to mess with the headphones or settings, it’s just too private to fiddle with.

So the next step in the virtualisation of things would be to have an applet of sorts which gets access to microphone and speakers and does some self testing with the users help to set up the voice signal correctly, test the levels, asks the person if they’re hearing the signal allright and start skyping from a webpage. That way the user only has to log in, answer a few questions and you’re all set.

A calendar works by putting in special dates which last an hour, or a day, or a week. However, our lives normally require us to intervene with a special process several times. Let me write down a few examples to explain what I mean:

• When attending to a birthday party, you would normally want to bring a present, which has to be decided upon, bought, wrapped, and packed when leaving for the party.
• When attending to a meeting, one should prepare for half an hour, preferrably soon before. Then, the decisions have to be put into emails, new calendar entries and so on – everything has to be followed up in some way.
• When cooking a meal for guests, the guests have to be invited, the goods have to be ordered and bought, then there needs to be time for cooking (depending on the recipe). Afterwards there needs to be time for tidying up.

So when putting anything into a calendar, wouldn’t it be nice to have some help with planning the other dependent actions?

I imagine a collection of processes which work like ical entries, but contain several action items. Each action item has a timing component which can be before another action item (cooking before eating), days before (ordering wine), hours before (buying goods, preparing the meeting), or any time after. They also should have a limit in how early you can do it – you should not buy the meat for the dinner many days in advance. The action items should be tagged with what it is (shopping) so that several action items fall into one category, so when going shopping, goods will be bought for many meals, or bills are paid for many orders… you get the picture. This should not be limited to one person: A process often involves many people (A has to order, B has to pay, C has to do something to it, D has to ship it to the customer).
Also, the calendar needs to know when to place those tagged action items – that’s when it feels a bit more like a normal calendar again. Put in when you want to go shopping, when you want to prepare for meetings, when to do phone calls.
When you add a process to your calendar, here’s what I imagine what should happen: You want to invite guests for a dinner next Saturday. This places a todo into your calendar of deciding what to eat, and a reminder to call the guests in your slot when you do phone calls. You go straight ahead and choose a meal you want to cook (that’s a process too, like ‘Lasagne’). That places the requirements for shopping for the lasagne, the meat, the flour, and the wine. It notices that the time is right (nothing is going to degenerate in your fridge by then), but you have no time arranged for cooking. So the system suggests to you when you can do the cooking – with lasagne this can be as early as two days in advance, just the oven bit has to be right before eating. It finds some spare time slots and lets you choose when you want to cook.

Another good example would be holidays. Think of how many things are involved in that! Asking at work, booking, buying swimwear, checking passports, vaccinating, confirming flights… the list is endless and since it only happens about once a year, forgetting one or two of the above action items can be cause of mayor stress. If the items are placed at the right spots the planning will be a breeze.
A calendar like this will by no means let you stop thinking, but I feel like it would be much more natural to have processes spawn several days, even weeks. By editing the processes after the events (putting in things that went forgotten), those processes become better and will avoid you many headaches.

The most contact we have with large parts of our environment is by walking. Funny enough, walk should be fairly easy to simulate. Think of it like that:

A foot can be seen as a rigid body (especially if it’s in a heavy boot). So we have something with six degrees of freedom (three rotations and three translations). When we walk, we apply some force to the foot and to the shoe so it moves. The ground pushes the shoe back and gives us the expected resistance. We can interact like that with a shoe so well that we don’t have to think particularly hard to do it, even when we walk up a flight of stairs.

So the interaction between us and the environment reduces to a force we apply to the shoe and the force coming back from the environment. If we attach a shoe to a pressure controlled gear set which pulls and pushes (of course controlling all those six degrees of freedom) and measure the pull and push which comes from the shoe, we can simulate the ground just by pushing back whenever the shoe hits the virtual ground.

You have to imagine this apparatus with a visual headset, so that the simulated environment is also visible to the person walking in the instrument.

So what happens if the person walks out of the range of the apparatus?

There is a way to avoid this: By carefully tilting the system (the visuals together with the shoe, maintaining center of mass – somehow like balancing a stick) so that the person does not recognize it. This produces a force which will eventually move the person back to the center of the usable area. By doing that centering constantly, the person could walk up stairs (or have a feeling to do that) while the virtual stairs are moving backwards under her feet – she will not know she’s not walking.

Theoretically, the same device could be used to simulate pretty much anything you only need feet for to interact with the environment – like skateboarding, snowboarding or skiing, simulating a bouncy castle, sandy ground or deep snow. Or you could just use it to present the architectural model of your new home before it is built.
Just don’t cross your legs.

This one is something which hit me when listening to the daily source code: Adam Curry talks to some of his pals using his podcast, that is, he plays an audio feedback, pauses it occasionally and replies to the questions. So by subscribing to his peers podcasts, he’s basically creating a network of friends who listen to each others’ podcast and that way they’re talking to each other.

This blog here allows you to write a comment at the end of the post. Also, there’s a ‘blog roll’ at the side which lists my friends’ blogs. We could have the same discussion together on the blog as we have with e-mail.

Now, blogs replace part of the communication of e-mail (i.e. directed one-to-one communication with a one-to-many connection). Could a podcast-style answering machine (ideally on the web and accessible by skype and such) replace parts of the communication we have over the phone as one-to-one? It could be used like this:

When I have something to tell to a friend of mine which is not urgent, I record that onto my own answering machine as a public message (like recording a podcast). I subscribe to my friend’s public messages and to the comments sections of my own message box. This way, I would listen to what’s going on on my way to work, maybe reply to one or two of the posts (which then would land into my friend’s subscriptions). Other people could listen into the main posts, also into the comments if they care.

So that’s a new java application for a phone to be written.

A Gyroscope is a flywheel which is not entirely fixed in its axis, see the Wikipedia article.

There’s a special physical property of a gyroscope. When you try to rotate the axis, it will always turn the other way – not against where you are pushing, but sort of perpendicularly away from it. This allows gyroscopes to be used as compasses because they can be mounted so that they work against every wiggle.

Now, if you mount a gyroscope in a sailing boat, for example, so that the axis goes from starbord to backbord (left side to right side of the ship), a pitching movement would not change the axis of the flywheel, but a heeling (transverse inclination) would. Depending in which direction the flywheel is turning, this would push the boat to the left or to the right – it could be used to stabilize the boat.

Now in a boat you got about 10 tons in an oscillatory movement and most of that energy is going to produce noise and spray. If you could imagine having cogs attached to the axis which would take that energy and increase the speed of the flywheel with that, the energy moved into the flywheel would be enormous – hundreds if not thousands of watts. If you know sailors you know how much that is on a sailing boat – they normally avoid switching on halogen lights because they consume 30 watts each.

Now the only problem is the cogs.

Photochromic is a word explaining a property of some material that changes its colour on light impact. There are glasses available which do just that (become sunglasses outside, see the explanation on science.howstuffworks.com.

Now, think about using a paint containing such a material. It would mean that using a matching laser pointer, you could paint something on the wall at home or in the office. If a so called galvanometer scanner (very hard to find a good explanatory link here) is placed between the laser and the wall you can actually use a computer to paint that picture. Depending on the chemicals used, the picture remains on the wall for a few seconds to a few minutes. So there’s a chance to fine tune.

I’ve seen affordable scanners which can come down to ‘microdegrees’ in resolution, that is, from the 30 or so degrees freedom the mirror has, every degree is split into 1000 angles. if you use its full range, you have a blazing 30000*30000 pixel resolution.

This would allow the projection of all pages of a small newspaper in a readable quality. It would allow complete visualisation of any database schema you can think of, huge genome rows, detailed blue prints… you name it. It will not be a moving image, but that’s part of the attraction.

Another application is using the walls of your office as displays. Arriving e-mails would just pop up in front of you on the wall, you could see your peers, display a map of something or have a server log filling up your wall (don’t try scrolling though, just wait until it’s faded and start over again on the left…) You get the picture.

Issues to solve: Finding a laser and a matching chemical. Having that chemical being non poisonous, but cheap, so that it’s easy to paint a room with it. Having the laser so that you don’t have to wear protective glasses at the required intensity levels. Having that chemical so that it does not go dark by itself over time.

For some time now, there are polymers used as semiconductors, as light emitting diodes (LEDs) or logic. As applications of this, many people talk about using this for flexible, roll-up displays. What’s a bit more recent is the idea to create prints using plastic semiconductors with an inkjet printer, see for example
IDTechEx: Inkjet-printed Polymer Thin Film Transistors at Epson.

For me, the amazing thing would go a bit further. This technology could be used to create open source computing hardware.

Think of it like this: There would be a rack which can hold paper, and the corner of the paper is clipped so that it connects the paper to a bus. When you install a piece of software (open source perhaps) onto your machine, you are given the option to print some of its functionality onto a piece of paper (like a fourier transform extension, a number cruncher, a special shader for a game). This can extend the computer in a very specific way and allow a development of an ever growing bunch of specialized — or even general — hardware to solve specific tasks or even evolve in a computer on its own.

When you play a podcast with AAC-Enclosures in iTunes (see the podfinder podcast as an example) you get a picture and a link for the different chapters in the podcast. If you click the picture you would visit the link which can be a web page or another podcast page.

The link could now be designed as follows. If you press the middle button on your iPod or the Enter key on any other portable mp3 player you run an action. The link would then be one of three or so types:

* A preloaded little mp3 that would be played when the button’s pressed. This can actually be another podcast – iterate.
* A question: The timecode of the button is recorded and uploaded to a web site when the device is synced. This creates the possibility to react on the content while listening. There must be a way to react on that button by adding or removing a part of the podcast. Maybe it would be best to combine that with the above.
* Subscribe the currently playing podcast.

To support this the aggregator (iTunes) would have to think ahead a little and cache all the linked content (up to a certain level or size limit). The cached content should not appear anywhere unless the button is pressed. In the device, there must be a standard reply in case the piece is not there (because of the limits) — something like ‘the selected piece will be downloaded at the next sync’.

This would allow a listener to manage his subscriptions, to provide feedback, some voting – all at the touch of the button at the right moment:

* ‘To hear more, push the button now’
* ‘To subscribe to this podcast, push the button now’
* ‘If you agree to Doug’s proposal, push the button now’

That reduces feedback on something you can still manage when working out or driving the car. It’s enough to make this medium bidirectional.

Now we need an iPod which can do that. How about the java phones? There you could imagine even more – maybe a ‘record an audio feedback’ option or the like.

First post

A CNC machine is a device which cuts, drills and forms metal or wood and can be used to fabricate pretty much anything which consists of one material. The machine might have a carousel to choose from a set of instuments.

The idea goes as follows: Such a machine could theoretically be used to produce itself. One could start with the carousel – for all the people who have a machine which does not include one. The design could become more modular later on – first it would be important to help everyone who owns such a machine to improve his/her tools.

There was a time when the open source operating system Linux was in a stage where self-compilation of the kernel and the compiler was an issue. So one of the first jobs with any of these projects is to get the system self-hosting. One way would be to make the machine simpler, in order to just create something out of mostly wood or soft plastic, which will not have any cooling or high precision, and then slowly go to harder materials and increased precision.