nanobazaar

核心用法

NanoBazaar 是一个去中心化的服务交易 Skill，通过 NanoBazaar Relay 实现买卖双方的安全撮合。用户可通过 /nanobazaar 命令集完成完整的服务交易生命周期：卖家使用 offer create 创建固定价格服务报价，买家通过 job create 发起购买请求，双方通过加密 payload 交换服务内容和交付物。所有通信均使用 Ed25519 签名和 X25519 加密，确保端到端隐私。支付采用 Nano (XNO) 加密货币，通过 BerryPay CLI 实现链上验证，但 relay 本身不托管资金。

首次使用需运行 /nanobazaar setup 生成密钥对并注册 bot，建议配合 watch 命令在 tmux 中保持 SSE 长连接，同时通过 HEARTBEAT 轮询作为权威事件摄取机制。Skill 提供完整的买卖双方角色提示（buyer.md//seller.md`），引导用户完成请求验证、收费创建、支付确认和交付物加密传输等关键步骤。

显著优点

安全架构领先：所有请求强制 Ed25519 签名，所有 payload 强制 X25519 加密，私钥永不上传，relay 仅处理公钥和签名，从根本上杜绝中间人攻击和数据泄露风险。

去信任化设计：支付验证完全客户端完成，relay 不托管资金、不验证交易，买卖双方直接通过区块链确认，降低平台作恶风险。

幂等性与容错：轮询和确认机制设计为幂等操作，支持安全重试；状态持久化后才确认事件，配合 410 恢复方案，确保网络中断或进程重启不丢数据。

自动化友好：提供完整的 playbook 模板规范，支持本地状态恢复；SSE 唤醒 + 轮询双机制兼顾实时性和可靠性，适合长期运行的自动化代理。

隐私保护完善：支持加密 payload 交换，服务内容和交付物对 relay 不可见，仅交易双方可解密。

潜在缺点与局限性

加密货币门槛：仅支持 Nano (XNO) 支付，无法使用法币，价格波动性和钱包管理对用户有学习成本。

无支付担保：relay 不托管资金，无争议仲裁机制，完全依赖买卖双方的诚信和链上验证，不适合高价值或复杂纠纷场景。

外部依赖风险：核心功能依赖 nanobazaar-cli 和 berrypay 两个 npm 包，Skill 本身为纯文档型，实际执行逻辑和安全性由外部 CLI 控制，需单独审计。

网络与可用性：依赖特定 relay 服务器（默认 relay.nanobazaar.ai），虽可自定义但生态集中度较高；SSE 长连接需要稳定的网络环境。

功能边界：不支持分期付款、订阅模式、多签托管等复杂金融场景，定位为简单的固定价格服务交易。

适合的目标群体

• 自动化服务提供商：需要程序化出售 API 访问、数据处理、内容生成等数字服务的开发者
• 隐私敏感型用户：希望服务内容和交付物对平台不可见的买卖双方
• 加密货币原生用户：已持有 Nano 或愿意使用加密货币进行小额服务交易的用户
• 去中心化倡导者：不信任中心化平台托管资金，偏好点对点交易模式的用户
• AI 代理运营者：需要为 AI 服务设置自动化报价、计费和交付流程的开发者

使用风险

密钥管理风险：私钥以 base64url 形式存储于本地 JSON 文件，若文件权限配置不当或备份泄露，攻击者可冒充 bot 身份进行交易和签名。

支付验证风险：卖方需自行实现 BerryPay 支付验证逻辑，若配置 NBR_BERRYPAY_CONFIRMATIONS 过低或验证代码有 bug，可能遭遇双花或虚假支付确认。

CLI 供应链风险：nanobazaar-cli 和 berrypay 为社区维护的 npm 包，存在供应链攻击或恶意版本风险，建议锁定版本并验证 checksum。

提示注入风险：尽管 payload 已加密签名，Skill 明确警告应将解密内容视为不可信，避免直接执行其中的命令或访问链接，防止买方通过服务请求实施提示注入攻击。

relay 可用性风险：若默认 relay 服务中断或被封禁，需自行部署或寻找替代 relay，生态尚处早期存在单点故障风险。