dsh_ai1net

DSH AI1NET · 中文文档

Live at ai1net.com — the project's own deployment.

DSH AI1NET is a capability network — every machine is a node, every user gets an isolated workspace, and nodes behind NAT reach each other through a self-built relay or a direct path. One command installs it; a browser operates it.

Let people co-create capabilities, share them, use them, and amplify them with AI.

People in the same domain collaborate in a group conversation, with the humans and their agents all in the room: the conclusions they reach, the traps they hit and the practices they settle on accumulate as knowledge under that domain's project, and AI turns that knowledge into reusable capability. Someone joining later does not start from zero.

Sharing used to look different. To hand a finished skill to another person, the file was copied over and each person installed their own. Once on the network, compute and capability are shared online, and nothing has to be copied around.

Each of those needs something first. Co-creation needs a shared place; sharing needs each person to have a place of their own. This project gives every person an isolated workspace behind a kernel boundary, and links those workspaces into one network. Group conversation is the next step along that path, and is not live yet.

DeepSeek Harness installs as a single process with one profile and one data directory, and it has no concept of a second user. Handed to a group, these questions go unanswered: who is allowed in, whose data is whose, who holds the model key, what happens when a process dies, and what a user may install.

A hosted service leaves the data in someone else's hands. Giving everyone a separate install shares nothing and leaves nobody administering anything.

1. Many users on one deployment — each gets an isolated workspace behind a kernel boundary, on its own OS account, its own process and its own data root. Desktop and mobile clients can join the same deployment too (the clients are in development).
2. How the shared model is handed out — the shared model entry the admin configures is off by default, and its quota is billed to the platform; the admin decides which users it is turned on for. A user can switch it off, not on. Users it is not turned on for never see the shared model in settings. On the same model, a key the user entered takes precedence.
3. Machines behind NAT reaching each other — they cannot reach each other on their own, so the network carries its own relay and direct path, and no deployment has to expose a new port.
4. Crashes and expired sessions — crash circuit-breaking, repair on demand, and recovery that does not need to be noticed.
5. How plugins reach a user — the platform imports pre-built artifacts only (a tarball from the official catalogue, or a release asset) and never runs a third party's build scripts on the platform side; what the admin picks into the candidate pool (the list of plugins the admin has imported) is the whole of what can be chosen. Users switch on what they need on the Capability management page, rather than everything at once.
6. Users managing their own skills — shared skills are read-only and available to everyone; the skills a user uploads can be switched on and off, and deleted.

• A team or a family that wants AI workspaces running on its own hardware.
• Several machines across networks (cloud · home · office) that must reach each other without opening ports.
• Giving a group of people isolated AI workspaces under one administrator.
• Any case where the data must stay in-house rather than with a third party.

Human planning and key judgment; implementation by AI (DeepSeek V4 / V4.1 flash) — see how this project is built.

This page keeps only the essentials. Details live in the documents below.

Every document has a Chinese counterpart (*.zh-CN.md).

The eight themes, one line each:

👉 Full detail: manual/highlights.md

Built on DeepSeek Harness (MIT) and invoked as a child process.

