你家路由器后面跑着一台树莓派。上面挂着个人的博客、Nextcloud 网盘、还有一个 Bitwarden 密码管理器。你用 DDNS 把家里的动态 IP 映射到一个三级域名上，每月续费 12 美元给某个 VPS 做内网穿透。
这个场景是数百万自托管玩家的日常。你拥有硬件，拥有数据，但你在公网上那个可供别人访问的「门牌号」——域名——还是租来的。
Human-Centered Computing Foundation（HCCF）最近抛出了一个更激进的想法：能不能有一个顶级域名，专门为自托管场景设计，每个人免费领一个，不能转售、不能囤积，一旦你不用了它就回归公共池？
这个顶级域名叫 .self。
一
HCCF 是一家注册在美国的 501(c)(3) 非营利组织。他们的核心提案直白到几乎天真：向 ICANN 申请一个新的通用顶级域名（gTLD）——.self，并把它运营成一项「公共数字基础设施」。
在 HCCF 发布的 PDF 手册里，.self 的关键约束有四条：每人限一个免费子域名；禁止抢注、停放和转售；内置 VPN 隧道和可信邮件服务器等共享服务；所有功能规则由社区治理决定。
这个提案在 Hacker News 上引来了两百多条评论，情绪分裂得相当整齐。一半人觉得这是互联网应有的样子，另一半人觉得这是又一个技术乌托邦幻想。
我们不妨先抛开立场，看看它到底要解决什么问题。
二
理解 .self 的动机，需要先理解「自托管」这个群体的处境。
自托管（self-hosting）的核心主张很简单：你的数据应该跑在你自己的硬件上。但实际操作中，把一台家用服务器暴露到公网面临三重障碍：IP 地址不固定（家庭宽带通常是动态 IP）、ISP 封锁常用端口（80 和 443 在很多地区默认关闭）、以及 TLS 证书的申请和维护成本。
目前的解决方案是拼凑式的：DDNS 服务做动态域名解析，Cloudflare Tunnel 或 frp 做内网穿透，Let’s Encrypt 解决证书。这些工具大多免费，但它们把「入口」的控制权交给了第三方——你的流量经过 Cloudflare 的服务器，你的域名是 Namecheap 或 Cloudflare 注册的，你并不真正拥有这个网络身份。
.self 试图一步到位：你不需要另外买域名，不需要配置 DDNS，不需要自己搭邮件服务器。TLS 证书、VPN、DNS 解析——全部由 TLD 运营方作为公共服务提供。HCCF 管这叫「shared services」，本质上是用一个非营利组织替代目前分散的商业服务商。
三
但这个设计立刻引出了几个硬问题，HN 上的讨论把它们一个个翻了出来。
第一个问题是身份验证。「每人一个域名」听起来很美，怎么做到？HCCF 的 PDF 没有给出具体方案。如果你的域名跟政府 ID 绑定，隐私怎么办？如果不绑定，一个人注册一百个域名怎么拦？HN 用户 anilgulecha 提了一个折中思路：域名从验证过的身份派生（比如政府 ID 的哈希），让抢注在结构上不可能。但这又回到了「谁来验证身份」的老问题——一个非营利组织持有全球用户的身份凭证，这本身就是隐私噩梦。
**第二个问题是安全信号。**用 .self 域名天然向外界宣告「这个网站跑在家里的树莓派上」。HN 用户 BLKNSLVR 直接说：我不想让全世界知道我的站点是自托管的——这等于是给攻击者发请柬。HCCF 的回应逻辑是：现在整个互联网的安全性已经够糟了，多一个 TLD 并不会显著改变攻击面。这话有一定道理，但掩盖了一个事实：集中的攻击目标（所有 .self 域名都指向个人服务器）比分散的 .com 站群更容易被批量扫描。
**第三个问题是域名投机市场。**HCCF 的设计试图通过「禁止转售」和「不用就回收」来消灭域名黄牛。但历史提供了一个反例：.tk（托克劳的国家顶级域名）曾经以「免费域名」著称，结果迅速被垃圾邮件发送者和钓鱼网站淹没，最终不得不收紧政策。HCCF 团队在 HN 上回应说，他们会在初期通过人工审核来防止滥用——用户 anilgulecha 直接点破：「这在规模化以后不可行，跟 captcha 一样，单个不费力，批量就撑不住。」
四
抛开技术细节，.self 提案最有趣的地方可能是它选了一个微妙的时间窗口。
ICANN 的新 gTLD 申请窗口不是每年都开。上一轮在 2012 年，下一轮在 2026 年——中间隔了整整 14 年。标准申请费是 22.7 万美元，而 HCCF 通过了 ICANN 的 Applicant Support Program（ASP）审核，可以享受 75% 到 85% 的费用减免。这意味着他们只需要付大约 3.4 万到 5.7 万美元——对一个非营利组织来说仍然不是小数目，但至少让申请本身变得可及。
HN 上有人质疑：为什么不先在现有的域名下把服务跑起来，等用户有了、功能成熟了，再去申请 TLD？HCCF 的回答很实在：「如果你错过了这个窗口，可能要再等十几年。」
这里确实存在一个先有鸡还是先有蛋的困境。没有 TLD，很难说服用户迁移；没有用户，ICANN 也很难相信你有能力运营一个 TLD。HN 用户 akerl_ 的评论很精准：「你们好像在解决一个最难的可选支线任务。你们路线图上的其他所有东西都可以在现有互联网上先做出来。」
五
一个更深层的问题是：一个新 TLD 真的能改变互联网的集权结构吗？
DNS 系统的权力本身是高度集中的。ICANN 控制根区，Verisign 运行 .com 和 .net 的根服务器，各国政府控制 ccTLD。即便是「独立」的 gTLD，域名注册局仍然受制于 ICANN 的合同约束，也必须遵守注册地所在国的法律。.self 如果是美国非营利组织运营，那它就在美国法律的管辖范围内——HN 用户 microgpt 尖锐地指出：所有非国家代码的 TLD 都落在美国的司法长臂之下。对欧洲或亚洲的自托管用户来说，这意味着你的域名可能因为一家美国法院的判决而被收回。
HCCF 的类比对象是 Let’s Encrypt——另一个由非营利组织（ISRG）运营的公共数字基础设施。Let’s Encrypt 证明了：在证书领域，一个非营利的、自动化的、免费的公共服务可以取代商业 CA 的垄断。但域名系统比证书系统复杂得多。证书只是「证明你是谁」，域名是「你本身就是谁」。两者的网络效应不在一个量级。
HN 用户 jazzyjackson 的评论切中要害：「你要跟一个巨大的网络效应竞争。」.com 不只是便宜，它代表了几十年的用户习惯、浏览器默认行为、搜索引擎权重和邮件信誉体系。一个新 TLD 要越过这些障碍，需要的不是理想，是执行力。
六
在讨论中最被反复提到的一个替代方案是：为什么不用 subdomain？
比如 HCCF 自己的网站挂在 onmy.cloud 上，他们完全可以在 onmy.cloud 下面给每个用户分配一个三级域名（user.onmy.cloud），实现跟 .self 一模一样的功能，而且不需要 ICANN 批准，不需要等 14 年的窗口，不需要花几万美元。
HN 用户 jerf 说得直接：「如果要向 ICANN 证明你们是认真的，我强烈建议先在 onmy.cloud 上把它做出来，告诉用户如果拿到了 .self 就帮他们透明迁移过去。没有什么比「我们已经在跑了」更有说服力。」
这恰恰是 HCCF 目前最薄弱的环节。他们有一份 PDF 手册、一个申请身份、和一个宏大的愿景。但从 PDF 到跑在树莓派上的 VPN 隧道客户端，中间还有很长的路。
七
把 .self 提案放在更大的图景里看，它代表了一类正在成型的思潮：互联网的基础设施层不应该全部由商业公司控制。证书有 Let’s Encrypt，代码托管有 Forgejo 和自建 GitLab，邮件有 ProtonMail 和自建方案，浏览器引擎有 Firefox 和 Chromium 的 forks——域名这个层面，目前还没有一个「公共选项」。
要不要给 HCCF 的 .self 提案下注，取决于你相不相信一个非营利组织可以在 DNS 这个层面复刻 Let’s Encrypt 的路径。相信的人会说：总得有人先迈出第一步。不相信的人会说：在 onmy.cloud 上先跑出一个一万用户的产品，再来谈 TLD 申请。
两种看法都有根据。对 HCCF 来说，现在最重要的是执行——把 PDF 里的「shared services」代码写出来，哪怕暂时跑在 onmy.cloud 的三级域名下。当用户真的在上面托管了自己的博客和网盘，.self 这个 TLD 才有从「提案」变成「标准」的可能。
本文的素材来自公开信息和社区讨论。如果你对这个话题有更深入的一手经验，欢迎指出文中的不足。