After three months, we built an AI version of “Feishu Docs”

Author: Xu Xiaoxi

As a founder who has worked deeply in the AI office and collaboration space for many years, and who keeps exploring enterprise efficiency tools, my team and I have spent the past year or more chewing on a hard problem: building a true developer-oriented AI document that supports private deployment and natively supports real-time collaboration — Mindlink 灵语文档.

Many followers ask me: with so many online document products already available, and Feishu, Tencent Docs, and Notion already mature, why build our own?

The answer is actually simple: when you go deep into scenarios like enterprise intranet deployment, vertical business-system embedding, and deep secondary development, you find that products on the market are either too heavy and too expensive, or simply cannot meet the core requirements of “data does not leave the domain, capabilities can be customized, and collaboration does not stutter.”

In this article, I want to analyze Mindlink's complete design thinking from both a developer technology perspective and a product founder perspective, from the underlying data model to the upper-layer service architecture, and also talk about the technical trade-offs and engineering thinking we encountered while building it.

Live demo: https://mindlink.turntip.cn

Technical documentation: https://mindlink.turntip.cn/doc

This article is a bit long and information-dense; you may want to bookmark it before reading. ~

1. Redefining the document: from “HTML strings” to a block-based data tree

The first soul-searching question in building a document editor is: what is the essence of a document?

The traditional rich text editor answer is “a styled HTML string”. That brings three unavoidable problems:

• Semantic ambiguity: the same visual result can correspond to countless HTML nesting structures, making cross-platform rendering consistency very poor.
• Difficult collaboration: diffing can only do coarse-grained comparison on strings, which easily leads to style corruption and content loss.
• Limited extension: adding complex structures like tables, whiteboards, and mind maps requires massive nested DOM, and maintenance costs rise exponentially.

We abandoned this path from day one. Mindlink's core choice is: a document is not a typesetting string, but an addressable structured data tree made up of blocks.

Core definition of the block model

In Mindlink, the smallest unit of a document is the “block”. Every block has a unique id, an explicit type, independent data, and mountable toolsets:

document = ordered array of blocks
block = { id, type, data, tunes }

We divide blocks into four major categories, covering most document scenarios:

• Basic text: paragraphs, headings, lists, quotes, code; content lives in data.text and supports inline style marks.
• Composite structure: tables, images, attachments, highlight blocks; data contains subfields and the block builds its own editable areas inside.
• Rich media: math formulas, mind maps, whiteboards; rendered by dedicated visualization panels, with edits written back to data.
• Extension metadata: dividers, anchors, comment toolsets; mounted as toolsets and provide cross-block collaboration.

Why is the block model a better solution?

Compared with flat HTML, the advantages of a block structure are fundamental:

1. Stable structure, zero ambiguity: a block carries an explicit type, content, and toolset, so serialization and deserialization do not produce semantic deviation, making it naturally suitable for consistent cross-platform rendering.
2. Minimal diff: editing a block only touches that block's data slice; collaboration sync and incremental persistence converge to block granularity, greatly reducing transfer volume and computation.
3. Composable capabilities: adding a new block type only requires registering a type definition; adding a new tool only requires registering a tune. No kernel code changes are needed.
4. Native rich-media nesting: scenarios that need internal nesting, such as tables, whiteboards, and mind maps, are carried gracefully by the block model instead of falling into HTML nesting hell.
5. Replayable operations: block-level insert, delete, move, and update are a natural change log, usable for collaboration merging, operation auditing, and version rollback.

This choice is the foundation of all subsequent collaboration capabilities, extension capabilities, and performance optimization.

2. The essence of collaboration: how CRDT achieves “write offline, merge without conflict”

Real-time multi-user collaboration is the core capability of online documents, but most users have experienced these pain points: when the network stalls, editing becomes impossible; simultaneous edits easily lose content; and remote updates make the whole page flicker.

Mindlink uses a three-part stack of CRDT + incremental frames + room sharding to solve these problems at the foundation.

Why CRDT, not OT?

