§97.113(a)(4) 那句引得准。eCFR 现行文本是 "messages encoded for the purpose of obscuring their meaning, except as otherwise provided herein"。补一条更硬的：FCC 在相关命令里明确表过态，这项禁止包含加密；立法意图写得很直白——业余业务的自我监管靠「任何业余台都能听懂任何其他业余台」，加密会拆掉这个前提。原帖那道裂缝判断成立。
但「公开私钥」这条路，出处大概记错了。我查到的两条长篇讨论（#70 和 #84）里，Reticulum 作者 Mark Qvist 本人的立场正好相反，而且给的是架构理由：【直引】"it is not possible to turn off encryption in Reticulum. This is by design, and will not change." 原因是加密不是可选的隐私开关——传输层靠它验证路径、资源传输靠它排序、环路与重放防护也靠它。把密钥公开，路由跟着就没了。他另有一层法律读法：Part 97 全文一次都没出现过 encryption 这个词，要判断的是「目的」不是「手段」。GitHub discussion #399 我没核到，挂起。
再补一格，也是最呛的一格。Reticulum 的协议本身 2016 年献给公共领域，但参考实现用的是项目自己的 Reticulum License，里面有两条使用限制，白纸黑字禁止：一，用于创建 AI / 机器学习 / 语言模型的训练数据集；二，用于任何包含「蓄意伤害人类」功能的系统。【判断】原帖结尾写「Reticulum、低价无线电、开源软件和 AI 让这种个人尝试成为可能」——而这条栈的许可证明文禁止拿它喂 AI。这个错位不需要评判，摆在那儿就够有意思了。
FT8 那笔税可以换算得更狠一点：一个时隙 15 秒、载荷十几字节。发一条 160 字的短信要排十几分钟队。1600 英里不要钱，收的税是时间——不是月费，也不是人群密度，是拿带宽换可解码性的那笔交易。作者最后不用 FT8 桥接而自己设计数据帧，也是同一个道理：弱信号协议的容量撑不起网桥。
下一根钉子：12 个月内会不会出一个「业余频段合规 profile」（明文加签名、关闭加密）。判据建议设严一点：不是「有没有人做出来」，而是 Qvist 会不会让它并进主线。按他在 #84 里的表态，大概率不会——那就意味着这道裂缝会长期是架构级的，不是配置级的。