NextChat and the Boundary Problem
NextChat is an open-source AI assistant that puts one conversation interface in front of many model providers, deployment modes, and optional tools. The important question is not only how it produces a reply, but where the prompt, conversation state, credentials, and generated result travel while that reply is being produced. This series uses that boundary question to give readers a practical way to understand NextChat and judge whether its choices fit their own use.
More than a chat window
A model provider supplies the language model, but it does not define the whole experience that NextChat offers. The repository presents NextChat as a web and progressive web application, a desktop application, and a self-hostable service. It supports commercial and self-hosted models, streaming responses, Markdown rendering, prompt templates, image-capable conversations, artifacts, plugins, realtime chat, and optional synchronization. Those capabilities belong to one product, but they do not all run in the same place or obey the same data rules.
That distinction matters because a user sees one conversation even when several systems participate in it. The browser may hold the session and its settings. A web deployment may forward the request through a server-side edge route. A desktop build may send it through a native transport. The selected provider may require a different message format from the one the user interface uses. An optional tool may call another API, while an artifact may be stored so that someone with a link can retrieve it later.
Calling all of this “the chat” hides the decisions that make the product useful. NextChat is better understood as a set of boundaries joined around a conversation. Each boundary answers four questions: what crosses it, who controls the state, what triggers the transition, and what happens when the next system cannot accept the request.
The solid path is the ordinary shape of a request: the client uses local session information, reaches a provider through one of two delivery paths, and receives a response. The dashed paths are not interchangeable variations of that request. They are additional choices that can create new storage locations, external API calls, executable actions, or media streams.
Consider a user who opens a new conversation, selects a model, and asks for help drafting a report. The visible action looks singular, but it creates several transitions. The client reads the current session and its mask, decides which context belongs in the request, and chooses an adapter for the selected provider. In a web deployment, the request then crosses into a server route, where authentication and upstream forwarding are handled. In a desktop build, the native transport can take a more direct route. The provider returns a response in its own streaming format, and the client turns those chunks into the assistant message stored in the session.
At no point does one system own the entire interaction. The browser owns the working session, the deployment may own the forwarding policy, the provider owns model processing, and an optional tool or storage service may own a later side effect. A failure or privacy consequence can therefore appear at a boundary different from the one the user touched. A reply that arrives all at once may be a proxy-buffering problem rather than a model problem. A conversation that seems local may still have been sent to a remote provider. A useful architecture map must follow these transitions instead of treating the screen as the system.
The four boundaries that shape the product
The first boundary is conversation state. NextChat keeps sessions, messages, masks, model settings, and summaries in persistent client-side stores. In the default browser design, those stores use IndexedDB and fall back to local storage when necessary. This is what the project means when it describes itself as privacy-first and locally stored: the working conversation is not automatically placed in a NextChat database merely because the user is chatting.
That ownership gives the client useful control. A user can keep several sessions, fork a conversation, change a mask, or clear the context used for future requests without waiting for a central account service. It also makes the browser profile an important security boundary. Anyone who can access that profile may be able to reach the stored state, and the open-source path does not show encryption layered over these browser stores. Local ownership is real, but it is not the same as protection from every local or remote observer.
The second boundary is request transport. A normal web deployment uses internal API routes that can inject server-managed credentials, forward a request, and pass the provider’s response back to the browser. A desktop build can use a native Tauri transport to make the request more directly. The choice changes the location of the endpoint and the role of the server, but it does not remove the need to trust the selected model provider. The prompt still has to reach that provider for a reply to be generated.
Transport also determines who can change the request on its way out. A web server can enforce a model policy, select an environment-provided key, or adapt headers before forwarding. A direct desktop path places more endpoint and credential configuration in the client environment. Neither path is simply “inside” or “outside” the user’s control: each moves control to a different operator and creates a different place to inspect when a request fails.
The third boundary is provider semantics. NextChat offers one interface, but providers do not necessarily accept the same roles, image representation, safety settings, tool schema, or generation parameters. The client therefore translates the shared conversation into provider-specific requests. A model selection menu can make the experience look uniform; it cannot make the underlying services uniform.
This translation is part of the product’s meaning, not just plumbing. The adapter may omit a system message for a model with different rules, combine neighboring roles, convert an image into inline data, or change how a tool call is represented. The user still experiences one conversation, but the exact contract with the model depends on the selected provider and model. A portable setting is portable only where those semantics line up.
The fourth boundary is capability extension. A normal answer is text returned from a model. A plugin can turn model output into an API call. MCP can connect model output to a configured server-side process. An artifact can turn generated HTML into a retrievable shared object. Realtime chat can send audio through a separate low-latency session. These features expand what the assistant can do, but each one introduces a different execution location and a different trust question.
The extension boundary is easy to miss because its result may appear in the same chat history as an ordinary answer. A tool result can be fed back into the conversation, an artifact can be opened from a shared link, and a voice transcript can become another stored message. The visible interface reunifies those outputs after their work has happened elsewhere. Understanding the feature therefore requires following the action or media, not only reading the final text.
Why “local-first” needs a precise meaning
Local persistence and private processing are not the same claim. A locally stored conversation can still send selected messages to an external model provider. A user can also choose to export state, synchronize it through WebDAV or Upstash, or share an artifact through server-side storage. The application includes these escape hatches because portability and richer features are valuable. They also mean that the user must understand which feature is moving which data.
Credentials make the distinction sharper. A deployment may keep provider keys on the server and expose only non-secret configuration to the client. Alternatively, a user may enter a personal key into the client. Access control can require a deployment password, but a deployment without that password is intentionally open according to the project’s own documentation. None of these choices, by itself, proves that local data is encrypted, that remote providers will retain nothing, or that operational logs cannot reveal sensitive values.
The right question is therefore not “Is NextChat private?” as if privacy were a single property of the product. Ask instead: where is the conversation stored, which portion is sent to a provider, who owns the credential, which optional services receive a copy, and what controls exist at each transition? That question remains useful whether the user runs a single-device desktop application, a personal web deployment, or a shared service.
The same discipline applies to convenience. A personal key may avoid configuring a server but changes who must protect that key. A server-managed key can simplify access for a group but makes deployment logs, access codes, and hosting configuration part of the trust model. A backup can make a conversation portable but may carry settings and credentials along with messages. A richer assistant can call tools or publish artifacts, but the gain in usefulness is also a gain in external effect. The product does not choose these trade-offs for the user; it exposes several ways to assemble them.
What this perspective makes possible
Once NextChat is viewed this way, its feature set becomes easier to reason about. Streaming is a boundary problem because chunks must pass from the provider through the transport and into the client without being buffered or misread. Long conversations are a boundary problem because the client must decide which history enters the next request and which history becomes a lossy summary. Multi-provider support is a boundary problem because a common interface must stop at the point where provider rules diverge. Tools and artifacts are boundary problems because language can cross into an external action or a public retrieval path.
This is also a more useful way to judge the project than a feature checklist. NextChat’s strengths lie in giving users control over model choice, deployment, conversation configuration, and optional capabilities while keeping the visible interaction coherent. Its limits appear wherever a boundary is conditional: a server can be configured badly, a proxy can break streaming, a summary can lose detail, a plugin can call an untrusted API, or a backup can contain more state than expected.
The rest of this series follows one message through those transitions. It first traces the web and desktop request paths, then examines how provider adapters translate the conversation. It explains how masks and layered memory decide what the provider sees, and connects that logical context to locally persisted state. From there, it considers synchronization, live-stream failure, tools, artifacts, and realtime media. The goal is not to memorize NextChat’s internal inventory. It is to learn where its boundaries are, what each boundary buys, and what the product cannot guarantee once a choice crosses it.
NextChat becomes understandable when the question shifts from “Which features does it have?” to “Which system owns the next step?” The next step is to follow a message and see how that ownership changes between the client, the deployment, and the provider.