timps is an (optionally transparent) proxy server targeted at instant messaging networks -- particularly AOL's Instant Messenger. One of the more important features is that when multiple users are connected through the proxy, messages between those users are kept in the local network and not routed across the internet. Multiple proxies can be connected together to form trusted networks for secure message routing. The proxy can also be used for connecting artificial users, such as interactive agents / bots without rate limiting. More generically, modules can be written that interact at any stage of message routing, creating a flexible system for developing applications with and on IM.
Since timps speaks the IM protocols natively (ie, it looks like an IM server), DNS rerouting or other tricks can be used to invisibly force users through the proxy. This is particularly useful for companies facing auditing compliance on employee communications (for example, Sarbanes-Oxley for financial companies, or normal policy for law firms).
Long story (see history section below) short, this is the beginning of reassembling ideas from a past project. Not all of it is here yet, and the feature base may seem oddly complete in some places and inconveniently incomplete in many others.
To check out the latest source, use anonymous CVS:
mkdir -p ~/cvs/timps
cd ~/cvs/timps
export CVSROOT=':pserver:anonymous@cvs.zigamorph.net:/usr/local/cvs/timps'
cvs login [password is 'anonymous']
cvs co .
If you need commit access, contact mid.
To browse CVS and do visual diffs, use ViewCVS.
Ha, right... I'll get right on that.
The timps-users list is for discussion of user-centric timps issues. Since timps is currently developer-oriented, this list is not very active yet.
The timps-dev list is for discussion of technical and development issues concerning timps and related components.
timps is built ontop of naf, a framework for building networked applications easily and includes a variety of useful routines. The next level is gnr [sic], a generic message router -- this includes routing messages between instances, which timps peering is based on (rather, will be based on).
The rest is timps. Mostly the fine details of each IM protocol, as well as the IM management/auditing/logging (again, when those things get implemented).
There is also an assortment of modules/plugins that can change the system's behavior at any of these levels.
timps protocol modules are structured in such a way that they can accept messages with or without context. All messages boil down to a "message text"/"message text type" (eg, "text/html") pair, and a pair (source and destination) of name+service duples for routing that message. Of course, most protocol modules supply additional hints for routing and rendering, but they must be able to operate without those hints when required. Related to this design goal, protocol modules should never directly forward a packet containing a message to the server or client -- always rewrite them. This makes sure nothing can slip by the auditing controls, and it has the side-effect that it (almost) forces the context-free generation of message packets to be written properly, reducing the corner cases.
Defining a message in these simple terms allows excellent flexibility in creating modules that accept and generate new messages -- bots, translators, et cetera -- without the need to adapt them for every new protocol or circumstance. Defining the message routing in similarly simple terms allows similarly great flexibility in the routing of messages. Think about a module that, say, lets you send messages to Yahoo with your AIM client. Additionally, when combined with the protocol modules' support for totally rewriting messages, this method of routing makes 'local routing' pretty much implicit.
timps is a reinterpretation of significant portions of what has so far turned out to be the largest project of my hacking life. The original idea and subsequent prototype stemmed from two projects I was working on at the time. First, I had a Linux kernel module that redirected OSCAR advertisement server requests to a target of your choosing. In combination with another component that looked like an OSCAR advertisements server, this nicely solved the annoying animated advert problem in Windows AIM (like this, which was the company name at the time). (This of course became useless when AOL switched to using HTTP-based adverts.) The other project was an AIM server, which I never quite finished, as there was very little need. The problem with an independent AIM server was that it would not be able to communicate with the real AIM network, and really the entire value of AIM is that other people use it.
The idea for a proxy -- a man-in-the-middle that could selectively manipulate the client/server stream to add features and security while still maintaining the connection with the real world -- is obvious from there. I built a very rough prototype in about 1200 lines of C across a few days in the middle of September 2000. It was based on the first open-source SOCKS proxy I could find, though there was very quickly no code left from that original. The prototype required you to set up your AIM client to use SOCKS5, as I had yet to make it 'transparent'. (I remember a conversation with my then-boss. He wondered why it required SOCKS and didn't just speak the protocol directly. I replied, "Yes, of course it could that. It's trivial.". Which, just like any statement of that sort, was only slightly true.)
Talking about it at the office ended up being a bad idea. No, they didn't try to take ownership of it or anything. But they did convince me that it'd be a great product and that the company should pursue it. This sounded like a great idea to me. Eventually we ended up putting a patent together, which is still pending, but is available online here. Several years of on-again-off-again support from the company followed, in addition to the occasional attempt at pursuing funding for a new company around the idea, Ultimately, nothing happened, but the code was forever encumbered.
Which is why this is a 'reinterpretation'. Legally the original code base is not mine. I had continued working on it throughout my employment with the company, even though it was only being used by me and a few pet projects. It took on the role of my personal development framework and at its peak was probably 70,000 lines of C -- supporting numerous IM protocols in addition to random other things (including a protocol of my own design for maintaining a network of proxies to route messages between trusted parties, and even a TCP/IPv4 stack -- all the way from libpcap/ethernet to, say, parsing a SOAP request). Now that I no longer work for that company, and have far more time than I know what to do with, I decided to put together something incorporating some of the ideas, style, and general spirit of the original.
In the meantime, several real venture-backed companies have tried to create similar products. FaceTime's product even received AOL rebranding as AIM Enterprise Gateway (now discontinued). Yahoo attempted it, too (also recently discontinued). At least I can take bitter solace in that even though my stuff was never taken to market, no one elses' was wildly successful.
