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 | TrackBackNow all you need is a huge client who will bully their suppliers into using your system - see www.ob10.com
Posted by: Darren at March 4, 2005 04:53 AMI disagree with the comment about EDI - it was and still is widely deployed and mostly using X25 et al in the supply chain.
EDI is entirely message based and can even integrate with faxes on the edge of the network, plus do payments if the agreements are in place. I agree it is not very adhoc :-)
Posted by: fm at March 4, 2005 11:36 AMIt sounds like a cool program, you ought to release a free version for non-commercial use. What kind of payments does it use? Anything that end users could reasonably get access to?
I don't see why you had to use datagrams just because you are sending a stream of unsolicited messages to the client. Is this some hack to get through firewalls?
Posted by: Cypherpunk at March 4, 2005 03:28 PMWhat kind of non-commercial use could a payment system have? I have always wondered what "free for non-commercial use" means for other software, but I would imagine that a payment system is something that by definition is used for commerce :)
Posted by: dash at March 7, 2005 05:36 PMCommerce is about trading for profit, one supposes. Trading for other reasons is also good fun; we are using the payment system to coordinate artists and production of art. Some of the contracts are making a name for themselves as art, and some value is moving around simply to better account for the favour economy.
Pretty much all the client side software is open over at webfunds.org. (I have to push out a new release including the messaging component.) The issuance server software is not open, but is gradually migrating to more open. As and when I get around to it, I'll add issuance capability into the client-side, that seems to be a more robust model than server-side issuance.
Posted by: Iang at March 8, 2005 10:34 AMObviously any system that makes payments needs to have bills and invoices, obviously any system that makes bills and invoices needs to have messaging. Though obvious, it is seldom done.
But instant messaging is real time and by default does not generate a readily filed record, while bills and invoices are frequently batch mode, and must correspond to fileable records - which is more like mail than instant messaging. And, of course, if a system for making payments works somewhat like mail, then it must have phishing resistance, which means it must have some kind of logon and password management that provides mutual authentication, like SRP or augmented PDM. And, of course, a system for making payments should be capable of being readily linked to a system for managing reputations, which is more like usenet news than email.
So though linking instant messaging to payments is a step in almost the right direction, I think it is a step in not-quite-the-right direction.
James,
yes, this is why I suspect there is more mileage in picking a payment system and adding IM than the other way around.
Cypherpunk,
The system I wrote it in is our old favourite: WebFunds/SOX/Ricardo/SDP1. The program is downloaded from the www.webfunds.org site. It isn't exactly ready yet, as I haven't had time in the last month to do a new distro, also the distro is a very primitive zip file. Still, aside from those planet sized nits, it works ;)
Posted by: Iang at March 14, 2005 06:28 PM