TapeAPI 2.0.0

中文

TapeAPI 2.0.0：标准即默认。 不传任何选项，createTapeAPI() 就按 TapeOut 官方 TAP 的规定解析服务：TAP-10 v1.1 §3 至 §7 与 TAP-11 §2，所有读取钉在同一个区块上，链 ID 与持有人要所有节点一致；名字从未开通（not-opened）、未激活或付费到期（unpaid）、TapeOut 的站点存储或付费合约换成了 SDK 不认识的实现（store-changed），都会得到一个明确的状态，而不是悄悄解析成功。

TAP-11 与 TAP-13 是我们起草并提交的草稿，编辑已把两份合并进官方仓库，状态是 Draft；合并为 Draft 不等于被采纳。另有 10 份草稿是尚未合并的拉取请求，等待编辑处理；对 TAP-11、TAP-13 的后续修改 #51、#53、#55、#56 也在等待编辑处理。

升级指南：从 1.x 升级到 2.0。TAPI-20 至 TAPI-27 的线上格式与冻结常量一个字节都不变，2.0 的客户端照样核验所有 1.x 的清单、委托、签名回答和回执。

一致模式成为默认

• 不传 conform：按 TAP-10 / TAP-11 §2 解析，正是 1.x 里 conform: 'tap10' 的行为。按 e.data.status 分支，不要按错误信息：not-opened、unpaid 要服务方自己处理（不要重试），store-changed 要升级 SDK（临时办法是 conform: false），unavailable 是节点问题（重试，或加一个自己的运营方）。
• 退出开关 conform: false（或 null）：1.x 的解析方式，请求逐个相同。已弃用，整个 2.x 保留；每个以它建立的客户端在建立时发出一次 onWarning（code DEPRECATED）。dev: true 等于 conform: false，不出弃用提示。
• 自定义地址、本地链或分叉、显式 pin：建客户端时 INVALID_ARGUMENT，提示传 conform: false；不会悄悄降级。
• tapeapi-verify、tapeapi-mcp、tapeapi-doctor 都用新默认，输出写明用了哪种解析，加 --no-conform 回到 1.x 的方式。在默认下，tapeapi-doctor 对未激活的名字判为失败；加 --no-conform 仍只是警告。
• 代价：在 BNB Smart Chain 上用默认节点实测，冷解析约 2 倍、热解析约 4 倍的 JSON-RPC 调用。
• 我们怎么核对的：637 个用例的差分测试里，conform: false 与 1.8.1 的默认发出相同的请求、顺序相同、结果相同（只允许两处差异：弃用提示，以及第 2 版的收件房间）。

状态名只增不改，以及跟随规则

TAP-10 与 TAP-11 是合并为 Draft 的（合并不等于被采纳），文本还可能改。改动时：放宽与新增状态名在 2.x 的次版本里直接成为默认；收紧先作为可选的新 profile 提供，默认到 3.0 才切换。状态名只增不改。conform: false 完全不跟随 TAP。data.status、SiteStatus 与 svc.conform 在 2.0 里仍是实验性的（它们跟随的是 Draft），待 TAP-11 评审期满且无未解决的异议后再考虑升为 Stable。新增 CONFORM_PROFILE（'tap10@1.1+tap11@draft'）与 svc.conform.profile，写明默认依据哪一版文本。

已知例外

不开 allChains 时，形如 0x…#4246 的"处理器合约#ID"会被拒绝（data.status: 'unsupported'，这是 TapeAPI 自己的名字），而 TAP-11 §2.1 要求接受它；传 allChains: true 即按 TAP-10 §4.1 读遍所有链解析（会同时访问 Base 与 X Layer 的节点）。2.0 默认仍不开 allChains。

其它破坏性修改

• 私密通道与群聊默认使用 TAPI-26 v2 与 TAPI-27 v2（标签以 tape-channel/、tape-group/ 开头），两份规范自 2.0.0 起为 Stable (v2)。labels: 'v1' 选用第 1 版（2.x 内弃用，不删除）。两个版本不互通，不一致时失败关闭；群聊终身保持创建时的版本。
• 链上清单以 UTF-8 字节序标记开头或不是合法 UTF-8 时，2.0 默认报 MANIFEST_INVALID（manifest-invalid），1.x 会照常解析；请持有人重新发布合规清单，临时办法是 conform: false。清单缓存由 3,600 秒改为 60 秒；目录标签不再是 resolve 的输入。
• TapeAPIError 去掉了弃用的顶层别名（e.rpcCode、e.tooLarge、e.agreed 等）：读 e.data.*。
• 通道模块把调用方自己的选项或参数错误报为 INVALID_ARGUMENT；TAPI-26 数据本身出错仍是 CHANNEL_INVALID。

