The setup. One server and three clients signed in as three different users, each also connected from a second window so every account was live on two devices at once. That arrangement lets a single machine exercise most of the distributed behavior that matters - cross-client delivery, cross-device state sync, and concurrent writes to the same channel. Each test case maps to a method the server actually implements, so nothing here is theoretical.

Server restart, mid-conversation. With messages in flight we killed the server process outright. Every client detected the drop within a couple of seconds and moved to a reconnecting state rather than erroring. When we restarted the server, all three clients re-established their sessions on their own in about six seconds, with no re-login. A reaction added just before the outage was still there afterward, and unread counts survived the restart intact, because read state is persisted to disk rather than held only in server memory.

The offline queue. While the server was down, we kept composing. Instead of failing, outgoing messages collected in a local outbox under a 'waiting to send' indicator. On reconnect, the queue drained automatically - and this is the part that matters - the messages arrived at the other clients in order and exactly once. No duplicates from an over-eager retry, no gaps from a dropped send. An outbox that double-delivers on reconnect is a classic distributed-systems failure, and it's the specific thing we were watching for.

Cross-device read state. With the same account open on two devices, we opened an unread channel on one and watched the unread badge clear on the other without touching it. Server-backed read state is a feature nearly every chat product claims and comparatively few verify across devices under observation. Ours now has a passing test with a date on it.

Simultaneous sends. Then we stopped being gentle. Three clients each fired a burst of twenty messages into the same channel at once - sixty concurrent writes. Every accepted message received a unique id, and all three clients converged on a single global ordering that matched to the character: no duplicates, no gaps, no lost events, and no disagreement between clients about what happened or in what order. Total-order consistency under concurrent writes is the hard part of a real-time chat system, and it held.

The defect, and the fix. A stress test earns its keep by breaking something, and this one did: very long messages were handled inconsistently. The client and server disagreed on how to count length - one measured UTF-16 code units, the other Unicode code points, so an emoji-heavy message could be counted two different ways - and on one path a message over the limit could clear the composer and vanish without an error, which reads to the user as silent data loss. We fixed it before publishing this post. There is now a single documented length limit enforced identically on client and server, counted the same way on both; a live character counter; an explicit over-limit message; and a hard guarantee that the composer never clears your text unless the server has actually accepted the message. We added tests at the limit, one under, and one over, on both the client and the server, and re-ran the full three-client check until it came back clean.

What's still open, in the open. A few smaller gaps came out of the same pass and are on the board rather than hidden: during a network outage the client currently blanks its cached view until reconnect - everything returns, but a local-first app should keep showing history while offline - message editing exists on the server without a UI yet, and there are a couple of cosmetic rough edges. Two cases were deferred rather than failed: the containerized self-host parity run, and the voice smoke test, which needs human ears and gates the next release tag.

Why we work this way. A month ago our own roadmap described intent and filed it under status; we've since made a rule that a capability only gets a checkmark when someone has watched it be true. Version 2.2 is now tagged with that standard met - networking verified end to end, stress-tested, and hardened against the one real failure the stress test found. That is what starts the internal alpha: not a claim that it works, but a dated record that it does, and an honest list of what's next.

The roadmap said networking was 'design accepted, implementation next'. It listed authentication, presence, the offline queue and self-hosting as planned work. Meanwhile the repository contained an authentication crate, a presence crate, an offline outbox with its own test suite, a migration system with backup and restore, and a compose file for self-hosting. Voice and screen sharing were listed as not started - they had shipped across five phases, hardening included.

The documents were not lying. They were written once and never re-measured, while the work kept moving underneath them.

What makes this worth writing about is how nearly we corrected the wrong side. Our website described features the roadmap said did not exist. The obvious reading is that the marketing site was overclaiming, and 'fix the site to match the roadmap' would have looked like diligence. It would have quietly deleted a large amount of genuinely shipped work from the public record - and it would have been justified by an official-looking document.

So the rule we settled on is simple: when a document and the code disagree, the code wins. A roadmap describes intent at the time of writing. It does not update itself, and age alone gives it no authority.

The roadmap now reflects what is actually built. We also added a marker for work that exists and is tested but has not yet been exercised end-to-end, because fixing a document that overstated its confidence by overstating ours would have missed the entire point.

