lsbot — Lingti Secure Bot

我们不能相信任何聊天服务器，也不能允许把我们电脑上最重要的数据分享给任何聊天服务器。

Bot Needs to be Secured

When you run an AI bot, you are handing it the keys to your machine: files, terminals, databases, browser sessions, credentials. The bot reads your code, your notes, your private documents. It executes commands on your behalf.

The question is not whether your bot is useful. The question is: who else can read what it sees?

Every message you send to an AI bot travels somewhere before reaching the model. If that path is not encrypted end-to-end, anyone sitting on that path — a relay server, a cloud provider, a network operator — can read your conversations and infer what is on your machine.

This is not a theoretical risk. It is the default configuration of almost every AI bot tool available today.

Why OpenClaw Is Not Secured

OpenClaw (and most tools in its category) are designed for convenience and feature breadth. Security is treated as an integration concern, not a core design principle.

The structural problems:

OpenClaw does excellent work on features and integrations. But its architecture assumes you trust the relay infrastructure. For personal machines, corporate environments, or any context where data sensitivity matters, that assumption does not hold.

When you give an AI bot access to your terminal and your files, the transport layer must be treated as hostile. OpenClaw does not do this.

Why lsbot

lsbot stands for Lingti Secure Bot. The name also echoes ls — the most basic Unix command, the first thing you type on a new machine. Like ls, lsbot is a fundamental tool: lean, purposeful, always available.

lsbot is built around a single principle: your data belongs to you.

This shapes every architectural decision:

• End-to-end encrypted by default. All relay traffic is encrypted with P-256 ECDH + AES-256-GCM. The relay server routes ciphertext. It cannot read your messages.
• Single static binary. No runtime, no package manager, no dependency chain. The attack surface is the binary itself — auditable, deterministic, reproducible.
• Local-first. Conversation history, memory, configuration, credentials — all stored on your machine. Nothing is written to any cloud database.
• Key verification out-of-band. The browser does not auto-fetch the bot's public key from the server. You paste it manually from lsbot e2e pubkey and verify the fingerprint. The relay server cannot substitute its own key.

Lingti Secure Bot

lsbot relay --provider deepseek

That one command starts a secure bot. It:

1. Generates an E2EE key pair on first run (~/.lingti-e2e.pem)
2. Connects to the relay over WebSocket
3. Publishes only the public key — the private key never leaves your machine
4. Encrypts every response before it leaves your process
5. Decrypts every message after it arrives at your process

The relay server at bot.lingti.com sees only ciphertext. It cannot read your messages, cannot log your conversations, cannot infer what tools you are using or what files you are accessing.

lsbot e2e pubkey
# Key file:    ~/.lingti-e2e.pem
# Public key:  BK3x9f2...
# Fingerprint: sha256:29f8954f

Open the bot page, click Secure, paste the public key, verify the fingerprint matches. Every subsequent visit auto-activates encryption using the stored key.

我们不能相信任何聊天服务器

信任中继服务器是 AI Bot 安全的原罪。

几乎所有主流 AI Bot 工具都依赖一个隐含假设：消息通过开发者的服务器路由是安全的。这个假设在以下任何场景中都会失效：

• 服务商被攻击或遭受数据泄露
• 政策变更导致日志保留或内容审查
• 内部员工滥用访问权限
• 法律程序要求披露用户数据
• 服务商出售或被收购

你的 AI Bot 可以访问你的终端、你的文件、你的代码库。它知道你在做什么项目，知道你的工作流程，知道你的私人文档。这些信息通过一个你不控制的服务器转发——这不是可接受的风险，这是一个架构缺陷。

lsbot 的设计前提是：中继服务器是不可信的。这不是对 bot.lingti.com 的不信任，而是一个工程原则：不需要信任的地方，就不应该建立信任依赖。

数据库保存在本地

lsbot 没有云端数据库。

云中继服务器（bot.lingti.com）只做一件事：路由加密后的消息。它不保存任何内容，不分析任何内容，不记录任何内容。消息转发后立即丢弃。

即使 bot.lingti.com 明天关闭，你所有的数据、配置、历史记录都完好无损在你的机器上。

这不是承诺，这是架构决定的结果。

名字的含义

lsbot 有两层含义：

Lingti Secure Bot — 安全是第一设计原则，不是事后加上去的功能。

ls — Unix 最基础的命令之一。第一次拿到一台新机器，你会敲的第一个命令。lsbot 的目标是成为你工具箱里同等级别的基础设施：永远在，永远可信，永远如你所期。

→ lsbot.org · 快速开始 · E2EE 加密 · GitHub