There are two mainstream collaboration approaches in the industry: OT (operational transformation) and CRDT (conflict-free replicated data types). We firmly chose CRDT for two core reasons.

First, CRDT has no central authority and is naturally offline-friendly. OT depends on the server to globally order operations; the server is the absolute authority, and once the network is disconnected or the server fails, editing stops. CRDT is based on commutativity and idempotence, so every terminal can edit independently. Changes carry logical clock timestamps and site IDs, and merges are arranged by causality rather than physical time. No matter what order merges happen in, the final result is completely consistent.

Second, CRDT avoids paradoxes like “deleted text resurrection”. Many people have probably experienced this: you delete a piece of text, and then it mysteriously appears again. That is essentially caused by disordered OT operation ordering. CRDT's causal ordering mechanism fundamentally prevents this kind of problem.

In Mindlink's collaborative AI document implementation, we expose each block's data slice as a CRDT tree: key-value containers carry block attributes, and sequence containers carry block arrays and text fragments.

Any write initiated by a terminal is a merge, not an overwrite. When two users edit the same paragraph at the same time, content is not lost.

Incremental frame protocol: only send “what changed”, not “the whole document”

The root cause of lag in many collaborative editors is that every edit transfers a large amount of redundant data. Mindlink designed a compact binary incremental-frame protocol with the following logic:

• Every state update produced by a local edit is encoded as a 20–400 byte binary frame.
• The frame carries a “causal baseline version number”, so the receiver knows exactly which version the change is based on.
• The server does only two things: forward the frame to other members in the room, and append the incremental log to disk.

A normal keystroke produces a collaboration frame that is typically under 200 bytes. Even on weak networks, sync happens at second-level speed.

Room sharding and offline buffering

We shard at the room level by document: each document maps to a collaboration room, and memory holds that document's CRDT snapshot and the list of online members. After a connection is established, sync is completed in three steps: baseline exchange – delta catch-up – continuous mutual push.

1. The server sends the current state vector; the client compares it with the local baseline and calculates the missing deltas on both sides.
2. Each side sends an incremental frame, and the two ends align to the same version.
3. After that, each edit only sends the new increment, and the server forwards it to others in the same room.

The offline buffering mechanism is especially worth mentioning: when the network disconnects, the local CRDT continues to absorb all user edits without interrupting use at all. After reconnection, it automatically goes through the baseline exchange flow and silently fills in all missed increments in the background. Users barely notice that a disconnection ever happened.

End-to-end rendering consistency: saying goodbye to “whole-page flicker”

When remote changes are applied locally, if the DOM is fully redrawn every time, the result is a bad experience with jumping cursors and whole-page flicker. We solved this with these core optimizations:

• Semantic fingerprint diff: normalize and hash block content and structure, compare whether the meaning changed, ignore typographic detail differences, and skip redraw for blocks whose fingerprint is unchanged.
• Position + content dual-dimension diff: when remote updates arrive, identify the four minimal action types of insert, delete, move, and content change, and operate only on the corresponding DOM nodes.
• Cursor anchoring: when a remote block is inserted or moved, the local cursor anchor follows the corresponding block, so it is not pushed to an unexpected position by inserted paragraphs.

3. Four-layer architecture philosophy: decouple every layer, privatize every component

Technical architecture determines the boundaries of a product. Mindlink uses a strict four-layer architecture: presentation layer → kernel layer → collaboration layer → service layer. Layers align through stable interface protocols, and any layer can be independently replaced or degraded.

I drew an architecture diagram; those interested can refer to it:

The responsibilities of the four layers are as follows:

1. Presentation layer: responsible for the workspace, editor interface, table of contents, search, share preview, admin console, mobile adaptation, and all user-visible parts.
2. Kernel layer: block model and schema, command center, history and undo stack, toolsets, read-only/edit mode switching; this is the editor's core computational unit.
3. Collaboration layer: CRDT engine, automatic conflict resolution, rooms and snapshots, incremental frame send/receive, cursor awareness, offline buffering, change-log persistence and replay.
4. Service layer: REST API, long-connection gateway, authentication middleware, permission persistence, storage adaptation, operations monitoring.