LynxBench is our attempt at the opposite. It is a hardware diagnostics and repair-knowledge effort running alongside the communication platform, and the goal is genuinely ambitious: build the most comprehensive structured repair knowledge repository we can, in a form that both people and machines can reason over.

**The problem with how repair knowledge is stored today.** A service manual tells you the official procedure. A forum thread tells you what worked for one person on one unit. Neither tells you *why*, and neither connects to anything else. There is no structure that says this component depends on that rail, that this symptom has four plausible causes ranked by likelihood, or that this measurement rules out three of them. Without that structure you cannot reason - you can only pattern-match, which is exactly the skill that lives in someone's head and dies with them.

**What we're building instead.** At the centre is a hardware knowledge graph: components, subsystems, the relationships between them, and how failures propagate along those relationships. On top of that sits structured troubleshooting - decision paths where each step is a measurement that meaningfully narrows the space, rather than a checklist someone follows to the end and then guesses anyway.

Underneath is the physical layer: PCB mapping and component identification. A surprising amount of this starts as hand-drawn board maps - someone tracing a real board, marking what connects to what. Those get digitised and turned into structured records, which is what lets the graph reason about a physical object instead of an abstraction. It is slow, unglamorous work, and it is the foundation everything else rests on.

**Evidence is the discipline.** Every verification produces a structured evidence record: what was tested, what was observed, and whether it confirmed or contradicted the expectation - including attempts that captured nothing useful. That last part matters more than it sounds. Recording failed captures is what separates a knowledge base from a highlight reel, and it is the difference between something you can trust and something that merely sounds authoritative. A claim about hardware behaviour with no capture behind it is an opinion, and opinions do not belong in a repair record.

**Where AI fits.** Not as an oracle. We use AI-assisted research pipelines to do the part that is genuinely mechanical: reading large volumes of scattered documentation, extracting candidate relationships, and proposing structure for a human to confirm or reject. The architecture deliberately separates observation from reasoning - one layer records what actually happened on the bench without interpreting it, another reasons over those observations against the graph. Keeping them apart means a wrong conclusion never contaminates the underlying record, and you can re-reason over the same capture later and get a better answer as the graph improves.

**Documentation standards are the product.** Twelve architecture decisions are recorded so far, because a repository like this is only as durable as its conventions. If two people record the same observation in two different shapes, the graph degrades into a filing cabinet. Deciding early how things are written down is not bureaucracy - it is the thing that makes the knowledge compounding rather than merely accumulating.

**What another engineer can take from this.** If you are building any kind of knowledge system, the transferable parts are these: separate raw observation from interpretation so you can revise conclusions without losing data; record negative results, because a knowledge base that only contains successes cannot be trusted; and settle your documentation conventions before volume arrives, not after.

We are keeping specific findings, interface details and protocol parameters private for now. The methodology is the part worth sharing - and the part we would want to read.

The failures worth engineering against are the invisible ones - where the tooling reports something confidently false and every downstream decision inherits the error. We hit one of those, and the process we built in response is the part worth sharing.

**The failure mode.** A mounted filesystem served files shorter than they actually were, truncated mid-token. Every tool reading through that mount saw the short version with no indication anything was wrong. Version control then compared the truncated content against the real repository and reported modifications that did not exist. Staging those would have committed the truncation - deleting working code nobody had touched, in a diff that looked completely reasonable to a reviewer.

That is the shape of the dangerous class: not a wrong answer, but a wrong *measurement* that produces a plausible wrong answer. No amount of careful review catches it, because review operates on the same corrupted input.

**Make the rule executable, not written.** Our first instinct was to document the hazard. That instinct is wrong. A warning in a document is a warning someone skips at 1am, and the person most likely to skip it is the one moving fastest. So the rule became a program: a preflight check that runs before any session touches version control, verifies the environment, and **fails closed**. It takes about two seconds, has no dependencies, and carries its own test suite - because an unverified safety check is decoration.

The design principle: if a rule matters, it should be impossible to proceed without satisfying it. Anything less is a suggestion.

**Treat every handoff as a hypothesis.** The second half is cultural. When work spans many sessions - human or AI - each one inherits a summary of what came before, and those summaries are where errors calcify. On a single day, three inherited claims collapsed the moment anyone measured them: a file count that was wrong, a set of tests reported as deleted that were entirely present, and a batch of errors described as outstanding that had already been fixed.

