If they tell us the $ figures, I am sure you will be motivated enough to discover the algorithms all on your own in an instant, or at least I would :-) High rewards have a tendency to induce epiphanies.
[Edit: Here is how I think it works, from my brief 2-day usage of it.
Comet: persistent connection between client and server.
First client connects to the server and creats a session. Server creates a "channel" with a file-handle/chan-id. Subsequent clients follow a URL to join the channel.
Without the live editing, you can see how any write in one client's textarea can be sent to the server and broadcast to all the channel members.
To allow for live editing, server keeps a "buffer" for the channel, initially empty.
All clients have onKeyPress or similar keylogging javascript event handler. A client might do internal buffering, say up to N characters or up to an X terminator (space maybe)
At the start, the server sends a test packet to each client and sees how long it takes, for timing purposes, call the time it takes to get a PONG response L for lag. So in the future, when a client sends a text snippet, it's timestamped, and the server subtracts the lag to get the actual sending time.
On the client side, display is refreshed after server response. When you type something, it's being rendered by the browser, but once your buffered input is sent, and the server responds, the display is refreshed by client-side javascript, which also keep an internal "document text model".
The server sends updates to your client's text model, and the view is rendered from this model. This allows the server to do all text-rearrangement on it side, so javascript isn't tasked with sorting time-stamped strings.
Along with timestamps, each text segment is also ID'ed by user, this allows the rendering engine to assign colors to the text.
Just wild speculation after giving this no more than 5 minutes of thought and another 10 to type it.
]