People have asked us for a way to try it out with other people, so here's a set of pads for news.yc readers to play with:

http://etherpad.com/ep/newsyc

For the curious, I added this URL to our running web server in 5 minutes with 12 lines of JavaScript:

  function render_newsyc_get() {
    function countUsers(p) {
       return getCollab().getDocument(p).getNumConnectedUsers();
     }
     var body = BODY({style: 'padding: 20px; font-family: monospace;'});
     body.push(H3("Welcome news.ycombinator readers! ",
   	       "Join us in an EtherPad of your choosing:"));
     pads.forEach(function(p) {
       body.push(A({href: p}, p), '   ('+countUsers(p)+' users)', BR());
     });
     response.write(HTML(body));
  }

Just a taste of the AppJet Web Platform. (A separate 1-time script generated the array "pads").

Just crashed my safari :/ and now url seems down...

Same here, WebKit nightly didn't crash but I'm getting a "Lost connection with the EtherPad synchronization server." error.

Scalability is harder than it looks ;)

"Changes are made in absolute real time, something even Google hasn’t been able to do (Google docs update every fifteen seconds)."

To imply that Google 'hasn't been able to do it' is kind of silly. It's more likely that they chose not to do it and/or their scaling requirements made it impractical.

It's not Google's scaling requirements that limit their simultaneity (or, obviously, a deliberate choice). Google Docs uses a different architecture, where a master copy of the document is kept on the server and broadcast every n seconds to all the clients. This is easier to implement, but can't be made fast enough to feel realtime.

Etherpad uses a different approach: they ship all the edits to all the users as soon as they happen, and each client processes them to produce an updated document. The hard part is making sure each user is seeing the same thing. This is easy with the Google Docs model where a single master copy is regularly rebroadcast. To do it the Etherpad way, without a master copy, is extremely hard. From what I've heard about what they had to do, it sounds like one of the more impressive hacking achievements by a YC-funded co to date.

A master model is not necessarily slower. Everything goes through the server either way, and it comes down to how much data you have to transmit and how much the sender, server, and receiver have to process it.

At http://draftastic.com/ we keep a master but only broadcast changed portions -- a compromise between re-sending the whole document and handling a hail of tiny diffs. This uses automatic locking, which we thought was reasonable given that people rarely want to type directly on top of each other, but it means a much simpler implementation of undo and so on. Basically, we've made a heartbeat-based system with heartbeats so cheap that they can be fast, and we never need a merge algorithm.

In any case, I'll be watching the just-raw-edits approach with interest. Best of luck to Etherpad -- there's plenty of room in the market.

Hopefully the mechanism they chose is amenable to cross-user undo. (Though it's currently missing, I'm assuming single-user undo can be added easily enough.)

Undo works, just type control-Z (on windows) or command-Z (on a mac). It will undo only your own edits.

We haven't figured out a way to let people undo other users' edits. (We can perform the manipulation on the document, we just haven't figured out a sensible UI for it).

I don't think there is a sensible UI for it. I'd leave it out completely.

Look at MMO's or FPS games to see how fast they can make that model.

Paxos-style distributed consensus?

Agreed. Etherpad is sending a new POST request pretty much every keypress. Considering the HTTP headers and cookies, that's around 500-1k of data per letter typed. At google docs volume that would be a lot.

(Total data sent when I press 'j' was 1073 bytes of HTTP headers, and 123 bytes of program data).

The other reason may be that whilst it looks really cool to see each other typing, is it really needed?

Does look quite slick though :)

I think they're using comet for the requests so while the activity may be high when people are typing, during breaks it should be very low as opposed to ajax polling.

I do think that real-time is really needed for many applications. The few times I've tried collaborating on a google doc, I've given up because the lag introduced the possibility of overwriting each others edits. That and just a general annoyance with saying "Do you see it yet?" over and over.