The middle case is the instructive one. It began as a measurement error, got written into prose, and from there acquired the authority of a fact - propagating through two handoffs unchallenged. Prose is remarkably good at laundering uncertainty into confidence. A number in a sentence reads as established; the same number in a tool output reads as a reading you might want to re-take.

So the standing instruction is to re-derive state from the repository at the start of every session rather than trusting the summary, however authoritative it reads. State is cheap to measure and expensive to assume.

**What another engineer can take from this.** Three things generalise. First, distinguish failures your review process can catch from ones it structurally cannot, and spend your engineering effort on the second category. Second, encode critical rules as programs that fail closed, because documentation degrades into folklore. Third, in any workflow with handoffs, build in a re-measurement step - the cost of verifying inherited state is far lower than the cost of one confident, wrong inheritance reaching production.

LynxDock now checks the file instead of the filename. Every attachment is read at the front, and its leading bytes - its signature, or magic number - are compared against the type it claims to be. All eight permitted types carry a real signature check.

Where that check lives matters as much as the check itself. It runs inside the storage call rather than in the interface, so no alternative code path can reach the disk without passing it. If the bytes and the claimed type disagree, the write is refused with a plain error rather than quietly accepted.

The part we would point at in review is not the feature, it is the negative test. We take a genuine image, rename a binary to sit beside it wearing the same extension, and assert that the second one is rejected. A security control without a test proving it says no is a hope, not a control.

This is deliberately narrow. It is not malware scanning and it does not make arbitrary files safe. It removes one specific lie - the claim a filename makes about what it contains - which is the lie this particular door was open to.

The first phase was the control plane - who is in the call, who is muted, who is sharing. That state travels over the same WebSocket connection the app already maintains, and it is kept deliberately separate from the media itself. Knowing who is in a room should never depend on the audio pipeline being healthy.

Then the media plane. We settled on an SFU rather than mesh, so a call with six people does not ask every laptop to encode five outbound streams. The server mints short-lived, room-scoped access tokens along with relay credentials, which means clients never hold long-lived secrets and calls still connect from behind restrictive networks.

Phase three made it real on the desktop: publishing your microphone, hearing everyone else, an active-speaker ring so you can see who is talking, deafen, and proper input and output device pickers. We also handled the browser autoplay problem explicitly - if audio is blocked, the app tells you and offers a single click to unblock, instead of appearing to work while you hear nothing.

Phase four added screen sharing on the same foundation, with a multi-tile viewer so more than one person can share at a time. Phase five was hardening, which is the part that usually gets skipped: media connection state is surfaced in the UI, failures are classified into real causes with a retry path, and each participant carries a small connection-quality indicator so a bad call is diagnosable instead of mysterious.

That closes Epic 5, and it arrived ahead of its position in the original roadmap order. File transfer runs over the same media plane and is the next thing up.

We started with the boring part - a status contract. Every component describes its health in exactly one shape, and the overall state is a worst-wins roll-up, so one degraded piece cannot be averaged away into a comfortable green. That status is generated into a single artifact which both the desktop app and this website read. One source, no drift between what we tell ourselves and what we tell you.

On top of that sits the hub. Modules report metrics and entities, and those are aggregated into a single state. It works in two tiers with an identical shape: a generated static snapshot, and a live feed over the WebSocket hub. The static tier means the board is never blank; the live tier means it is current when a server is actually running.

The live feed is where it gets useful. The server reports its open connections, active voice rooms and participant counts, and host CPU and memory. Commander reports squadrons and operations, and those can be created directly from the desktop app. An event bus retains recent history and replays it into a live timeline, so you can see the last several dozen things that happened rather than only the current instant.

The design rule we kept coming back to is that it should degrade honestly. If a source is not connected, the board says so plainly rather than inventing a healthy-looking number. That is why you may currently see components reporting as unknown - the generator has not been re-run against real release data yet. We would rather show an honest unknown than a false green.

Dashboards, an integration layer, and a view of the AI workforce are designed and queued next.

So we built a collector. It tracks reported sessions in a short-lived store, de-duplicates them with a clear precedence rule when the same session is seen twice, and assembles the result into a module snapshot in the same shape every other part of the system uses.

It runs behind a small localhost HTTP service with two endpoints - one to report a session, one to read the snapshot - verified end to end. Alongside it there is a reference reporter for wiring up your own tooling, a deliberately conservative process-scan fallback for when nothing reports itself, and a one-shot snapshot command suitable for a scheduled job.

