不用买服务器，也能做 AI 应用：web-dc-api 把去中心化能力打包成浏览器 SDK

不用买服务器，也能做 AI 应用：web-dc-api 把去中心化能力打包成浏览器 SDK

如果你想做一款带 AI 功能的应用，传统路径是：买云服务器、搭数据库、接支付、处理登录体系、维护一套后端 API。一套下来，光服务器账单每个月可能就是几百块。

web-dc-api 换了一个思路：把这些能力全部搬到浏览器里，用去中心化协议替代传统服务器，数据存在链上或分布式节点，身份用钱包，文件走 IPFS。

听起来很理想主义，但代码是真实可跑的。当前版本 0.2.81，8 月 11 日刚发布，最近一个月保持着每周一个小版本的更新节奏。

这个 SDK 到底能做什么

web-dc-api 的定位是”面向浏览器的去中心化应用全家桶”，所有能力集中在一个 DC 实例里：

身份与认证：用钱包登录替代传统账号密码体系，支持 EVM 兼容地址、NFT 账号，应用端拿到的是公钥体系身份，不再需要自建登录服务。

用户私有数据库（ThreadDB）：每个登录用户有自己的结构化存储空间，支持 JSON Schema 定义集合、写完按条件查询、跨设备同步。相当于给每个用户配了一个带索引的 SQLite，但跑在浏览器里。

共享 KeyValue 存储：分为普通共享（同一 key 按写入者分别记录）和全局共享（同一 key 全局只保留最新值）。适合做排行榜、全局配置、商品信息这类多用户共同访问的数据，不需要中心化数据库。

加密文件：文件加密后上传，下载时通过 CID（内容寻址标识）获取，支持目录遍历和流式读取。加密密钥在用户侧，平台无法查看文件内容。

消息系统：分两条线——dc.message 是离线消息箱，适合通知和私信；dc.rtm 是在线实时消息，适合需要对方在线才能送达的信令类通信。

AI 代理与 MCP：内置 dc.aiproxy 模块，支持流式模型调用和 MCP 协议，可以对接自己的 AI 服务或第三方代理。

实时音视频（RTC）：点对点通话、多人会议、屏幕共享，配合 dc.rtm 做呼叫信令。房间消息也在同一个体系里。

实时白板：多人协作白板，支持绘制、文档、翻页和视角同步。

支付：整合了扫码支付和托管收银台，适合做付费内容或会员体系。

分布式缓存：短期带过期时间的临时存储，适合 Token 中转等场景。

技术门槛：不是所有场景都适合

这是需要提前了解清楚的部分。

运行要求：

• 目标运行环境是现代浏览器，不是 Node.js 服务端
• 需要浏览器支持 ES2020、Web Crypto、IndexedDB、WebSocket
• 摄像头/麦克风/屏幕共享需要 HTTPS（本地开发允许 localhost）
• ，钱包登录要从真实用户交互触发（点击按钮），否则会被浏览器拦截弹窗
• SSR 框架（Next.js、Nuxt 等）中不能直接在服务端模块顶层导入 SDK，要做动态导入

appId 的坑：appId 是数据命名空间的一部分，上线后不要改，否则用户数据会进到另一个隔离空间。

版本现状：SDK 文档对应的版本是 0.2.72，npm 最新版是 0.2.81，两者有小版本差。README 本身没有标注”不稳定”或”预览版”，但考虑到版本号还在 0.x，接口在不破坏性变更上相对激进，生产项目接入前建议锁版本并跑完整测试。

维护状态：仓库目前 942 Star，0 个 open issue，看起来维护状态不错，但生态资料少，没有找到 Hacker News 或 Reddit 上的讨论帖，教程维度搜索全部失败。社区基础薄，遇到问题基本靠读源码或翻 issue。

适合谁，不适合谁

适合：

• 想快速验证去中心化应用原型，不想搭服务器的独立开发者
• 需要多人实时协作功能（白板、RTC、消息）但不想自建信令服务的团队
• Web3 原生应用开发者，已经在用钱包体系做身份
• AI 应用需要端侧存储用户上下文、笔记或草稿，而不想自建数据库

不适合：

• 需要服务端运算、批处理、定时任务的场景（浏览器 SDK 天然做不了）
• 企业内网应用，用户没有钱包也不会去装插件
• 对数据主权要求极高、不能接受任何数据经过第三方节点的应用（链上数据本质是公开的，只是加密存储）
• 追求稳定 API 表面、不想跟随快速迭代节奏的团队

竞品角度怎么看

同类去中心化 Browser SDK 方向，libp2p 是底层协议层面的标杆，Gun.js 是去中心化数据库方向，ThreadDB（Protocol Labs）提供了结构化存储的上层封装。web-dc-api 实际上是在 ThreadDB 基础上做了更完整的上层封装，把身份、文件、RTC、白板、支付这些常见需求一站式整合，代价是绑定了特定的钱包和链节点体系，灵活性低于直接用 libp2p。

可执行的下一步

如果想验证它能不能跑：

npm install web-dc-api

然后直接 copy README 里那个 5 分钟示例，填一个可用的 wssUrl（README 默认指向 wss://dcchain.baybird.cn，这是官方提供的测试节点），就能跑起来。唯一外部依赖是钱包浏览器插件，MetaMask 或 Rabby 均可。

如果想评估生产可用性：

1. 看官方节点 dcchain.baybird.cn 的可用性和性能，如果要自建节点，需要跑一个 DCChain 全节点
2. 锁死 appId 并设计好数据迁移策略（一旦上线就不要变）
3. 测试 dc.init() 的重连机制，在弱网或节点切换时的用户体验
4. 确认支付模块的结算周期和费率，目前没有找到独立的支付服务商接入文档

GitHub 仓库：https://github.com/dcnetio/web-dc-api
npm：https://www.npmjs.com/package/web-dc-api

• 本文使用多源搜索增强：minimax（最新动态/竞品对比）、zhipu（AI 摘要）、bocha（博查补充），搜索维度包括竞品对比、最新动态、AI 综合摘要。搜索未覆盖到社区讨论和教程维度（均失败），内容主要基于 README 源码和 GitHub 数据。*