transform/collab: Is it (in theory) feasible to select a client as the OT authority?

I’m thinking of implementing an prototype that uses prosemirror’s collaborative editing feature without using a server side JS runtime (Nodejs).

To be backend language agnostic I’ve thought:

Instead of having the server be the central authority for OT changes, it might be perhaps possible to select one of the clients to do the work, while the backend just routes the transformation messages and handles the selection etc.

There are of course implications (performance, robustness, authorization etc.) that might cause too many problems. So adding an additional server & runtime ends up being more practical.

But I’m more interested in whether this is feasible at all given the assumptions around OT in general and how it is implemented in prosemirror. I’ve read the post on the prosemirror blog, some of the source code and tried to gather some knowledge around this. So far I don’t see a fundamental stumbling block, but I’d still like to ask whether I’m missing some glaring issue here.

Thanks in advance!

Yes, that’s entirely possible. But then you’ll have to deal with the problems of client-to-client communication, electing a leader, and management of the active group of clients, which all gets pretty complicated.

1 Like

Thank you for the quick response.

First of all I’m glad that I didn’t fundamentally misunderstand OT. Phew!

But then you’ll have to deal with the problems of client-to-client communication, electing a leader, and management of the active group of clients, which all gets pretty complicated.

I’m superficially aware of these problems.

I currently don’t want to go as far and do direct client to client communication. I think websockets through a central server might give me enough leverage to select an authority between clients, since it keeps track of who is connected/disconnected and so on. Although the idea of using something like WebRTC seems interesting too.

I think the big issue is that it would introduce additional overhead that I don’t end up wanting to deal with, since every message needs to end up with the authoritative client, plus the server needs to ask for snapshots for durability. Plus I probably need to buffer the messages in case the authoritative client disconnects and a new one needs to be selected…

I might not do it this way but I want to make sure explore some ideas before a JS runtime becomes a hard-requirement.