So pick an application, any application. "Here's one I just happened to have prepared earlier." Let's Start at the Top.
Imagine a decent payment system. I mean a really decent one, with reliable payments and proper client server architecture. So rule out Paypal, the IGs, and any online bank. But, include SWIFT, settlement systems, and the like. Well, maybe, you be the judge on that one.
What's going on with these systems is that they are message based. And, indeed, they can be used as messaging systems. When you send your wire through the monetary black hole also known as New York New York, your two losing banks sends messages over the same system to try and find the money. (This happens in excess of 50% for my international dollar wires.) Eventually the messages meet in the middle and some clerk remembers to crank the handle or feed the mouse to get the wheels of banking rolling again.
It's terribly unreliable, but it *is* messaging and the messaging is analogous to proper reliable messaging systems. It's used in exactly the same way as you or I use an instant messaging client or a mail client. Except it also does payments...
So what would it be like to add instant messaging to an Internet payments system? Or, to add payments to an Internet chat system? Well, for one, it would mean that we'd never lose another payment through human error, because the system that is used to do the human layer - that protocol known as conversation - is the same as that of the payments layer. While I'm chatting with my counterparty, I fill the box with the number and hit PAY. My computer does the rest, including guaranteeing that the right person gets it, instantly.
For another, once we have a messaging system, we can send invoices. As I'm working, I click on "Invoice", select "template #3", add an amount, and hit send. While I'm chatting, the invoice pops up on my counterparty's chat window. Her window happens to know what it is, and asks her "Pay now? Or Pay later? Or reject?" Couldn't be easier ...
In fact, once payments and IMs are intermingled, whole vistas are opened up. Pausing for breath here, it may well be that the reason EDI, ITP, and a squillion other ventures with too many acronyms didn't work was because they lacked two things: a payment system and a messaging system.
So that's my application. And here's my requirement: The Payment Is The Message. Or, The Message Is The Payment!
How to build this? That's the challenge of FC. Clearly, not from scratch. One either takes a payment system and adds chat, or, one takes a chat system and adds payments. I chose the former, because a) I had a payment system, and b) the reliability of payments dominates the reliability of chat. So it was a case of detuning in a lot of respects, which is easier than .. rebuilding.
Now, the requirement above says we have to make a payment system act like a messaging system. This immediately creates for us a few derivative requirements. Firstly, a client has to talk to a client in live form, which means a server has to talk to a client, in live, unsolicited form. Secondly, a client has to accept those unsolicited live messages coming in. Thirdly, the messages want to be of open, user-supplied format, somewhat.
To date, most payment systems have been "pull" in that the client goes to the server and pulls the data down. Our derivative requirements above break the pull model. To deal with "push" requires the server to be able to send a stream of unsolicited messages to the client, which means a further requirement on the secure protocol: datagrams. As we aren't going to compromise security, this means crypto datagrams, flying in both directions, which means a new crypto protocol, because there isn't a convenient secure crypto datagram protocol. (There is now: SDP1 is used in SOX :-)
Further, payment clients are generally far too "pull" oriented. This means proper multithreading and integration with GUIs. (Ours didn't cut it, and had to be rewritten. That took an age. This also means that certain client technologies are going to suck at the future landscape of payments, and we are entering a new age of client confusion as capabilities fail to converge with desires. But that's another rant.)
So, having isolated our requirements, and driven them down into layers of requirements, all that is left is implementation. Skip forward to the present, and I can now demo chat over payments. Or was it payments over chat? Either way, we are now well placed for phase 2: experimenting with invoicing, p2p trading, and p3p activities.
Adding instant messaging to the Ricardo payment system was no easy task. It involved the two quite mammoth changes mentioned above. But, the result is simply awesome. I don't think it's an exaggeration to say that this is a major result for Financial Cryptography - setting the requirement as the payment is the message is the payment is like the missing link in ecommerce evolution.
Suddenly, everything that people were dreaming of in the mid 90s becomes easy. Suddenly, not being able to reliably intermingle payments with messages looks very honky indeed.
And this is where FC gets its magic. It's a top-down application concept. Start with the application - the finance layer - and set your application goals. In this case, it was to add messaging to a payment system. Then, drive those goals as requirements down until you have a working concept.
Just as a total coincidence, we ended up with new crypto in there. Writing SDP1 was fun! But it was also totally application driven - and in fact it wasn't until we got to the point of actually needing it that we knew that crypto datagrams needed to be done. It was so small and trivial in the application scope of things, it got left out of the high level architecture as too trivial to mention.
That's what FC is: take an application of financial importance. Set goals, break them down, go deep down. Goals, Requirements, Layers, ... Probably, your journey ends with crypto. Sometimes it doesn't, but that doesn't matter. What matters is that what is *required* in an FC application is found and implemented.
And maybe we snuck some crypto in there for fun.Posted by iang at March 3, 2005 10:04 PM | TrackBack