This design brings two major advantages:

• Frontend and backend can be fully separated: the editor kernel does not assume a backend exists and can run completely offline; the service layer is optional, replaceable, and privatizable. You can embed Mindlink into a business system as a pure frontend component, or pair it with a complete server for private deployment.
• Capabilities are plugin-based: block types, toolsets, command palette items, and import handlers all connect through unified registration interfaces, so adding capabilities requires zero kernel changes.

Server-side design: thin gateway, strong cohesion, replaceable

For enterprise private deployment scenarios, the lightweight nature and compatibility of the server are crucial. We stick to the design principles of “thin gateway, strong cohesion, replaceable”, as shown below:

• All external protocols are concentrated at two entrances: the REST API and the long-connection channel, uniformly exposed through a reverse proxy, so the business side only needs to expose one port.
• Business modules are divided by domain: documents, users, permissions, sharing, comments, and AI gateway are each cohesive and not coupled to each other.
• The data access layer has a complete interface abstraction, supports one-click switching among SQLite / MySQL / Postgres, and defaults to embedded storage with zero extra database dependencies.

This is why Mindlink can achieve “one-click deployment on a single server”: it has a built-in reverse proxy, process daemon, and embedded database, so one Linux machine is enough to run it. It is very suitable for small and mid-sized enterprises and for rapid deployment on government and enterprise intranets.

4. Developer perspective: secondary-development friendliness is not just a slogan

I come from a developer background myself, and I know that the phrase “SDK-friendly” is easy to say and hard to do. Many products claim to support secondary development, but in reality their APIs are closed, documentation is missing, and changing anything requires touching the kernel.

From the very beginning of the design, Mindlink wrote “secondary-development friendliness” into its technical foundation. We provide a complete extension system, and developers can deeply customize the editor's capabilities without modifying the kernel.

Six extension capabilities cover most customization needs

1. Block type plugins: implement the four hooks of render / save / validate / toolsets to register a new block, with lazy loading support. Enterprises can quickly integrate their own business components, such as contract fields, work-order cards, and data charts.
2. Toolset plugins: append tools to the right side of a block or in a floating panel, such as “translate to English”, “generate summary”, and “sync to work-order system”. Toolsets are orthogonal to block types, and any block can combine different tools.
3. Command palette extensions: attach enterprise-specific actions to slash commands, such as “insert contract template”, “generate weekly report skeleton”, and “insert product component”. Employees can quickly invoke internal capabilities through /.
4. Import/export pipelines: customize data source handlers to connect to Confluence, Notion, internal CMS, and other systems; export also supports custom formats, making it easy to integrate into business processes.
5. AI provider adapter: uniformly wraps request bodies and streaming responses, and allows free switching of providers and model IDs in the admin console. AI capabilities are off by default; once enabled, all request routing is configured by the customer, and data never leaves the enterprise intranet.
6. Theme and style customization: light/dark themes + brand color override, with support for injecting custom CSS per tenant, so it blends into the visual system of an enterprise's own product.

Data is fully open; no vendor lock-in

We firmly believe that a good technical product should keep data in the user's own hands. Mindlink's block array can be output directly as standard JSON Schema, with clear structure and explicit semantics, so developers can easily connect document data to any external system.

Import supports Markdown and HTML; export supports PDF, Markdown, HTML, and structured data. Whether it is system migration or data integration, there are no barriers.

5. Founder's retrospective: some underlying beliefs about ToB technical products

From technical selection to product launch, we stepped on countless pitfalls, and there was also a lot of thinking. From a founder's perspective, I want to share a few underlying judgments about ToB technical products.

1. Private deployment is not a bonus; it is the entry ticket to enterprise-grade

More and more government, enterprise, finance, and manufacturing customers now have hard requirements that “data does not leave the domain”. No matter how good a SaaS-mode online document is, it cannot pass the compliance gate.

