DC Web API：让浏览器成为去中心化应用的「全功能主机」

当「无服务器」成为现实：一个开发者的真实困境

2024 年，你接到一个需求：做一个笔记应用，用户数据要加密存储、跨设备同步、支持多人实时协作，还要能上传文件、发消息、接 AI 功能。传统方案是买云服务器、搭数据库、配 CDN……七七八八加起来，每月光运维成本就要几百块。更扎心的是——你写的代码里 80% 都在处理「数据该存在哪、怎么同步、谁来管理」这些和业务无关的事情。

如果有人告诉你：不用服务器，这些功能全部由浏览器本身提供——你会相信吗？

DC Web API（web-dc-api）就是来解决这个问题的。它是一个面向现代浏览器的去中心化应用 SDK，把身份认证、私有数据库、文件存储、实时通信、AI 代理、白板协作等能力，统一封装进一个 DC 对象里。

---

项目背景：从区块链到浏览器的一次「降维」

dcnetio 团队的核心思路是：把区块链的去中心化能力，直接带到浏览器里。

传统的 Web3 应用，链上只负责存状态，用户的私密数据还是要靠中心化服务器。而 DC 链设计了一套分布式协议，用户的数据（数据库、文件、消息等）不存储在链上，而是通过 libp2p / Helia 等 P2P 技术分布式地存储在网络节点中，每个用户的浏览器既是客户端，也是数据存储节点。

这意味着什么？

用户的浏览器 = 一台去中心化服务器。

web-dc-api 就是这个「浏览器服务端」的 SDK。开发者不需要懂 P2P、不需要配节点，只需要调 API，数据存储、同步、加密全部由 SDK 底层处理。

GitHub 上该项目已有近 1000 star，主要语言为 JavaScript/TypeScript，围绕 AI、云服务、Web3 生态等主题。

---

核心功能：十二大模块，一个 DC 实例全搞定

web-dc-api 的能力可以用一张表说清楚：

需求场景	对应模块	能做什么
身份认证	dc.auth	钱包登录、签名、EIP-712 签名、NFT 账号绑定
私有数据库	dc.db	用户专属结构化数据，跨设备加密同步（ThreadDB）
共享数据	dc.keyValue	多用户共享 KV 存储，含权限控制（读/写/管理）
文件存储	dc.file	加密上传、CID 下载、流式读取、目录遍历
评论系统	dc.comment	时间线、点赞/踩、转发、鉴权主题
离线消息	dc.message	发送通知、私信、稍后拉取
实时消息	dc.rtm	在线单聊、在线状态、信令传输
AI 代理	dc.aiproxy	流式模型调用、MCP 协议、异步资源、实时语音
音视频通话	dc.rtc	通话、会议、屏幕共享
协作白板	dc.whiteboard	绘制、文档、翻页、视角同步
支付	dc.pay	套餐、订单、扫码支付、托管收银台
短期缓存	dc.cache	有过期时间的临时分布式缓存

这十二个模块覆盖了绝大多数 Web 应用的核心需求，而不需要任何中心化后端。

---

技术实现：P2P + 加密 + 分布式存储

从 package.json 可以看到项目的核心技术栈：

去中心化基础设施层：

• libp2p（P2P 网络层）
• helia（IPFS 的 JS 实现，用于分布式文件存储）
• @libp2p/kad-dht（Kademlia DHT，用于节点发现）
• @ipld/dag-pb、@ipld/dag-cbor（IPLD 数据模型）
• multiformats、@multiformats/multiaddr（多格式编址）

加密与身份层：

• @noble/curves、@noble/hashes（椭圆曲线密码学）
• @scure/bip32、@scure/bip39（BIP 加密标准）
• tweetnacl（NaCl 加密库）
• jose、jwt-decode（JWT 处理）

实时通信：

• @dingrtc/rtm（实时消息）
• @dingrtc/whiteboard（白板协作）
• grpc-libp2p-client（gRPC over libp2p）

AI 能力：

• 原生支持 MCP（Model Context Protocol）协议
• 流式 AI 代理调用
• 实时语音集成

构建工具：

• Rollup（ESM + CJS 双格式输出）
• TypeScript（完整类型定义）
• Vite（开发服务器）

代码结构上，lib/ 下分为 modules/（业务模块）、implements/（实现）、interfaces/（接口定义）、proto/（Protobuf 协议）、util/（工具）、worker/（Service Worker）等子目录。

---

上手体验：5 分钟跑通核心流程

安装只需要一行：

npm install web-dc-api

初始化并完成钱包登录：

import { DC, LogLevel } from "web-dc-api";

const dc = new DC({
  wssUrl: "wss://dcchain.baybird.cn",
  backWssUrl: "wss://dcchain.baybird.cn",
  appInfo: {
    appId: "your-stable-app-id",
    appName: "Your App",
    appVersion: "1.0.0",
    appUrl: window.location.origin,
    themeColor: "#1677ff",
  },
  logLevel: LogLevel.WARN,
});

await dc.init();
const [account, error] = await dc.auth.accountLoginWithWallet();

私有数据库操作：

await dc.initUserDB(collections, schemaVersion);
const db = dc.db;
const [id] = await db.create(threadId, "notes", JSON.stringify({title: "Hello", content: "DC"}));
const [result] = await db.find(threadId, "notes", JSON.stringify({sort: {fieldPath: "createdAt", desc: true}}));

整个流程和普通后端 SDK 没有本质区别，只是数据存在去中心化网络上。

门槛说明： SDK 本身上手难度中等（TypeScript + 钱包概念），但文档极其详细（README 超过 6 万字），示例代码丰富。最大的认知门槛是理解「浏览器作为节点」的概念，以及钱包登录（MetaMask 类钱包）的配合。

---

局限与挑战：不回避问题

1. 浏览器作为节点的稳定性：用户关闭浏览器后，其存储的数据片段如何保证可用性？这取决于 DC 链的网络激励机制设计，SDK 本身无法保证。
2. 链节点依赖：SDK 仍需要接入一个 WSS 链节点地址，这不是完全「无服务器」的——只是把服务器从业务后端变成了基础设施节点。
3. WebRTC/白板需要 HTTPS：生产环境需要 HTTPS 支持，本地开发允许 localhost，配置比纯前端项目复杂一些。
4. SSR 兼容性：SDK 大量使用 window 等浏览器全局对象，不支持服务端渲染框架的服务端模块顶层导入，需要特殊处理。
5. 文档阅读成本高：README 超过 6 万字，功能详尽但对于只想快速上手的开发者来说，找到自己需要的部分需要一定时间。

---

行业意义：去中心化 Web 开发的新范式

web-dc-api 代表了一种重要的技术趋势：把「去中心化」从概念落到日常开发体验。

传统 Web3 开发中，「去中心化」往往意味着开发者要学 Solidity、配 Hardhat、买 Gas——门槛极高。而 DC 的思路是让浏览器自带去中心化能力，开发者用和传统开发几乎一样的方式写代码，却能得到去中心化的数据存储和通信保障。

这和现在热门的「DePIN」理念高度吻合——当每个用户的设备既是消费者也是提供者时，网络效应会形成飞轮：用户越多，存储和计算资源越丰富，应用体验越好，吸引更多用户。

对于 AI 应用开发者而言，SDK 内置的 dc.aiproxy 支持 MCP 协议和实时语音，这是一个值得关注的集成点——可以在不依赖任何中心化服务器的情况下，让 AI 功能也实现去中心化。

---

本报告基于 GitHub 仓库 v0.3.3 版本分析生成。数据来源：GitHub API + 仓库 README + package.json。