Yandex Docs: A Tunnel Inside an Editor’s Workflow

OpenFlux’s Yandex transport is not simply a WebSocket with a different URL. It first turns a document page into session state, then speaks enough of the editor’s browser-shaped protocol to move packet bytes through that state. This chapter follows that lifecycle—from document metadata to cursor messages, queues, keep-alives, and reconnects—and uses it to separate the reusable tunnel boundary from the fragile assumptions borrowed from a third-party editor.

The document page is a session bootstrap

The Yandex Docs path begins with a document URL, but the URL is not itself the packet channel. The client fetches the page and looks for a structured client-config object embedded in the HTML. From that configuration it extracts document information, permissions, a token, cookies, and the balancer address that will host the editor session. The document key and other editor fields are then used to build the WebSocket connection and its opening messages.

This first stage explains why a public-looking document link can be a structured authentication and configuration entry point. OpenFlux needs more than a hostname. It needs the page’s current shape, the fields that identify the document, and the session material that the editor expects. If the page is private, redirects to login, uses a different editor, or omits a field that the parser expects, the carrier cannot start. The failure occurs before the tunnel sends its first packet.

The adapter also presents itself in a browser-like way. It supplies a user agent, origin, cookies, and host information when opening the WebSocket. After the connection succeeds, it sends editor-shaped authentication and open-session messages. Those messages are not part of the generic Transport contract; they are the price of borrowing the document editor’s workflow. The common tunnel only knows that the adapter eventually becomes ready to accept and deliver byte payloads.

The parser’s error handling makes the dependency concrete. It limits redirects, reports when a response looks like a login page, rejects malformed configuration JSON, and refuses to continue when the expected editor or document fields are absent. That is good boundary behavior: an invalid session should fail before packet traffic is silently sent into an unknown service state. It also means the adapter’s first responsibility is not carrying packets but recognizing whether the external application still exposes the contract OpenFlux has learned to imitate.

sequenceDiagram participant Core as OpenFlux tunnel participant Page as Document page participant Socket as Editor WebSocket participant Queue as Write queue participant Remote as Remote session Core->>Page: Fetch document HTML Page-->>Core: client configuration and session fields Core->>Socket: Open browser-shaped session Socket-->>Core: WebSocket connected Core->>Socket: Authenticate and open document Socket-->>Remote: Editor session messages Core->>Queue: Enqueue packet bytes Queue->>Socket: Cursor-style message with encoded payload Socket-->>Remote: Carry packet payload Remote-->>Socket: Cursor or saved-change message Socket-->>Core: Encoded payload Core->>Core: Decode and deliver packet bytes Core->>Socket: Periodic keep-alive Socket-->>Core: Session closes or remains open Core->>Page: Refetch metadata after reconnect