Under the Hood of Cloudless Collaboration

Dear readers, it’s great to find out that you are interested not only in co-authoring docs but also in what is hidden behind this process. Our team is here to reveal the secret processes of the cloudless collaboration technology.
Let’s start!

You are probably already familiar with the typical collaboration architecture where there is a central predefined and presetup point of entrance and synchonisation — the server in the cloud that does all the magic.

Our team wanted to investigate and try another approach — to build small collaboration sessions on demand without big centralised user databases and servers or even the Internet connection.

Noteworthy, we already had a text & spreadsheets editor that was able to edit local and cloud documents.

So, there were 3 main technical problems that we had to solve:

• How can we show one’s intention to collaborate on a document?
• How can we physically connect people to one session?
• Would our existing collaboration engine work in such an environment?

Next, we decided to try out some hypotheses and build a prototype that will allow users to collaborate on documents in local area networks using just their iPhones.

This allowed us to answer all these questions:

1. We used the Apple Bonjour technology. People would search one another the same way they search for a printer.
2. The second question was probably the easiest one. If people want to co-edit a local document, they should connect to a single device, for example, via WebSocket, to exchange data.
3. If we have single local document, we can run the same engine we use for the cloud on a lightweight local server that would distribute all the changes to other devices. Thus, the architecture would mimic its “big brother” but would be small and quick enough for local collaboration.

The first implementation

Pretty quickly we implemented the prototype. We built user experience around invitations. People would publish there names to the local network and wait for an invitation, then document owner would see and pick users with particular permissions.

Once we finally made a prototype, we discovered that:

1. Collaboration with the participation of 5 users had sufficient performance (which is quite good when an iPhone 5 acted as a server).
2. The UX was inconvenient — you had to manually invite users.

However, at that time, this prototype completed the task and the progress was frozen for various reasons.

The second implementation

The prototype was promising, so we decided to move on, but with few things changed:

1. We switched all the business logic to cross-platform C ++.
2. We moved from iOS Bonjour framework to bare mDNSResponder library that is a backbone of Bonjour.
3. We changed the UX. Now an owner simply publishes the basic information about the document to the local network and restricts access with a 4-digit passcode. Users can then connect to an editing session by entering this passcode.

All in all, we managed to achieve the cloudless collaboration between iOS and macOS platforms. Other platforms are coming soon…

What is under the hood of local P2P collaboration?

Now let us show you more detailed scheme of how this all works. Let’s look at the simplest example of 2 devices.

1. ​A user launches the app and opens a local document. The DOM is built and the CollaborationEngine is launched (ready to become a server at any time for any open documents in case the user wants to share something)​. ​When ​the user presses ​the ​’Start Collaboration​’​ button, mDNSPublisher is launched. It announces the document via the mDNS protocol on the local network.
2. ​The WebSocket server is launched, listening for incoming connections from collaborators. Users’ edits will be transmitted via this communication channel.
3. ​Next, the second user starts the application in the same way. However, instead of opening a document, it launches mDNSBrowser to find available documents to connect to.
4. After the necessary ​document is selected via ​the client’s ​​WebSocket​, it connects directly to the serve​r​​.
5. The app downloads the document, builds the model, and launches CollaborationEngine in the client mode.​ That’s it!

The role of Operation Transformation in collaboration

Let’s take a look at our collaboration engine. It is based on Operation Transformation (OT) with some peculiarities.

The following requirements to the algorithm were important for us on the design stage:

• an optimistic strategy of changes,
• convergence,
• intention preservation.

Some algorithms based on OT are peer-to-peer, but we use a central server. The central server allows us to simplify the algorithm implementation and optimise operation transformation by count comparing to peer-to-peer based algorithms.

​Anyway, we still have some issues to resolve

• Network address translation (NAT). For example, it’s necessary when two or more users are in the same subnet. This is a whole next stage of development for our team that allows to co-edit documents not only within one local network.
• App’s background functioning on iOS. When the document owner minimises (hides) it. Although the app reconnect occurs after its activation and all changes made by other users should be successfully shown in the document.​
• Support of other platforms. We are going to release Collabio Spaces for Windows, Android and maybe Linux.

Sure, we also have lots features to add, still, it’s another “How we built this” story… :)

Also, if you haven’t yet read “Co-authoring Documents. What’s Good and What’s Still Missing”, feel free to do this right now. It is our second roundtable we held at Web Summit and we’re glad to share the information about it here on Medium!