Request path: browser → nginx (TLS) → control plane (auth / approval / admin / web desktop) → routed by Host or /u/<userId>/dsh/* → the user instance (loopback only). Self-healing: a crash → spawn a guardian once to repair the profile → restart; repeated crashes back off and trip a circuit-breaker.

The architecture diagram shows the single-machine deployment, which is the default. Cluster mode splits it across hosts without changing what a user gets:

A node sitting behind NAT with no inbound port is still reachable. Each node makes one outbound connection; the relay multiplexes every stream over it and, for its part, binds loopback only — so adding nodes never adds publicly reachable surface. To the caller the address stays an ordinary host and port, which is why the transport can be replaced without touching the request path.

On top of that channel a direct path is attempted: candidate endpoints are exchanged over the connection that already exists (no new port, no new protocol), and a UDP path counts only when it works in both directions. Otherwise it is declared dead and the fall back is named — off, cooling down, no address, one-way, or past the deadline. A direct path only affects speed, not whether it works.

Identity decides before address does. An offline root authorises signers; online signers issue node credentials; every node holds its own key; sessions use an in-memory key. Whether a node may join is verified on the node itself — a compromised control plane cannot silently insert one — and anything unverifiable is refused with a named reason. Addresses come from a signed directory that can be rotated, so moving a relay does not require reinstalling clients.

👉 Interactive diagram: diagrams/archify/overlay-architecture.html

👉 Full detail: manual/architecture.md

One table per module. Mechanism and trade-offs: see Highlights.

New users land on the registration page — credentials, a human-verification step and an email code:

Returning users sign in from the login page:

An instance that was reaped and opened again shows a self-recovering transition page instead of an error. The shared runtime lives under /usr, which is mounted read-only inside an instance — so what is installed is plain to see.

Requirements: Linux (Debian/Ubuntu or RHEL family) + systemd + root, Node.js ^22.19 or ≥24, and — for the full feature set — a domain with a wildcard certificate.

With a domain (recommended):

git clone https://github.com/maogeigei/dsh_ai1net.git
cd dsh_ai1net
sudo CF_API_TOKEN=xxx bash install.sh --domain dsh.example.com --email you@example.com

Without a domain (verify the wiring only; the chat interface will not open):

sudo bash install.sh

Verify:

systemctl is-active dsh_ai1net                    # expect: active
curl -I http://dsh.example.com/                   # expect: 200 (or 301 to https)
curl -I https://test.dsh.example.com/             # expect: 401 (not logged in)

Then log in to the admin console and approve the first user; that user can then start a session from the web desktop.

🤖 Want an AI agent to install it? Hand it install.md — step-by-step instructions with a check for every step and explicit "stop here" criteria.

👉 Full detail: manual/installation.md (DNS records, certificate issuance, both options compared, the nip.io rehearsal, manual dev setup, and everything about domains) · Environment variables: manual/configuration.md

A hosting platform makes completely different assumptions from "running locally": 127.0.0.1 on the server side is the server, while 127.0.0.1 in the browser is the user's own computer. Plenty of plugins work fine locally and break completely once hosted — and the platform cannot compensate.

The eight failure modes, one line each:

👉 Full guide with the porting rules, the complete case study and a pre-release checklist: PLUGIN-PORTING.md 📦 Worked example: examples/dsh-univer-office/ — the porting patch, new modules and companion skill, with the upstream baseline and how to apply it.

• A cold-starting instance answers 503 instead of a bare socket close — while an instance is coming up its port is already allocated but nothing is listening yet; the proxy used to drop the connection without writing a response, which the edge could only report as 502. It now replies 503 with Retry-After, and a navigation request gets a small page that retries on its own. Only a response already in flight is torn down.
• Housekeeping — the overlay network's operational probes and drills no longer ship: they are written against one specific two-machine deployment, their runbooks live with the operator documentation, and the host identifiers are part of their code rather than their wording.

• Deployment values live in config files — the domain, addresses, ports and credentials a deployment needs are read from config/platform.env (template: config/platform.env.example) or the same-named environment variables. The real file is git-ignored and shipping it is not possible. Precedence: system environment > config/platform.env > neutral built-in defaults that are safe to boot with.
• No real value ships in the code — the overlay bootstrap seeds, the platform directories and the install root are resolved from configuration, so a copy of this repository carries no address, host or directory belonging to someone else's deployment.
• One place resolves every deployment path — src/platform-paths.ts is the single source for the data root, the platform state / backup / artifact directories and the install root; nothing recomputes them.

• Shared model is granted per user — an admin turns it on for each user in the user list (off by default); only then does that user see the platform shared model in their settings and get to use it.
• Model landing follows ownership — the platform writes an instance's credentials and settings through the same ownership-routed file layer as the file surface, so it lands correctly when the instance lives on another host.

• Overlay network — a self-built relay plus direct P2P paths, so instances sitting on different networks can reach each other without each of them needing a public endpoint: node identity keys, rendezvous, an endpoint directory with placement, and content distribution (chunking plus a group key) all ship in-tree under src/net/.
• Registration and accounts — account creation is gated by human verification and an email verification code.
• Overlay control plane — the administrator surface carries the node registry, joins and placement for the overlay, alongside the existing cluster controls.
• Housekeeping — the published copy no longer ships the regression suite, the smoke scripts or the runtime screenshots; the verification scripts that guard shipping behaviour stay.

• Cluster mode — the control plane can now run split across hosts: a manager node plus worker nodes, with per-instance ownership leases so a restart on one host does not fight the other, a remote spawner, and a host-agent path for filesystem and instance operations. The single-machine mode is unchanged and remains the default.
• Multi-language runtime — the platform UI ships a runtime i18n layer, so the interface language is no longer baked into the pages.
• Per-instance skill grouping — the instance-side "my skills" view is grouped rather than a flat list.
• Fixed — the deployment-mode parser and its declared type now agree, so the configuration surface is consistent end to end.

• Model settings — the model dialog mirrors the official interaction, and the recommended plugin catalogue is filtered by the dsh version actually installed.
• Instance memory — the per-instance budget is now a single rule (base 448 MiB → max 1024 MiB) and is decoupled from which plugins are enabled, so toggling a plugin no longer changes the quota it reports.
• Faster page loads — the browser no longer re-downloads the whole plugin script bundle (about 11 MB) on every page view: the merged /plugins/ script table now carries an ETag and answers 304, and the HTML shell is served no-cache so a stale shell can no longer leave the page stuck at "Failed to load plugins".
• Proxy hardening — stale dsh-auth cookies are cleared on rewrite, fixing a 431 that surfaced as "Failed to load plugins".
• Single-machine deployment — the platform ships the single-machine backend, and the deployment mode is settled at startup.

• First public snapshot: one-shot single-machine deployment, per-user process isolation, crash self-healing, and governed plugin and skill management.

• DeepSeek Harness — deepseek-ai/deepseek-harness (MIT). This project neither modifies nor embeds DSH; it invokes the locally installed dsh as a child process. Thanks to the DeepSeek team for open-sourcing it.
• dsh-univer-office — dream-num/dsh-univer-office (Apache-2.0), by dream-num. It is the real-world case study behind the plugin porting guide. Thanks to the author and the Univer community — being able to move a 41 MB online spreadsheet plugin into a hosted environment at all depends on someone having built it first.
• The porting patch and new modules under examples/dsh-univer-office/ are offered under Apache-2.0 as well, so they stay consistent with upstream and are easy to merge back.

Copyright (C) 2026 maogeigei

This project is dual-licensed.

1 · Open source — GNU Affero General Public License v3.0 (the default). Full text in LICENSE.

Free to use, modify and distribute, including commercially. AGPL's source-disclosure obligation applies: anyone who distributes this software, or offers a modified version to others as a network service, must provide those users with the modified source code (AGPL-3.0 §13).

2 · Commercial license. For use without those source-disclosure obligations — most commonly running a closed-source hosted service, or embedding this software in a proprietary product — a commercial license is available. Scope and how to obtain it: COMMERCIAL-LICENSE.md.

For a commercial license, write to maogeigei@gmail.com for terms and pricing.