The output flows into the same hub file Mission Control already reads. That is the part that matters: development activity becomes a first-class module sitting next to the server and the desktop app, rather than a separate dashboard nobody opens. There are reference adapters too, including a local model runner and a generic subprocess wrapper, plus a health adapter that pulls in the state of an external repository.

The whole collector has zero runtime dependencies and is covered by its own test suite. It is a small piece of infrastructure, but it turns a stream of disposable sessions into something with a memory.

Messaging went networked. Read state is server-backed and syncs live across devices, so opening a channel on one machine clears the unread badge on another. Messages carry real display names resolved over the wire, and desktop notifications are mention-aware, with the unread count shown in the window title.

The app now holds up on a bad connection. An offline outbox queues messages while you are disconnected, de-duplicates them, and drains automatically on reconnect - with a small 'N queued' indicator so you always know where things stand. Losing Wi-Fi mid-sentence no longer loses the sentence.

Voice and screen sharing are real. We settled the call architecture on an SFU (LiveKit) with a clean two-plane split between control and media, then built the media plane itself: joining audio, device selection, deafen, and screen share, with hardening along the way. It is the start of Epic 5, arriving earlier than the roadmap promised.

Search got fast. Message search is backed by SQLite's FTS5 full-text index, with a safe fallback, and you can scope a search to one channel or all of them and filter to messages that carry attachments.

Underneath, reliability improved in ways you will never see: a versioned migration framework with automatic backup and restore means upgrades never lose data, and the server gained backup / export / import maintenance commands. A new System Status board surfaces live health inside the app's mission-control view.

All of this is still pre-release - we are at 0.1.0-alpha and building in the open. But the shape of the product is now visible: private by default, local-first, and increasingly connected on your terms. Follow along on the roadmap and on GitHub.

The infrastructure layer is finished: GSpec (a versioned specification), the Bootstrap compiler that turns it into artifacts, release tooling that produces signed manifests, and CI that holds the line. A Golden-IR contract test guarantees the compiler's output never drifts.

On top of that we've stood up a single product monorepo. It spans TypeScript and Rust: shared libraries, a protocol package whose wire types are generated from Rust to TypeScript, our own component framework (Genesis UI), a Tauri desktop app, a Studio surface, a plugin SDK, and AI tool contracts.

The desktop app already runs a local workspace, identity, and settings, plus a local-only chat client. It isn't networked yet - that's deliberate. We're building the product from the inside out, so each layer is solid before the next depends on it.

Version 2 is where LynxDock stops being infrastructure and starts being an application. This site now reflects that reality.

Rust gives us memory safety without a garbage collector, which means a small, calm resource footprint and no surprise pauses. It's a good fit for a desktop app that should feel instant and stay light, even on modest hardware.

The desktop app is built on Tauri: a Rust core with a web front-end. Storage, identity, workspace, and messaging all live in Rust, exposed to the UI through a handful of typed commands. The server, when it arrives, will be Rust too.

Rust also anchors our protocol. The wire types are defined once in Rust and generated into TypeScript, so the client and a future server can never quietly drift apart. CI fails if the generated types are out of date.

None of this is visible in the UI - and that's the point. The right foundation is the one you never have to think about.

At its base are design tokens - color, type, spacing, motion - expressed as CSS variables and mirrored in TypeScript. Components read the tokens; they never hard-code a value. That single indirection is what makes theming possible.

On top of the tokens sits a runtime theme engine. Switching between dark and light (or following the system preference) is a matter of setting one attribute on the page; a reduced-motion mode collapses animation for people who prefer less movement. The desktop app already uses this to apply your settings live.

Genesis UI is framework-agnostic where it counts: links and images are injected, so the same components work in Next.js on the website and in a plain Vite app on the desktop. A Tailwind preset carries the palette so utility classes line up everywhere.

It's early - the component set is still growing toward a full 'FluentUI for LynxDock' - but the foundation is in place, and this website is styled with the same language the app uses.

Concretely: the desktop app stores your workspace, identity, and messages on your own machine. Telemetry is off by default, and the app tells you so with a visible status indicator - not buried in a settings page. There's no account to create just to open the app.

The architecture reinforces the promise. Because state is local-first, there's simply nothing to harvest by default. When networking arrives, it will be something you opt into - a server you run or choose to join - not a cloud you're silently enrolled in.

