The task of making users aware of the activities of other users is one of the most important challenges in collaborative software. Extensive research has been conducted on the topic of awareness in shared editing applications. But most real-world applications still lack behind the possibilities depicted in, for example, [2] and [3]. In chapter X we give an overview of the research that has been conducted on awareness.
To my knowledge, no research has been conducted on the problems that arise when users produce changes offline and sync it later with the live state of the document. Google Docs, for example, does support offline editing. If the experimental offline functions are enabled, the user can access and modify the document without internet access. Upon reconnect, the content is silently merged with the live document. There is no feedback to the user that suggests that merge conflicts could occur. This often leads to unexpected results, as the following example shows: Alice and Bob collaborative on the document ”Shared Editing is the Future”. Alice modifies the document while sitting in a park without internet access. She changes the document to ”Collaboration is the Future”. Bob changes the document to ”Collaborative Editing is the Future”. We tested the exact same setting in Google Docs and ended up with ”CollaborationCollaborative is the Future”. The result is the sum of the modifications. While this is expected in real-time editing, it easily leads to syntactic merge conflicts when users are allowed to work offline.
Version Control Systems, like Git and SVN, do not require permanent internet access. Changes that are committed concurrently need manual interaction to resolve possible merge conflicts. This behavior is not desirable when users actively interact with each other - e.g. in peer programming. On the other hand, Version Control Systems elegantly solve the problem of offline interaction. A manual merge is necessary to make sure that strongly diverged states get merged properly. In this thesis, I want to investigate how to improve and visualize offline merging in shared editing applications allowing minimal user feedback for offline-merges.
Conflicts that are produced while working offline, are best resolved by hand, via some kind of Diff. In order to be able to create Diffs, I need to implement a way to compare different states in Yjs. The offline-merge could work like this:
  1. User has internet access and is asked if she wants to sync with the server.
  2. Before merging the content from the online server, save the current state \(s1\).
  3. Merge the state from the online server and capture the new state \(s2\).
  4. Compare \(s1\) with \(s2\) and visualize the changes via some kind of diff.
But the above syncing mechanism does not yet consider the case of new incoming changes from the server. It should be possible to render incoming changes while the user resolves conflicts.

Goals

In a recent thesis [1] I implemented Yjs11http://y-js.org, a novel framework for real-time shared editing on the web. The goal of this project was to make shared editing more accessible to developers. While all popular shared editing frameworks rely on a central server to resolve conflicts, Yjs does not need a single source of truth. So it is possible to design a highly distributed system, that does not have a single point of failure. Furthermore, Yjs does not only support shared text editing, it resolves conflicts on any kind of data.
Since Yjs does not rely on a single source of truth, it is possible to use Yjs with any communication protocol. At the time of writing this, there are working extensions for communication using WebRTC, WebSockets, XMPP, dat22A p2p gossip protocol https://datproject.org
A shareable type is an abstract interface to the shared data. We provide the following shareable types: text, rich-text, XML, array, and associative arrays. Furthermore, it is possible to implement custom shareable types.
Yjs currently lacks support for awareness features, like user management, change bars or shared cursors. The design of such awareness features is especially hard because Yjs cannot rely on a centralized architecture. Furthermore, Yjs currently lacks the support for a performant and fail-proof persistence layer. Yjs has the ability to store its internal structure directly a persistent database, but this architecture easily leads to data inconsistency, when the program is shut down while in a transaction. In chapter Z we describe and evaluate a new persistence layer that is more secure
The goal of this thesis is to describe and evaluate design patterns for shared editing applications. This includes the design of a scalable and resilient server architecture, and, of course, UI/UX patterns for the front-end application.
Yjs currently does not support any awareness features. The implementation is especially hard, because Yjs is based on CRDT, and works differently from well known OT based editing frameworks. In particular, I need to implement a method to compare different states of users.
Design and proof of a new persistence layer
Scale Yjs to a huge amount of users
Cursors, change bars, user management, offline-merge
How to properly design offline applications using Service Workers, and background sync
The ultimate goal of this thesis is to design a shared editing application with proper offline editing support, that proves that it is possible to create collaborative software that scales well with the number of users. Furthermore, I want to describe and evaluate design decisions that are necessary to create shared editing applications.