Condensed Journal

The Journal is created as a side-effect of editing and matches the editing interactions in detail. Here we consider eliding some of that detail when published or viewed. We don't yet exploit the journal for merging but should be careful that we don't limit that functionality.

We know that the server has recorded a change when the journal entry appears. This might be valuable moment to moment even for trivial changes.

As actions get older we become less interested in the details. We've introduced "logarithmic" perspective with Journal Spacers. These could mark boundaries between degrees of eliding.

When we retrieve an old version, that establishes a new viewpoint in time. More detail could be of interest then. (do spacers adjust?)

We do have several points of "publication" that could represent useful times for simplifying history. Any push from local storage or across a firewall would count as publication.

Any fork is a publication event too but do we really withhold history? Especially if it is not our history?

When we write import scripts we often discard historical information that might be available. Common practice is to condense all history into a single create, possibly with provenance attached.

We have been thinking of this as peep-hole optimizations, applied locally, preserving the end result.

move, move ⇒ last move

add, delete ⇒ nothing

add, move ⇒ add before

edit, edit ⇒ last edit

The textEditor creates some additional noise in the journal that could be recognized.

split, delete ⇒ nothing

split, join ⇒ nothing

We could take a longer view and attempt to condense an editing session (or period of possession) to an optimized set of edits.

create empty, any editing ⇒ create empty, add, add, add

create empty, any editing ⇒ create complete

fork, any editing ⇒ fork, optimized editing

any editing, fork, any editing, fork ⇒ fork, fork

There are a few cases of embarrassing redundancy that could be removed by making the journal more complex.

We store images in both the story and the journal. We consider alternatives in Image Assets.

We are required by the license to attribute sources so we must preserve at least one fork from each contributing site.

We should leave the journal in a state that creates the current version. Some of our oldest pages don't do this. Nothing breaks, but it is confusing. Hand-edited pages are prone to this.

Version retrieval from the journal must be tolerant of any corruption of the history, including broken or missing action types, or even missing journals.

We have suggested cryptographically certified journal entries that could validate the reproducibility of the journal to a point in time and a chain of trust. Subsequent edits would be suspect until recertification.

We have found unlikely value in redundant edits such as the weekly update of the hangout address in Frequently Asked Questions. Browsing through the journal I can see when we started operations that way and on what dates I was a little slow making updates.