Well that's a stupid way to handle it... keep the socket open... read about Comet. http://en.wikipedia.org/wiki/Comet_(programming)

Are you being sarcastic? Does anyone know what comet is? Please explain exactly how you can SEND multiple packets over time from browser to server without sending more HTTP requests, and without using any java applet/flash.

It's a shame people seem to have started saying "use comet" without understanding what it means. Did you read that link?

Connection: Keep-Alive

Yes, you can specify keep-alive (Although some browsers refuse to do it in an XHR - Opera for one). However, you still send the full glut of HTTP headers every single request.

True, you still need the headers, what you don't need is a new connection every key stroke. Establishing a new TCP connection is a relatively high cost network item (between all the Acks and Syns you need 3 messages have to go back and forth for it to establish), keep the connection alive, the stuff will run a lot faster.

You can null out the default headers on a XHR so they don't get sent.

Without any java applets or flash?

You're forgetting Google didn't develop Google Docs in-house they purchased Writely back in 2006 and that's the codebase Google Docs is built on. Depending on how it was built originally the change might require a massive rewrite...

Was Google Spreadsheets built on top of the Writely codebase? Because their Spreadsheet app is WAY better than their Document app.

No that's based on a different acquisition, 2Web Technologies

What's the difference between "something even Google hasn’t been able to do" and "their scaling requirements made it impractical"? When you get past the semantics, it's essentially the same thing. Either way, they're not doing it.

Lack of action doesn't imply inability. That's what's different.

A parked car is not a car that's not able to drive. It's a car that's not driving.

The end user only cares whether its driving. If it's not moving, the user doesn't really care why.

What would make this application killer for me is if was embeddable in other applications as a widget (think rich-text editor on steroids). This, plus a git-like backend for revision history, would be just absolutely amazing.

Agreed. Imagine this sort of collaboration in the Heroku editor... Or online collaborative versions of Textmate, emcacs, vim, etc.

Be nice if they offered textile and markdown rendering.

SubEthaEdit's collaboration engine is licensable (Coda has it), so it's possible something like TextMate could go there. I'd also like to see a Windows package get it because that's a pretty big limitation with SubEthaEdit at the moment.

> The AppJet team plans on releasing this new server-side software (similar to their previous release but with the addition of Comet functionality and other pieces) completely Open Source as well.

-- from here: http://news.ycombinator.com/item?id=369500

Is their other stuff really "open source"?

They definitely released their source code (available here: http://appjet.com/download) but the only mention of a license on that page is:

Disclaimer: The appjet.jar software is provided "as is", and you use it at your own risk. AppJet Inc. is not responsible for anything bad that may happen.

From that, it's not really clear whether it's open for modification and redistribution. Any of the AppJet guys care to comment?

They definitely didn't release their code. That jar is full of built class files, dependencies and some of their library in javascript.

What a fun service. I can't remember the last time I used the word "fun" in reference to a plain text editor. :)

It's really interesting to watch the POSTs fly by and consider the implications of out-of-order updates, breaks in the open downstream "comet" channel, interleaving potentially conflicting text from different clients. A lot of difficult tradeoffs that they seem to have made good -- or at least plausible -- decisions on.

Maybe this will change how people code. Instead of programmers hanging out in IRC, they can hang out in the code and fix things instead of just complaining :-)

create a mashup with this and github to pull in code from a github url and edit it

Stir in half a pint of Mibbit IRC widget, and you could have quite a productive environment.

There's already a Chat pane in the sidebar...

SubEthaEdit has been one of the coolest pieces of software I've used, but it's 1) not free, 2) desktop-based, 3) OS X only. Etherpad offers all the functionality without those restrictions.

This is a really impressive product.

This would be useful for getting candidates to write code during phone interviews!

That was one of the applications the Appjets had in mind. Aaron told me that when he worked at Google one of the main reasons they used to fly candidates in was just to watch them write code. Part of that step could now happen before the flight.

