Communiscript

Communiscript, later renamed Retype, was a collaborative structured document editing system. The idea was to treat a technical document like version-controlled source code: break it into sections and paragraphs, version each of those individually, and let several authors work on the same document at once with comments and revisions attached to the specific paragraph they refer to rather than to the document as a whole.

The original inspiration came from helping to write several academic papers, with each contributing author providing various sections and commenting on each other’s parts. I was also providing a final pass for English language usage (in a multinational research group the range of native languages was quite wide!). This was accomplished by emailing drafts back and forth, and reconciling edits in MS Word, an unpleasant task to say the least.

Communiscript, pre-2012

A 2018 backup of my old VPS turned up the original Subversion repository, revealing how many attempts I made at this, each one starting again with a different technology stack, and each getting a bit further, but ultimately not making it to a useable product.

  • PHP and Zend Framework, September 2009 – January 2011. Plain PHP to begin with, ported to Zend’s MVC over Christmas 2009. A jQuery front end using the pure templating engine and jStore for offline storage, with Flash, Gears, HTML5 and IE back ends — a good marker of the era. Login was OpenID. It ran as a password-gated private alpha in late 2009. I have effectively no memory of this code.
  • Java, EMF and GWT on App Engine, February – August 2011. A complete rewrite. The domain model became an EMF .ecore, persisted first through Teneo/Hibernate and then hand-annotated JPA on DataNucleus. Closure Templates server-side, RestEasy for the API. It reached signup, profiles, document creation and listing before it stopped.
  • Renamed to Retype, August – September 2012. A third attempt, Maven and Jetty with a GWT UiBinder editor and LESS, became net.kothar.retype.

The model was the interesting part — DocumentDocumentRevisionSection/SectionRevisionParagraph/ParagraphRevision, where every revision was linked to its own parents, so the document’s history formed a graph. Comments were embedded against individual elements, authors and figures and tables were first-class domain entities, and editing happened against a working revision which could then be promoted to a published version. I was clearly never completely satisfied with the implementation of this idea though.

Retype, March to October 2013

Communiscript was renamed Retype, using the rety.pe domain, and the forth implementation was a slightly more serious attempt to make a working website.

I stuck with Java but ditched GWT for Velocity templates, and built the backend on MongoDB. Paragraph content was stored as Markdown and converted to HTML server-side for rendering, with editing handled in the browser by the Redactor WYSIWYG editor.

The frontend interactivity was written in Dart using the Polymer web components library. Neither has made it into mainstream use for web apps, with Dart mainly known for its association with Flutter, although web components are still an interesting technology I’d like to do more with.

Retype, December 2015 to April 2016

The fifth attempt kept the name and the concepts but was another rewrite, moving off Heroku and MongoDB onto Google App Engine. The data model was ported to the App Engine Datastore. Dart was abandoned, and the frontend went back to GWT, this time wrapping MediumEditor for the editing surface.

Two new ideas were added that the earlier versions didn’t have. Named branches, so a document revision could be worked on under a label rather than a single working copy, and cross-references (xref) on any element of a document, so a section or paragraph could be addressed by a stable human-readable name instead of a generated ID. Paragraphs also gained a content hash field, with the intention of making identical content shareable between revisions and the parent graph content-addressable in a similar way to Git, although I never got as far as populating it.

The awkward part was the translation between parallel models of the document on client and server. Since the datastore IDs didn’t translate cleanly into the client-side code, a lot of bookkeeping was needed to translate between the two.

This attempt fizzled out in 2016; I had at least some basic editing working, but the key collaboration features were still lacking.

Current landscape (2026)

There were several commercial tools offering a similar structured authoring experience when I was last working on this project, but most seem to have disappeared now (10 years later).

Most of the products in this area seem to be CRDT-style real-time collaborative editing like online MS Office applications, rather than fully structured write-review-amend authoring and editing tools. I suspect people make do with Office for simplicity, and most businesses won’t want to use a third-party tool to author documents that need to be shared as .docx files in the end anyway.

I did have an idea that sites publishing web novels or fan fiction might benefit from something like Communiscript, allowing inline comments and editing suggestions to crowd-source reviews as new chapters are published, but since I never got a fully working project up and running this hasn’t been explored.

See also

The same underlying interest has resurfaced in other projects since.

  • Whalefish approached documents from the publishing side, as a CMS built on a user-defined document taxonomy and schema.
  • Kevalin is an ongoing experiment in peer-to-peer document publishing and referencing.