Privacy also shapes what we don't build: no engagement loops, no dark patterns, no notifications engineered to pull you back. Restraint is a feature.

The goal is software whose incentives are aligned with the person using it. Built for people, not platforms - starting with where your data lives.

LynxDock is a lightweight communication platform. Start a spontaneous peer-to-peer call for voice, chat, and screen sharing, or settle into a persistent, self-hosted community with accounts, rooms, history, and admin controls. Either way, your accounts and data stay with the server you choose - not with us.

Self-hosting has a reputation for being painful. We're changing that. The Guided Server Setup wizard generates a real config with sensible defaults, a random session secret, and safe self-hosting options - no config files or terminal commands required.

LynxDock is one part of a larger ecosystem. LynxDock Studio is an AI-assisted development workspace that links docs, sprints, architecture, and research into a single navigable graph. LynxDock Bootstrap is the automation engine that turns a blank slate into a structured foundation in minutes.

We're early, and we're building in the open. Follow the roadmap, star the repositories, and register interest for early access. This is just the beginning.

Under the hood it's a Next.js and TypeScript site styled with Tailwind CSS, exported as fully static files and served on Cloudflare Pages. No runtime server, no database, no heavy client libraries. The whole thing is generated ahead of time for speed.

The design language borrows the vocabulary of the app itself: a dark graphite base, thin cyan hairline borders, translucent glass panels, and subtle glow. The logo is the visual anchor; the product screenshots are the proof.

Everything you see here is intentionally minimal. Short copy, generous space, and just enough motion to feel alive without getting in the way. That restraint is the point - it's the same philosophy that drives the products.

Self-hosting is the antidote: run the server yourself, and the accounts, history, and files belong to you. LynxDock is being built so that a self-hosted server is a first-class target, not an afterthought.

Historically self-hosting meant config files, secrets, and terminal commands - enough friction that most people never tried. Our aim is to make standing up a server approachable, with sensible defaults and a guided path, so ownership doesn't require a sysadmin.

Networking and servers are on the roadmap (Epic 3 and Epic 4). We're building the local experience first so that when the server lands, it's syncing something that already works - not the other way around.

The long view: a lightweight, self-hostable communication tool shouldn't be a luxury. It should be the default for anyone who cares where their data lives.

Privacy-first means a few concrete things at LynxDock. We don't run advertising. We don't sell data. We don't track you across the web. And when you self-host, your community's messages, accounts, and files live on infrastructure you control - not ours.

It also shapes what we don't build. No engagement-maximizing dark patterns. No notifications engineered to pull you back in. No hidden data flows. Restraint is a feature: the calmest software is often the software that respects your time.

Why now? Because the tools people rely on to talk, build, and organize have quietly consolidated onto a handful of platforms, each with its own incentives. A lightweight, self-hostable alternative shouldn't be a luxury. We think it should be the default for anyone who cares where their data lives.

That's the bet behind everything we ship: built for people, not platforms. If that resonates, follow along - we're building it in the open.

Epic 0 (Foundation) and Epic 1 (Workspace & Identity) are complete. Epic 2 (Local Messaging) is in progress: channels and messages you can compose, edit, delete, and search, all stored locally.

From there: Epic 3 brings networking - a WebSocket transport, a handshake, authentication, and a self-hostable server. Epic 4 adds communities and servers; Epic 5 adds voice and screen sharing over WebRTC. Epics 6-8 cover AI, plugins, and Studio.

We're deliberately building local-first. Each epic stands on solid ground before the next depends on it, which keeps the product honest and the foundation clean.

You can follow the whole sequence on the roadmap, and watch it happen in the open on GitHub.

LynxDock's Guided Server Setup is designed to remove that tax. It's a calm, first-run wizard that walks you through five short steps: choose a purpose, set the basics, pick your access rules, configure the call relay, and start the server. No config files. No terminal.

Under the hood it generates a real configuration - a SQLite database, local uploads, a randomly generated session secret, and safe self-hosting defaults. You can save a draft at any point and come back later; nothing is committed until you choose to generate and launch.

When you're ready, you set a port (8080 by default), pick a data folder, and choose whether registration is invite-only, open, or closed. For calls and screen sharing, the basic STUN-only mode works for most setups, with the option to add a TURN relay for tougher networks.

The result is a server that belongs to you and your community, spun up in minutes. For the full walkthrough, see the Self-hosting guide in the docs.