Air Etherpad. Official Airline of the Recession.

except that you can't know if the person who is typing is the real one

That's why I said part of that step could happen before the flight. You would also want to have some tests in person for the people who made it past the remote test. They probably wouldn't be needed that much, though, because I don't think most applicants would go so far as to have someone else type their answers if they were doing it live on the phone with someone from the hiring co.

yeah, on a second thought in the potential to limit the stress I suppose this could be used by putting the intervwee alone in a different room and watch them code remotely from another room.

...or by himself, or using google, or a serial killer in his underpants, etc.

Just had an idea... when you show the revision view for a given revision, attach the chats that happened during the same time as comments to the page.

There is no test etherpad on their page where you can actually test it on a document with others editing simultaneously, so I created one for HN:

http://etherpad.com/a4jtHYAoF9

Just join in and try it!

My first thought while playing with it during class was that it'd make a great replacement for Basecamp's crappy Writeboard feature.

I was also thinking that instead of unnamed, you could build a list of celebrity names that are used until the user changes it (which should be pretty quick if you wind up with something like Danny Glover or Hans Blix). If not, at least you'd have a way to distinguish between people.

Hey, where have I seen this before?

Oh yeah, here: http://gobby.0x539.de/trac/

Gobby. Bubbling over with 1990's user friendliness:

"There is a native Win32 build of sobby at [link]. There are no special Windows-specific features, but it runs. You will need glibmm, libxml++ (from the gtkmm installer), obby and net6 DLLs (from the Gobby installer or the gobby-win32 repos). There has been no extensive testing on the Win32 platform, so consider this as experimental." - March 2007, (latest)

Which is a desktop app...

;)

And yet it's the same functionality. Personally, I would prefer a desktop app when working on anything sensitive (i.e. code at work)

yeh I have to agree there.

Another plus: you don't have to worry about it getting slashdotted / digged / whatever like what's happening now :)

This seems like SubEthaEdit but for the web. Maybe it was the barrier to entry or the technical wrangling to get it working that killed SEE; But even among Mac-heads I haven't seen it being used in years.

I'm not sure how much this will fly.

I've used SEE almost exclusively for the last three years. I know plenty of other people who do too.

Being able to skype someone a link is a plus. Network difficulties are easier to overcome online.

Interesting app; it looks like it has a lot of potential.

On an unrelated note, something about Arrigton's journalism just bothers me. It's like every title has to involve some tired old cliché or unsubstantiated, conflicting statements.

neat but hardly killer.

Yes they have the handiness of true realtime updates (and I am not denying that isn't a huge feature) but that's hardly a unique feature (or wont be for long).

But then the rest of the UI / feature set is far too bland :( at least get some code highlighting and stuff in there.

Also in our short test earlier it didnt handle mass deletions & editing very well (if I deleted a block of text as someone was adding to it merry hell broke loose :P).

IMO a nice demo of a cool idea but badly executed enough to be no real use. Make me a real time white board and THEN I might take notice :D

> Make me a real time white board and THEN I might take notice

You mean like http://dabbleboard.com ?

They do have syntax highlighting for JavaScript.

One thing I've often wished for was a standard syntax for specifying syntax highlighting modes. Right now basically every text editor has a different way of doing it, so you have to write dozens of modes when you create a new language or editor.

I know what you mean :D that would be rather cool

Thinking about it (going back slightly) there are not many situations where I see anyone actually coding with others in REAL time. Perhaps on hackathons (actually it would be ace for them) or suchlike - but for real work I doubt it would work. So the big selling point is gone: and there is nothing else to support it as a useful app (when Google docs has 100x the features).

That said I hope that will change in the future because it is rather nifty :D

Would be killer if I could bring it in house, so we could discuss everyday work on it.

(Yes, we could do that on public sites, but we're not going to, and neither are many of our customers).

This is very cool for sure. I really think it would be nice for brainstorming on code with other developers.