实验性，在 2.0 首次公开：有界代理

代理可以替容器花钱，而容器最多会亏多少由托管通道定死、可在链上核对：阶段 1 的核验（{ enforcement: 'escrow-channel' }）、持有人的计划与收尾、代理的累计限额器（默认拒绝单次超过上限 10% 的调用），以及重启后接着处理订单（钥匙与订单记录加密保存）。边界如实说：托管合约未经审计、未部署，所以主网不可用；只在本地链与测试中可以验证；@tapeapi/sdk/agent 不受 2.x 兼容承诺约束。阶段 1 的 TAP 草稿尚未提交。

另外两项实验性功能

• 美元报价、BEM 结算（TAPI-22 §3.6；TAP 草稿 #52，未合并的拉取请求）。没有 usdPricing 的清单，回答与付款逐字节照旧。托管合约没有部署，所以不收任何费用。
• 容器之间的评价（@tapeapi/sdk/review；TAP 草稿 #54，未合并的拉取请求）。有证据才计入；汇总只数不同的评价方与持有人，从不按金额加权。

承诺

按 2.0 文档写的代码，在所有 2.x 版本里都能继续工作；除了标注 @experimental 或 @internal 的，其余全部是稳定的。conform: false 与 labels: 'v1' 已弃用，整个 2.x 保留。2.0.0 发布后 1.x 继续获得 6 个月的安全修复。 今天上线的一切都免费；没有经过第三方审计。

完整的改动清单见 CHANGELOG。

English

TapeAPI 2.0.0: standards by default. Pass no options and createTapeAPI() resolves a service the way TapeOut's official TAPs say: TAP-10 v1.1 §3 to §7 and TAP-11 §2, every read at one pinned block, strict agreement of the nodes on the chain and the owner, and a named status instead of a quiet success when a name was never opened (not-opened), is not activated or its payment has run out (unpaid), or TapeOut's site store or payment contract runs an implementation the SDK does not list (store-changed).

TAP-11 and TAP-13 are drafts we wrote and submitted; the editors merged both into the official repository as Drafts, and a merge into Draft is not adoption. Ten more drafts are open pull requests, waiting for the editors; the follow-up edits to TAP-11 and TAP-13, #51, #53, #55 and #56, are waiting for the editors too.

Upgrade guide: Upgrading from 1.x to 2.0. The wire formats and frozen constants of TAPI-20 to TAPI-27 do not change, so a 2.0 client verifies every 1.x manifest, delegation, signed response and receipt.

Conformance becomes the default

• Without conform: TAP-10 / TAP-11 §2 resolution, exactly what conform: 'tap10' did in 1.x. Branch on e.data.status, not on messages: not-opened and unpaid are for the provider to fix (do not retry), store-changed means update the SDK (conform: false is the stop-gap), unavailable is a node problem (retry, or add an operator of your own).
• The opt-out, conform: false (or null): the 1.x resolution, request for request. Deprecated and kept in all of 2.x; each client made with it warns once through onWarning (code DEPRECATED) when it is made. dev: true means conform: false, without a warning.
• Your own addresses, a local chain or fork, an explicit pin: INVALID_ARGUMENT when the client is made, naming conform: false; nothing falls back silently.
• tapeapi-verify, tapeapi-mcp and tapeapi-doctor use the new default, say which resolution they used, and take --no-conform for the 1.x one. In the default, tapeapi-doctor fails a name that is not activated; with --no-conform it is still a warning.
• What it costs: measured on BNB Smart Chain with the default nodes, a cold resolution sends about 2 times and a warm one about 4 times the JSON-RPC calls.
• How we checked: in a differential run over 637 cases, conform: false made the same requests in the same order with the same results as 1.8.1's default (the only differences allowed: the deprecation warning, and the version-2 inbox room).