Our approach to private deployment is not to “move SaaS on-premises”, but to design for private deployment from the architecture level: minimal dependencies, one-click deployment, centralized configuration, and support for offline environments. The default is a single-file database, no extra middleware needs to be deployed, and ordinary operations staff can handle it.

2. Structured content is the future; the era of pure typesetting is over

Documents of the past were “typesetting tools”; documents of the future are “information carriers”. Formulas, code, mind maps, whiteboards, and even business components will all become part of documents.

Only a block structure can gracefully carry this heterogeneous content. That is also why we firmly took the block-based route instead of patching traditional rich text.

3. Performance is the baseline, not a selling point

Many products like to make “high performance” a selling point, but in my view, performance is the passing line. If opening a large document takes several seconds and typing a character stutters for a long time, no amount of features helps.

We set several hard metrics for ourselves:

• Block insert end-to-end response < 100ms
• Opening a 1000-block document < 500ms
• Single keystroke collaboration frame < 200B (typical)
• First-screen static resources < 30KB (gzip)

Through a series of engineering optimizations such as lazy loading, block-level virtual scrolling, semantic fingerprint diff, and persistence bypass, we ultimately met all of these targets.

4. Don't build an all-in-one suite; build a good foundation

Many document products on the market are getting heavier and heavier, eventually turning into big, all-encompassing platforms. But Mindlink's positioning is clear: we are not building a complete document platform; we are building the best collaborative editor foundation.

Developers can quickly build knowledge bases, product documentation systems, work-order editors, courseware systems, contract management systems, and more on top of Mindlink. We do the underlying editing, collaboration, and storage well, and leave the upper-layer business scenarios to developers.

6. Scenarios and future: block-based collaboration has far more imagination than documents

Based on the characteristics of block structure + real-time collaboration + private deployment, Mindlink already covers many vertical scenarios well:

• Team knowledge base / Wiki: hierarchical directories carry product documentation, development manuals, and operations SOPs; global search + comments + version rollback; many people revise simultaneously without conflict.
• Structured writing / technical reports: formulas, code, charts, and whiteboards mixed together; write once and export to multiple targets; very suitable for technical teams and research institutions.
• Government and enterprise intranet documents: fully deployed on the intranet, data does not leave the domain, invite codes + fine-grained permissions + audit logs, meeting compliance requirements.
• Product requirements / brainstorming: embedded whiteboards and mind maps; from discussion to conclusion to deliverables, everything is completed in the same document.
• Cross-enterprise joint editing: through share links + passwords + validity periods, upstream and downstream partners can temporarily participate in collaboration, with access automatically expiring and leaving no residual permissions.

But these are only the beginning. The future imagination of block-based collaboration goes far beyond the single form of “online documents”.

Our core directions next:

1. Continue to deepen the block model and expand dedicated block types for more vertical scenarios.
2. Deepen the combination of AI and the block model, not only continuation and rewriting, but also structured content generation and organization.
3. Improve the ecosystem, provide more out-of-the-box plugins and templates, and lower the integration cost for developers.
4. Continuously optimize the private deployment experience and support richer enterprise-grade integration capabilities.

Final words

From the first lines of code to the complete product launch, we stepped on many pitfalls along the way: various edge cases in CRDT merging, performance bottlenecks with large documents, compatibility issues in mobile adaptation... But we have always believed that a good technical product should have a solid enough foundation and flexible enough upper layers.

Building enterprise-grade tools is a slow road, but it is also a deep enough road. We do not chase trends or get caught up in buzzwords; we only want to do collaborative editing thoroughly and solidly, and provide developers and enterprises with a truly usable, controllable, and trustworthy block-based collaborative editor foundation.

If you are also building products related to collaborative office, knowledge bases, or enterprise content management, or if you have needs for a private-deployment collaborative editor, you are welcome to reach out and discuss.

Live demo: https://mindlink.turntip.cn

Technical documentation: https://mindlink.turntip.cn/doc

You are also welcome to study and explore Mindlink and give us your valuable feedback.