Some other libre collaborative text editors

The initial research taught me about some related projects in the free software world, in particular the Gnome Office Collab initiative that was discussed on the Abiword developers mailing list. This discussion included a very valuable post linking to the excellent computer science paper [sun98achieving] that was purportedly implemented by SubEthaEdit.

But as far as libre collaborative text editors went, I did not find much.

• The Collaborate application seemed like a good candidate, but it just did not work correctly. Though the web page looks good, it's just an aborted student project.
• The Network Text Editor [handley97network] appears more mature, but it's an MBone application and is all about making collaborative text editing work with such an unreliable transport. That might make for good academic publications, but that seems to me like the kind of contortions you would only perform to fit within an imposed research program.
• At the time, I also noticed this intriguing Debian package, called libobby-1.0. However, that did not seem to be actually used by something and it had the annoying property of enforcing a centralised model. It turns out that this is the core library used by Gobby.
• I have also recently been pointed at ACE, a Java application.

Centralised or decentralised?

What do I mean when I say: centralised model? In short, that means that all editing actions goes through a central, fixed, server instead of being transmitted among peers.

Centralisation in a real-time collaborative environment is problematic: the server network bandwidth can become a bottleneck, latency is increased as any two users have to communicate through the server, and the editing session cannot outlive the server. These problems are aggravated by the fact that the server often runs on the workstation of one of the participants, who may want to leave the editing session, and whose network connectivity may be less than carrier-grade.

When several people are collaborating on the same data over the internet, there are technical challenges in ensuring that all users see the same document, and that the changes appear to each user in a natural order. What makes the problem difficult is that, if you want to provide smooth editing experience, you must accept that different users may have slightly diverging document states.

When you type a word in a collaborative text editor, you want the word to appear immediately on your screen and then be sent to other participants in the editing session. Then another user can type another word before receiving what you typed, and that should also be displayed instantly on the other user's screen. In that scenario, you and the other user's document state diverge for a short while. Among other things, the collaborative text editor must ensure that everybody ends up with the same document state after a short while. That is the convergence problem.

Other technical challenges of concurrent document editing include causality preservation, and intention preservation. Causality preservation means that if you type "Hello", and a second user types "World" after seeing "Hello", then a third user must always see "Hello" appear before "World". Intention preservation simply means that edits always have the desired effect, which is not as simple as it sounds because document states may diverge.

Convergence and causality preservation seem difficult to achieve without arbitration. The usual solution to arbitration problems is to centralise the system, a single server process on a single computer decides in which order things really happened and breaks ties. Special relativity explains that two causally independent events may appear to have occurred in different orders for different observers, so it often looks like there is no way around centralisation when arbitration is needed. But the sun98achieving paper shows that centralisation is not required for collaborative text editing, and explains how to do without.

The need for a decentralised messaging abstraction

Centralisation, even if it problematic, avoids some other difficult problems. The sun98achieving paper makes a good job of explaining how to handle editing operations, but it says nothing about session negotiation. In particular, if you want to prevent two users from using the same nickname, or the same text colour, or you want documents in the session to have unique names, you have a difficult distributed resource management problem.

The Spread Toolkit solves a related problem, providing a messaging abstraction for decentralised networks. Unfortunately, it is very oriented towards clustering applications and requires that network participants be declared in a configuration file. That makes it completely unsuitable for use in a user friendly collaborative text editor. Also, its license has an attribution clause that makes it GPL-incompatible. However the Spread Message Service Types look like they would be a good foundation for a generic distributed messaging system.

Another problem with decentralised collaborative text editing over the internet is that to really reap the benefits of decentralisation in robustness and performance, you need to build a mesh of network connections which touches another difficult research problem (pointers gladly accepted): the construction of a robust mesh without going for a fully-connected network. In addition to this theoretical problem, special care would be needed to transparently and reliably establish connections to other session participants in the present of NAT.

My personal experiments were based on a decentralised model, and I got very tangled into the distributed resource management problem. I think that before we can have a usefully decentralised collaborative text editor, we will need a good decentralised messaging abstraction that provides a foundation for resource management and a transparent fault-resilient mesh network of peers.

Gobby, it works!

A few days ago, a colleague pointed me at Gobby. The collaborative text editor from the 0x539.dev group. I downloaded and compiled the application, played a bit with it, read the (still quite short) mailing list archive, and chatted a lot on the #0x539 IRC channel. And I have to say I was quite positively impressed!

In short, Gobby is a multi-platform (Linux, Mac, Windows) collaborative text editor written in C++ and using the GTK toolkit. Despite the low version number (0.2.0 was recently released) it's already quite usable though it still has a few annoying limitations:

• When a user loads a document, the whole document appears with the background colour of that user, making it impossible to see the text that user has typed during the session.
• The Undo mechanism does not distinguish between local and remote edits. There is no way (yet) to undo your actions without first undoing more recent actions from other users.
• The networking implementation is still less than ideal, in particular, the application freezes while trying to establish a connection.
• The carets and selections of other users are not visible.

On the upside, most of these limitations are likely to be fixed in the near future, except multiple-caret and multiple-selection display that would require a non-trivial amount of GTK programming.

Most of the features you would expect are already there:

• Lock-less collaborative text editing that actually works, providing all three of convergence, causality preservation and intention preservation.
• Each user is associated to a background colour that marks the text the user has typed during the session.
• A built-in chat service.
• Syntax highlighting provided by the GtkSourceView widget.
• Zeroconf networking using Howl.
• A sane build system, based on the GNU Autotools suite.
• Localisation support using gettext.

My main issues with this project is that it is written in C++, which is not a language I would be programming in for fun, and that it enforces a centralised model. However, centralisation appears like a reasonable choice when you consider the additional complexity involved by useful decentralisation.