Status names only grow, and the follow rule

TAP-10 and TAP-11 were merged as Drafts (a merge is not an adoption), so their text can still change. When it does, a loosening or a new status name becomes the default in a 2.x minor release; a tightening is offered first as an optional new profile and becomes the default in 3.0. Status names only grow. conform: false does not follow the TAPs at all. data.status, SiteStatus and svc.conform are experimental in 2.0 (they follow a Draft); they are considered for Stable after TAP-11's review period ends with no unresolved objection. New: CONFORM_PROFILE ('tap10@1.1+tap11@draft') and svc.conform.profile, naming the texts the default resolves by.

Known exception

Without allChains, a processor contract#ID such as 0x…#4246 is refused (data.status: 'unsupported', a name of TapeAPI's own), where TAP-11 §2.1 says a client must accept it; pass allChains: true to resolve it on every chain as TAP-10 §4.1 says (this also queries the nodes of Base and X Layer). allChains stays off by default in 2.0.

Other breaking changes

• Private channels and groups use TAPI-26 v2 and TAPI-27 v2 by default (labels that begin with tape-channel/ and tape-group/); both specs are Stable (v2) from 2.0.0. labels: 'v1' selects version 1 (deprecated in 2.x, not removed in 2.x). The two versions do not interoperate, and a mismatch fails closed; a group keeps its version for life.
• A manifest on chain that begins with a UTF-8 byte order mark or is not valid UTF-8 now fails by default with MANIFEST_INVALID (manifest-invalid), where 1.x resolved it; the holder publishes it again, and conform: false is the stop-gap. A manifest is kept for 60 seconds instead of 3,600; a directory label is no longer an input to resolve.
• TapeAPIError loses the deprecated top-level aliases (e.rpcCode, e.tooLarge, e.agreed, ...): read e.data.*.
• The channel module reports a mistake in your own options or arguments as INVALID_ARGUMENT; TAPI-26 data that fails stays CHANNEL_INVALID.

Experimental, first public in 2.0: bounded agents

An agent may spend for a container, and the most the container can lose is fixed by escrow channels and checkable on chain: the phase-1 checks ({ enforcement: 'escrow-channel' }), the holder's plan and close-out, the agent's spend limiter (by default it refuses a single call above 10% of the cap), and orders that resume after a restart with the keys and order records sealed. The limits, plainly: the escrow contract is not audited and not deployed, so this is not usable on mainnet; it is checked on local chains and in tests only, and @tapeapi/sdk/agent is outside the 2.x compatibility promise. The phase-1 TAP draft has not been submitted.

Also experimental in 2.0

• Prices in US dollars, paid in BEM (TAPI-22 §3.6; the TAP draft #52, an open pull request). A manifest without usdPricing answers and pays byte for byte as before. No escrow is deployed, so nothing is charged.
• Reviews between containers (@tapeapi/sdk/review; the TAP draft #54, an open pull request). A review counts only with evidence; summaries count distinct reviewers and holders, never amounts.

What 2.0 promises

Code written against the 2.0 docs keeps working in every 2.x release; everything is Stable except what is marked @experimental or @internal. conform: false and labels: 'v1' are deprecated and kept in all of 2.x. 1.x receives security fixes for 6 months after 2.0.0. Everything live today is free; nothing here has had a third-party audit.

The full list of changes is in the CHANGELOG.

Verify the download / 校验下载

The packages are installed from these release files (they are not on npm), so check them first: put SHA256SUMS and the .tgz files in one folder and run shasum -a 256 -c SHA256SUMS (on Linux, sha256sum -c SHA256SUMS). Every line must end in OK.

安装用的是这个 Release 里的文件（不在 npm 上），请先校验：把 SHA256SUMS 与 .tgz 文件放进同一个文件夹，运行 shasum -a 256 -c SHA256SUMS（Linux 用 sha256sum -c SHA256SUMS），每一行都必须以 OK 结尾。

70d2b783de77a56761ba1fa9d7a693ff7159052f8c0857e9bb5453f9441854e4  tapeapi-sdk-2.0.0.tgz
b75d77d710fc24a30f31c6236ad954e16c24dec9b4cd2fd69a69c01bc13990b7  tapeapi-server-2.0.0.tgz