Presence for OT Types

[Curran Kelleher]

Presence, meaning for example where others' cursors are, is an essential feature of real time collaborative systems. Without it, the experience of real time collaboration suffers greatly. When it comes to implementing presence, one of the tricky bits is transforming presence by ops. Since various OT types will transform presence in different ways, it makes sense to have each OT type define its own presence data structure and transformation algorithm.

This work has been underway for some time now, but I wanted to make this issue to discuss the core of the work - namely, whether or not this feature stands a chance at becoming an "official" part of the OT implementation recommendataion/docs within the ottypes organization. This would be an improvement over the current situation, where the feature is implemented and maintained solely in a fork or multiple divergent forks.

This PR Add presence-related properties #27 introduces the following new methods:

• createPresence([initialData]) -> presence: (optional) Creates a valid presence from some initialData. Presence represents a user and may contain details like user ID, cursor position in a text OT type, etc.
• transformPresence(presence, op, isOwnOp) -> presence': (optional) Transforms the presence by the op to create a new presence' which is adjusted in some way for the effects of the op. For example, a cursor position may be pushed forward, if the op inserts some text at the beginning of a text document. isOwnOp determines if the operation comes from the owner of the presence, or from another user.
• comparePresence(presence1, presence2) -> boolean: (optional) Compares presence1 to presence2 and returns true, if they are equal, otherwise returns false.

I personally am only totally convinced that we need transformPresence(presence, op). The experience of actually implementing the feature may prove the need for the others.

Related reading:

• Presence issue in ottypes/json0
  • Presence PR in ottypes/json0
• Presence issue in ottypes/json1
• Presence issue in ottypes/rich-text
  • Presence PR in ottypes/rich-text
• Presence issue in ShareDB
• presence implementation in ShareDB (pending PR) by @gkusiba
  • Teamwork Fork of ShareDB (PR is merged)
• ot-rich-text (implements presence)
  • Operation.js implements the presence functions
• Add presence-related properties in ottypes/docs (pending PR)
  • Teamwork for of ottypes/docs (PR merged)
• https://github.com/SyncOT/SyncOT - implements presence differently than ShareDB, but will leverage the ottypes family.

With this issue I'd like to open a discussion about high level questions around presence, like:

• Does it make sense (is it really necessary) to add presence awareness to OT types?
• Is presence a feature that the ottypes body of work should support?
• If this standardization gets sorted out in ottypes, can mainline ShareDB be made to support it?

/cc @josephg @nateps @ericyhwang @gkubisa @mdaines @houshuang @jhchen

[Greg Kubisa]

The new presence-related functions are needed for presence as implemented in @teamwork/sharedb. I'm the author of that feature, yet I realise that it might not represent the optimal design. I see it more like a compromise which allows it to work with the current implementation of ShareDB. Consequently, I'd recommend careful evaluation before baking it into the ottypes spec.

PS. An alternative presence design could treat presence data (eg caret position, selection, etc) as a part of ops and snapshots, with a separate "connection-level" module determining who is actually online right now and which carets/selections should be displayed.