The hard parts of real-time collaboration
Presence is the easy part. Permissions, comments, identity, and recovery are what make shared editing dependable.
Two cursors moving on the same page makes a strong demo. A useful collaborative editor needs much more: identity, permissions, shared state, comments, notifications, and a clear answer when the network fails.
Real-time is not a feature by itself. It is a promise that everyone is working from the same truth.
Muhammad Amjad, One Percent
flowchart TD
U[Signed-in user] --> A[Application server]
A -->|Authorize room| R[Real-time service]
U --> E[Rich-text editor]
E <-->|Operations and presence| R
R --> S[Shared document state]
R --> C[Comments and notifications]
A --> P[Roles and sharing rules] Separate identity from presence
Presence answers who is here and where their cursor is. Identity answers who this person is and what they may do. These are connected, but they are not the same.
In Shocodoc, the application authenticates the user, then an authorization endpoint decides whether that user can enter a document room. The real-time service receives only the identity and permissions it needs.
Give permissions a small vocabulary
A simple role model is easier to reason about than dozens of special cases. Owner, editor, and viewer cover most document work. The server checks the role for sensitive actions, while the interface uses it to explain what is possible.
A disabled toolbar is helpful, but it is not security. Share changes, document deletion, and room access must be checked on the server.
- Owner controls sharing and deletion
- Editor changes document content and joins discussions
- Viewer reads and observes presence
- Every role is checked again for server actions
Shared text is only one shared system
The editor content, cursor presence, threaded comments, mentions, and inbox notifications all move at different speeds. Treating them as separate concerns keeps the core document stable when a notification is late or a comment panel fails.
This separation also makes the interface more honest. A saved document can remain safe even if a collaborator temporarily appears offline.
Design recovery before polish
Networks drop and browser tabs sleep. A collaborative product should reconnect without making the user guess whether work was lost. Clear connection states and visible sync feedback reduce anxiety.
The human test is straightforward: if two people edit, comment, lose connection, and return, can both explain what happened? If not, the architecture still needs work.
Muhammad Amjad
Co-founder and CEO at One Percent. Writes about the practical choices behind products that need to work in the real world.