TapeSend 与 TAP-10 消息层TapeSend and the TAP-10 messaging layer
容器之间的端到端加密信箱：端点由链号与容器地址拼成，中枢只存目录与指纹，正文只对收件人可解。an end-to-end encrypted mailbox between containers: endpoints are chain ID plus container address, the hub stores only directories and fingerprints, and only the recipient can read the body.
TapeSend 是 DeWEB 的消息层，规范编号 TAP-10。它让两个容器互相收发消息：TapeKit 负责读网站，TapeSend 负责传消息。
身份是容器，不是用户名
没有注册、没有用户名、没有手机号。收件地址就是端点号：
endpointId = uint32(0) ‖ uint64(chainId) ‖ 容器地址共 32 字节，全网唯一，无需中心分配。BNB Chain 上显示为 #15324@30 这样的形式，其他链带短名后缀（如 #15324@30.base）。谁持有容器，谁就是这个端点的所有者——转手电路即转手收件箱。
一条消息怎么写、怎么读
中枢不是金库，是两项目录。 每条启用链通过确定性部署让中枢地址相同。收件项记录发件容器、区块、时间戳与摘要；发件项记录收件端点以及这条消息在对方收件目录里的序号。
密钥点：
- 只写源链：发件人只在自己容器所在的链上提交交易，不查询目标链、不等待目标链执行，因此没有「源链已写、目标链未到」的半状态。
- 正文放在事件里：链上长期保留的是目录与指纹，客户端据此校验。
- 对不上指纹，这封信就不成立：摘要由引用与载荷哈希共同算出，消息号绑定协议域、链号、中枢、收件端点与收件序号。
加密
载荷使用 X25519 + XChaCha20-Poly1305，格式标记 0x02。
中枢合约
| 项目 | 内容 |
|---|---|
| 代理地址 | 0xe61A…E25ee |
| 当前实现 | v3 0x80aF…EE85 |
| 部署差异 | 各链地址相同（确定性部署） |
| 上线时间 | 2026-09-18 在 BNB Chain 上线 |
| 规范文本 | 尚无独立标准稿，正在作为 DeWEB 标准的一部分重写 |
客户端
| 客户端 | 形态 |
|---|---|
| TapeSend | 网页、桌面（Electron，内置 tape:// 浏览器）、iOS、Android |
| TapeChat | 社区基于 TapeSend 二次开发，支持多链互发 |
| DeQQ | 社区聊天客户端 |
| TAPQQ | 复古窗体风格的链上聊天 |
社区客户端不代表官方背书；跨链互发依赖各链中枢可用性。
能力边界
| 能做 | 不能做 |
|---|---|
| 容器间的点对点加密消息 | 隐藏收发双方与时间戳 |
| 多链端点互发 | 替目标链执行任何操作 |
| 客户端独立核验摘要 | 依赖单一中心服务器即可视为可信 |
The messaging layer: TapeKit reads sites, TapeSend sends messages
TapeSend is the messaging layer of DeWEB inside TapeOut: an end-to-end encrypted mailbox between circuit containers. It splits the work with TapeKit — TapeKit reads sites from the chain, TapeSend swaps messages between containers. Founder Blonskr unveiled it on 19 September 2026; the code sits in the send/ directory of the TapeKit repository under MIT, and the spec lives in TAP-10, with the English text authoritative. The repository itself notes it has not been independently audited.
The identity is a container, not a username
The identity is not a username but a circuit container. Every circuit binds an ERC-6551 account, and holding the circuit is what lets you send and receive in its name. The endpoint ID is uint32(0) ‖ uint64(chainId) ‖ container, unique across all chains. On BNB Chain it shows as #15324@30; other chains carry the chain's short name.
How a message is written and read
To send, the sender writes the message into a small contract on their own chain, the DeWEB Hub. The Hub keeps, per recipient, the sender container, block, time and content fingerprint, and keeps an outbox directory per sender; the actual payload rides in the Sent event. Clients page through the mailbox with eth_call against several nodes, can fetch the payload from any node, and then verify it. The message ID is keccak256("TAP-10/msg/v2" ‖ chainId ‖ hub ‖ to ‖ inboxIndex). The recipient's client reads several chains itself and merges the messages addressed to it into one inbox, with no bridge, centralised index or project-run message server in between.
Encryption
The payload format is 0x02; encryption uses X25519 for key exchange and XChaCha20-Poly1305 for symmetric encryption. The public key is derived from a wallet signature and published on the Hub together with a bitmap of "receiving chains".
Deployment
In the public implementation, the BNB Smart Chain Hub proxy the client uses is 0xe61A9C7213a6Aa616C246a2B569e555B417b25ee, with implementation contract v3 at 0x80aFE7B77F2dFD08e9feab7675780baC34a7EE85. On 19 September 2026 the founder said the factory, containers, site repository and TapeSend Hub had been deployed to X Layer, and the round trip with BNB Chain had been tested.