Today we are publishing the first preview of TXTextControl.Web.Collaboration 34.0.6-alpha, a new package for building collaborative document editing experiences with the TX Text Control ASP.NET Core Document Editor. TX Text Control gives every editor a rich, independent document surface. That is ideal for a single author, but live collaboration adds a second problem: Several people need to make changes to one shared document without guessing which local editor copy is current. The collaboration package addresses that problem with server-authoritative rooms, protected access links, presence indicators, a sharing bar, partial TX Text Control document updates, and defensive reconciliation. The server owns the master document. Every connected editor works with that same room rather than with an unrelated copy. First preview releaseTXTextControl.Web.Collaboration 34.0.6-alpha is available now on NuGet. The package is an alpha preview intended for evaluation and early integration feedback. Why Live Collaboration Needs a Room A collaboration room is the shared home for one document. It has a room ID, an authoritative TX Text Control master document, a current version, a set of connected participants, and protected access tokens. Creating a room does not change the original source file. It creates a live editing session around a TX Text Control copy of that source. When an author joins a room, the package loads the current master document into that author's editor. When the author pauses after making a change, the package captures the changed TX content, applies it to the server master, and broadcasts the resulting update to other editors. The master is always the point of agreement. This is especially important when authors work in different parts of a long document. Independent paragraph and table changes can be processed as small, partial updates. If an update is structural, ambiguous, or cannot be applied safely, the package keeps a complete-document recovery path instead of risking an incorrect partial update. Server-Authoritative Synchronization The initial preview is optimized for the current server-hosted Document Editor. Each editor connection has its own TX Text Control connection ID. In ServerSide mode, the collaboration package uses the server-side TX Text Control WebSocketHandler to capture and apply document ranges without sending the complete document through the browser for ordinary edits. Behind the room is an isolated TX Text Control worker pool. A room is consistently assigned to one worker, while different rooms can be processed by different workers. This respects the critical sections inside ServerTextControl while allowing a busy application to process multiple documents concurrently. The synchronization pipeline is intentionally defensive: The browser tracks editing activity, cursor presence, and an idle period. The server captures the current editor document and resolves the affected paragraph or complete table against the authoritative master. The worker applies the TX Text Control fragment to the master and publishes the new version. Receiving editors apply a partial TX Text Control update when it is safe, preserving their visual caret and scroll position. Periodic reconciliation compares the complete editor document with the master so a change missed by an editor event is recovered. For concurrent changes, the server serializes accepted updates. Changes in separate regions can be rebased. When two authors change the same region at the same time, the first accepted update wins and the other editor is reconciled with the master. Install the Preview Package A new ASP.NET Core application needs the TX Text Control Core SDK, the Web Document Editor package, the Document Editor backend, and the collaboration package: # Install the TX Text Control document editor and collaboration packages. dotnet add package TXTextControl.TextControl.Core.SDK --version 34.0.4 dotnet add package TXTextControl.Web --version 34.4.0 dotnet add package TXTextControl.Web.DocumentEditor.Backend --version 34.4.0 dotnet add package TXTextControl.Web.Collaboration --version 34.0.6-alpha New-BlogGist The collaboration package depends on the Core SDK and TXTextControl.Web packages, but the backend package is added explicitly by the application because it owns the Document Editor backend process. A valid TX Text Control license is required. Register Collaboration Services The server registration follows the existing TX Text Control Document Editor setup. Register the collaboration services, start the Document Editor backend, enable WebSockets, register the TX WebSocket middleware, and map the collaboration hub: using TXTextControl.Web; using TXTextControl.Web.Collaboration; using TXTextControl.Web.DocumentEditor.Backend; var builder = WebApplication.CreateBuilder(args); builder.Services.AddControllersWithViews(); builder.Services.AddDataProtection() .SetApplicationName("MyCollaborationApp"); builder.Services.AddTXTextControlCollaboration( builder.Configuration.GetSection( TxTextControlCollaborationOptions.DefaultSectionName)); builder.Services.AddHostedService<DocumentEditorWorkerManager>(); var app = builder.Build(); app.UseStaticFiles(); app.UseRouting(); app.UseWebSockets(); app.UseTXWebSocketMiddleware(); app.MapControllerRoute( name: "default", pattern: "{controller=Home}/{action=Index}/{id?}"); app.MapTxTextControlCollaboration(); app.Run(); ASP.NET Core Data Protection protects room access tokens and invitations. For a multi-server deployment, use a shared Data Protection key ring, a room store accessible to all instances, and sticky routing for the collaboration hub and the editor WebSocket connection. Create a Room from Your Document Store The package does not dictate where an application stores documents. Create a room from a TX file path with CreateRoomFromFileAsync, or load TX bytes from a database or object store and use CreateRoomAsync. The returned access token is suitable for the room URL. using Microsoft.AspNetCore.Mvc; using TXTextControl.Web.Collaboration; public sealed class DocumentsController( ITxTextControlCollaboration collaboration, IDocumentStore documents) : Controller { public async Task<IActionResult> Collaborate( string documentId, CancellationToken cancellationToken) { var filePath = documents.GetServerPath(documentId); var userName = User.Identity?.Name ?? "Document owner"; var room = await collaboration.CreateRoomFromFileAsync( filePath, userName, cancellationToken); return RedirectToAction("Room", new { room = room.AccessToken }); } } Applications can create additional protected access tokens for authorized users with CreateRoomAccessAsync. The package provides the secure room mechanism; the application remains responsible for its authorization decisions and source-document lifecycle. Connect the Editor and Collaboration Bar The collaboration package includes a Razor Tag Helper. Register it once in Views/_ViewImports.cshtml, then add an empty tx-collaboration element next to the Document Editor. The Tag Helper renders the collaboration web component and automatically adds the versioned JavaScript and stylesheet. No manual collaboration script reference is required. @using TXTextControl.Web.MVC @* Register this once in Views/_ViewImports.cshtml: @addTagHelper *, TXTextControl.Web.Collaboration *@ <tx-collaboration room-token="@Model.AccessToken" /> <div id="collaborationEditor" data-tx-collaboration-editor style="height: 720px;"> @Html.TXTextControl() .TextControl(settings => settings.Dock = TXTextControl.Web.DockStyle.Fill) .Render() </div> The component locates the element marked with data-tx-collaboration-editor, joins the room, loads the current master document, and manages the collaboration UI. Presence, Sharing, and Visual Feedback The collaboration bar shows the people currently working in the room, the current synchronization state, and a Share button. A generated invitation URL includes the selected user identity, an expiration, and a unique nonce. The invitee opens the URL and joins the same server room. Presence is visible in two places. The room bar provides a compact overview of participants. In the document, user caret overlays identify where collaborators are working. When a collaborator is outside the visible editor viewport, the presence marker becomes a sticky top or bottom indicator. It returns to the document position when that region comes into view. Partial and complete updates are also surfaced in the collaboration UI. The Included Sample Application The complete sample application is available on GitHub at TextControl/TXTextControl.Web.Collaboration.TestApp. It is a practical starting point for integrating the package into an existing document portal. The sample presents a small document library. It lists TX and DOCX source documents, creates one active collaboration room for each selected source, and lets users reopen that room instead of creating duplicates. It also stores the relationship between source documents and rooms so the library can be restored after an application restart. Collaboration itself always works with TX Text Control Internal Unicode Format. The sample therefore uses ServerTextControl to convert DOCX to TX before creating a room. When the editor is finished, the document library offers an explicit Save to source command. It exports the authoritative TX master and converts it back to DOCX when the original source was a Word document. This separation is deliberate. Room persistence protects the live master document under App_Data/CollaborationRooms; it does not silently overwrite the source document. The application decides when the room should be published back to its file system, database, or object store. The sample also hashes the source file and prevents an overwrite if that file changed outside the room. Configuration and Recovery The sample uses two isolated TX workers, server-side editor access, 400 milliseconds of edit idle time, fragment uploads, 25-second reconciliation, and file-system room persistence. These values are intentionally visible in appsettings.json so they can be adapted to document size, user activity, and hosting capacity. For example, a larger worker pool can improve throughput for many active rooms, while a longer idle period reduces update frequency. Reconciliation remains useful even when fragment updates are fast because it verifies the complete document after idle time and repairs a state mismatch that a document editor event might not have reported. Source document ownership stays with the applicationCreate rooms from a server file or TX byte array, let the collaboration package maintain the live master, and call ExportDocumentAsync when your application is ready to publish the current room state back to its own storage. Try the Preview Install TXTextControl.Web.Collaboration 34.0.6-alpha, run the sample application, open the same room in two browser sessions, and start editing. The preview is designed to make the room, source of truth, synchronization path, and persistence model explicit from the beginning. We are excited to hear where you would use collaboration in your document workflow and which document types, deployment topologies, and editing scenarios you would like us to cover next. Frequently Asked Questions What is a collaboration room? A room is the server-authoritative collaboration session for one document. It has its own room ID, TX master document, current version, connected participants, and protected access tokens. Authors join the same room to collaborate on the same document. Does the package support DOCX files directly? The collaboration engine works with TX Text Control Internal Unicode Format. An application can load a TX file directly or convert DOCX to TX with ServerTextControl before creating a room. The included sample demonstrates both directions, including converting the exported TX master back to DOCX when saving the source file. Is the complete document sent through the browser after every edit? Not for normal edits when ServerSide synchronization and direct editor access are enabled. The package captures and applies TX fragments through the server-side TX WebSocket handler. It retains a complete-document path for structural, ambiguous, oversized, and recovery situations, plus periodic reconciliation. How are concurrent changes handled? The server is the source of truth and accepts changes sequentially. Changes in independent document regions can be rebased and distributed as partial TX updates. When authors update the same region at the same time, the first accepted server update wins and the other editor is reconciled with the authoritative master. Can an application keep documents in its own file system, database, or object store? Yes. The application supplies a server file path or TX byte array when it creates a room. It decides where the source document lives and when the current master is exported and saved back. The package can persist active room state with its built-in file-system store or a custom ICollaborationRoomStore. Is this package production-ready? This is the first alpha preview release. It is intended for evaluation, feedback, and early integrations. Production deployments should validate their document types, hosting topology, persistence, authorization, and recovery behavior before rollout.