标签 网络审查 下的文章

根据 cloudflare radar 观测伊朗的数据可知，伊朗从 1 月 8 号开始全国断网，近几天有少量回复但仅为之前的约 2%，此时 dnstt（一个可基于 dns-over-udp/https/tls 的隧道工具）就成了仅存手段之一（当然现在可以用 chatgpt.com 对应的那个 ip 来走 cf ws+tls 那套经典玩法了，但这不是重点）
声明：对于现在还远没有那么严格的国内网络监管程度应该是没有多少实际应用价值了，本次只是处于我的好奇心和整活
也可以参考伊朗人的教程： DNSTT Walkthrough
使用的一键安装 dnstt 服务端脚本 github 仓库： GitHub - bugfloyd/dnstt-deploy: One-click dnstt DNS tunnel server deployment and management script for Linux. Supports multiple distributions, automatic configuration, systemd integration, and interactive management menu.

  1. 前提条件
  • 1 个能用的域名
  • 1 台有 root 权限的 vps（53 端口可用）
  • 一个能用的 dns/doh/dot 服务器（dns-over-quic 可以看有一个叫 slipstream 的项目，据说速度能快十倍但是我没试过）

  1. 域名方面工作
    我用的是 de5.net 那个免费二级域名，托管到了 cloudflare，实际上不需要托管到 cloudflare，只要能设置 A 记录和 NS 记录的都可以
    假设我的 vps ip 为 6.7.8.9，此处创建一个 A 记录，名称设置为 “tns”，内容为 6.7.8.9
    接着创建一个 NS 记录，名称设置为 "t"（根据原作者教程，这里只能为单字母），内容为 "tns.example.com"（例如我的就是tns.example.de5.net）
    大概长这样：

    伊朗大断网时期同款 dnstt 隧道搭建教程，在提供一种极端方案同时，让你能在 2026 体会拨号上网般的速度（1

  2. vps 上的工作
    我使用的是 ubuntu 24.04.3 的 vps，使用脚本在开头有链接，此处使用 ssh 隧道模式。设置过程中还需要填写 mtu，根据作者推荐应根据网络环境选择，较好的选择最高在 1400 左右，最差的应该在 512 以上，我这里选择默认的 1232。安装完成后会弹出一个 “public key”，应保存在客户端的一个文件里（我这里保存为 11111.pub），为了安全应当设置一个新的账户而不是直接使用 root 账户，例如用户名为 “dnstt”，也可以不设置

  3. 客户端连接
    使用命令 dnstt-client -udp DNS_SERVER_IP:53 -pubkey-file server.pub t.example.com 127.0.0.1:7000 来将 vps 的 ssh 隧道到本机的 7000 端口，此处 dns_server_ip 可以是任意能用的 dns 服务器，使用 -doh https://aaa.ddd.oaifree.com/query-dns 等 doh 也行，server.pub 内应有前文脚本生成的 public key，例如我的 11111.pub
    一个可用的启动命令示例为.\dnstt-client-windows-amd64.exe -doh https://dns.alidns.com/dns-query -pubkey-file 11111.pub t.example.de5.net 127.0.0.1:7000
    重点：ssh 模式代理过来的是 ssh，而不是 socks 代理，要使用 ssh -D 1080 -p 7000 root@127.0.0.1 来转化为 socks 代理再填入 v2rayn 等客户端

  4. 测速

    伊朗大断网时期同款 dnstt 隧道搭建教程，在提供一种极端方案同时，让你能在 2026 体会拨号上网般的速度（2

    cloudflare speed test 测下来开始时大约 227kbps，但是我真的懒得等它能测出来最高多少了，反正就比拨号上网强一点吧，上个谷歌还是没压力的，下载个 100gb 的原神大概需要 1026 小时吧

  5. 总结
    其实安装过程比 xray singbox 之类的并不困难，理论上极端网络环境下可用，而且难封锁，就算国内进行了 dns 污染只要换个域名 / 换个 doh 就能用，ip 墙不墙无所谓，但是速度真的太低了
    另外手机上应该可以用 http injector 这个软件，但不知道为什么我连接一直超时，懂的也可以教教我（

📌 转载信息
原作者：
Tairitsu
转载时间：
2026/1/21 22:23:50

这两天在网络上又有一个东西火了，Twitter 的创始人 @jack 新的社交 iOS App  Damus 上苹果商店（第二天就因为违反中国法律在中国区下架了），这个软件是一个去中心化的 Twitter，使用到的是 nostr – Notes and Other Stuff Transmitted by Relays 的协议（协议简介，协议细节），协议简介中有很大的篇幅是在批评Twitter和其相类似的中心化的产品，如：Mastodon 和 Secure Scuttlebutt 。我顺着去看了一下这个协议，发现这个协议真是非常的简单，简单到几句话就可以讲清楚了。

目录

通讯过程

  • 这个协议中有两个东西，一个是 client，一个是 relay，client 就是用户社交的客户端，relay 就是转发服务器。
  • 用户不需要注册，用户只需要有一个密钥对（公钥+私钥）就好了，然后把要发的信息做签名，发给一组 relays
  • 然后你的 Follower 就可以从这些 relays 上订阅到你的信息。

技术细节摘要

  • 技术实现上，nostr 使用 websocket + JSON 的方式。其中主要是下面这么几个指令
    • Client 到 Relay主要是下面这几个指令：
      • EVENT。发出事件，可以扩展出很多很多的动作来，比如：发信息，删信息，迁移信息，建 Channel ……扩展性很好。
      • REQ。用于请求事件和订阅更新。收到REQ消息后，relay 会查询其内部数据库并返回与过滤器匹配的事件，然后存储该过滤器，并将其接收的所有未来事件再次发送到同一websocket，直到websocket关闭。
      • CLOSE。用于停止被 REQ 请求的订阅。
    • Relay 到 Client 主要是下面几个指令：
      • EVENT。用于发送客户端请求的事件。
      • NOTICE。用于向客户端发送人类可读的错误消息或其他信息
  • 关于 EVENT 下面是几个常用的基本事件：
    • 0: set_metadata：比如，用户名，用户头像，用户简介等这样的信息。
    • 1: text_note：用户要发的信息内容
    • 2： recommend_server：用户想要推荐给关注者的Relay的URL（例如wss://somerelay.com）

如何对抗网络审查

那么，这个协议是如何对抗网络审查的？

  • 识别你的身份是通过你的签名，所以，只要你的私钥还在，你是不会被删号的
  • 任何人都可以运行一个或多个relay，所以，就很难有人控制所有的relay
  • 你还可以很方便的告诉其中的 relay 把你发的信息迁到另一个 relay 上
  • 你的信息是一次发给多个relay的，所以，只要不是所有的热门realy封了你，你就可以发出信息
  • 每个relay的运营者都可以自己制定规则，会审查哪些类型内容。用户据此选择即可。基本不会有一个全局的规则。
  • 如果你被全部的relay封了，你还是可以自建你的relay，然后，你可以通过各种方式告诉你身边的人你的relay服务器是什么？这样，他们把这个relay服务器加到他们的client列表中，你又可以从社死中复活了。

嗯，听起来很简单，整个网络是构建在一种 “社区式”的松散结构，完全可能会出现若干个 relay zone。这种架构就像是互联网的架构，没有中心化，比如 DNS服务器和Email服务器一样，只要你愿意，你完全可以发展出自己圈子里的“私服”。

其实，电子邮件是很难被封禁和审查的。我记得2003年中国非典的时候，我当时在北京，当时的卫生部部长说已经控制住了，才12个人感染，当局也在控制舆论和删除互联网上所有的真实信息。但是，大家都在用电子邮件传播信息，当时基本没有什么社交软件，大家分享信息都是通过邮件，尤其是外企工作的圈子，当时每天都要收很多的非典的群发邮件，大家还都是用公司的邮件服务器发……这种松散的，点对点的架构，让审查是基本不可能的。其实，我觉得 nostr 就是另外一个变种或是升级版的 email 的形式。

如何对抗Spam和骗子

但是问题来了，如果不能删号封人的话，那么如何对抗那些制造Spam，骗子或是反人类的信息呢？nostr目前的解决方案是通过比特币闪电网络。比如有些客户端实现了如果对方没有follow 你，如果给他发私信，需要支付一点点btc ，或是relay要求你给btc才给你发信息（注：我不认为这是一个好的方法，因为：1）因为少数的坏人让大多数正常人也要跟着付出成本，这是个糟糕的治理方式，2）不鼓励那些生产内容的人，那么平台就没有任何价值了）。

不过，我觉得也有可以有下面的这些思路：

  • 用户主动拉黑，但很明显这个效率不高，而且体验不好
  • 社区或是同盟维护一个黑名单，relay定期更新（如同email中防垃圾邮件也是这样搞的），这其实也是审查。
  • 防Spam的算法过滤垃圾信息（如同email中干的），自动化审查。
  • 增加发Spam的成本，如: PoW 工作量证明（比特币的挖矿，最早也是用于Email），发信息要花钱（这个对正常用户伤害太大了）等。
  • ……

总之，还是有相应的方法的，但是一定没有完美解，email对抗了这么多年，你还是可以收到大量的垃圾邮件和钓鱼邮件，所以，我觉得 nostr 也不可能做到……

怎么理解审查

最后，我们要明白的是，无论你用什么方法，审查是肯定需要的，所以，我觉得要完全干掉审查，最终的结果就是一个到处都垃圾内容的地方！

我理解的审查不应该是为权力或是个体服务的，而是为大众和人民服务的，所以，审查必然是要有一个开放和共同决策的流程，而不是独断的。

这点可以参考开源软件基金会的运作模式。

  • 最底端的是用户（User）参与开源社区的使用并提供问题和反馈。
  • 用户在使用过程中了解项目情况后贡献代码和文档就可以晋升为贡献者（Contributors），
  • 当贡献者提交一定数量贡献之后就可以晋升为提交者（Committers），此时你将拥有你参与仓库的代码读写权限。
  • 当提交者Committers在社区得到认可后，由项目管理委员会（PMC）选举并产生PMC成员（类似于议员），PMC成员拥有社区相关事务的投票、提名和共同决策权利和义务。

注意下面几点

  • 整个社区的决策者，是要通过自己贡献来挣到被选举权的。
  • 社区所有的工作和决定都是要公开的。
  • 社区的方向和决策都是要投票的，PMC成员有binding的票权，大众也有non-binding的投票权供参考。
  • 如果出现了价值观的不同，那么，直接分裂社区就好了，不同价值观的人加入到不同的社区就好了。

如果审查是在这个框架下运作的话，虽然不完美，但至少会在一种公允的基础下运作，是透明公开的，也是集体决策的。

开源软件社区是一个很成功的示范，所以，我觉得只有技术而没有一个良性的可持续运作的社区，是不可能解决问题的，干净整齐的环境是一定要有人打扫和整理的。

 

欢迎关注我 npub1w6r99545cxea6z76e8nvzjxnymjt4nrsddld33almtm78z7fz95s3c94nu
欢迎关注我 npub1w6r99545cxea6z76e8nvzjxnymjt4nrsddld33almtm78z7fz95s3c94nu

这两天在网络上又有一个东西火了，Twitter 的创始人 @jack 新的社交 iOS App  Damus 上苹果商店（第二天就因为违反中国法律在中国区下架了），这个软件是一个去中心化的 Twitter，使用到的是 nostr – Notes and Other Stuff Transmitted by Relays 的协议（协议简介，协议细节），协议简介中有很大的篇幅是在批评Twitter和其相类似的中心化的产品，如：Mastodon 和 Secure Scuttlebutt 。我顺着去看了一下这个协议，发现这个协议真是非常的简单，简单到几句话就可以讲清楚了。

目录

通讯过程

  • 这个协议中有两个东西，一个是 client，一个是 relay，client 就是用户社交的客户端，relay 就是转发服务器。
  • 用户不需要注册，用户只需要有一个密钥对（公钥+私钥）就好了，然后把要发的信息做签名，发给一组 relays
  • 然后你的 Follower 就可以从这些 relays 上订阅到你的信息。

技术细节摘要

  • 技术实现上，nostr 使用 websocket + JSON 的方式。其中主要是下面这么几个指令
    • Client 到 Relay主要是下面这几个指令：
      • EVENT。发出事件，可以扩展出很多很多的动作来，比如：发信息，删信息，迁移信息，建 Channel ……扩展性很好。
      • REQ。用于请求事件和订阅更新。收到REQ消息后，relay 会查询其内部数据库并返回与过滤器匹配的事件，然后存储该过滤器，并将其接收的所有未来事件再次发送到同一websocket，直到websocket关闭。
      • CLOSE。用于停止被 REQ 请求的订阅。
    • Relay 到 Client 主要是下面几个指令：
      • EVENT。用于发送客户端请求的事件。
      • NOTICE。用于向客户端发送人类可读的错误消息或其他信息
  • 关于 EVENT 下面是几个常用的基本事件：
    • 0: set_metadata：比如，用户名，用户头像，用户简介等这样的信息。
    • 1: text_note：用户要发的信息内容
    • 2： recommend_server：用户想要推荐给关注者的Relay的URL（例如wss://somerelay.com）

如何对抗网络审查

那么，这个协议是如何对抗网络审查的？

  • 识别你的身份是通过你的签名，所以，只要你的私钥还在，你是不会被删号的
  • 任何人都可以运行一个或多个relay，所以，就很难有人控制所有的relay
  • 你还可以很方便的告诉其中的 relay 把你发的信息迁到另一个 relay 上
  • 你的信息是一次发给多个relay的，所以，只要不是所有的热门realy封了你，你就可以发出信息
  • 每个relay的运营者都可以自己制定规则，会审查哪些类型内容。用户据此选择即可。基本不会有一个全局的规则。
  • 如果你被全部的relay封了，你还是可以自建你的relay，然后，你可以通过各种方式告诉你身边的人你的relay服务器是什么？这样，他们把这个relay服务器加到他们的client列表中，你又可以从社死中复活了。

嗯，听起来很简单，整个网络是构建在一种 “社区式”的松散结构，完全可能会出现若干个 relay zone。这种架构就像是互联网的架构，没有中心化，比如 DNS服务器和Email服务器一样，只要你愿意，你完全可以发展出自己圈子里的“私服”。

其实，电子邮件是很难被封禁和审查的。我记得2003年中国非典的时候，我当时在北京，当时的卫生部部长说已经控制住了，才12个人感染，当局也在控制舆论和删除互联网上所有的真实信息。但是，大家都在用电子邮件传播信息，当时基本没有什么社交软件，大家分享信息都是通过邮件，尤其是外企工作的圈子，当时每天都要收很多的非典的群发邮件，大家还都是用公司的邮件服务器发……这种松散的，点对点的架构，让审查是基本不可能的。其实，我觉得 nostr 就是另外一个变种或是升级版的 email 的形式。

如何对抗Spam和骗子

但是问题来了，如果不能删号封人的话，那么如何对抗那些制造Spam，骗子或是反人类的信息呢？nostr目前的解决方案是通过比特币闪电网络。比如有些客户端实现了如果对方没有follow 你，如果给他发私信，需要支付一点点btc ，或是relay要求你给btc才给你发信息（注：我不认为这是一个好的方法，因为：1）因为少数的坏人让大多数正常人也要跟着付出成本，这是个糟糕的治理方式，2）不鼓励那些生产内容的人，那么平台就没有任何价值了）。

不过，我觉得也有可以有下面的这些思路：

  • 用户主动拉黑，但很明显这个效率不高，而且体验不好
  • 社区或是同盟维护一个黑名单，relay定期更新（如同email中防垃圾邮件也是这样搞的），这其实也是审查。
  • 防Spam的算法过滤垃圾信息（如同email中干的），自动化审查。
  • 增加发Spam的成本，如: PoW 工作量证明（比特币的挖矿，最早也是用于Email），发信息要花钱（这个对正常用户伤害太大了）等。
  • ……

总之，还是有相应的方法的，但是一定没有完美解，email对抗了这么多年，你还是可以收到大量的垃圾邮件和钓鱼邮件，所以，我觉得 nostr 也不可能做到……

怎么理解审查

最后，我们要明白的是，无论你用什么方法，审查是肯定需要的，所以，我觉得要完全干掉审查，最终的结果就是一个到处都垃圾内容的地方！

我理解的审查不应该是为权力或是个体服务的，而是为大众和人民服务的，所以，审查必然是要有一个开放和共同决策的流程，而不是独断的。

这点可以参考开源软件基金会的运作模式。

  • 最底端的是用户（User）参与开源社区的使用并提供问题和反馈。
  • 用户在使用过程中了解项目情况后贡献代码和文档就可以晋升为贡献者（Contributors），
  • 当贡献者提交一定数量贡献之后就可以晋升为提交者（Committers），此时你将拥有你参与仓库的代码读写权限。
  • 当提交者Committers在社区得到认可后，由项目管理委员会（PMC）选举并产生PMC成员（类似于议员），PMC成员拥有社区相关事务的投票、提名和共同决策权利和义务。

注意下面几点

  • 整个社区的决策者，是要通过自己贡献来挣到被选举权的。
  • 社区所有的工作和决定都是要公开的。
  • 社区的方向和决策都是要投票的，PMC成员有binding的票权，大众也有non-binding的投票权供参考。
  • 如果出现了价值观的不同，那么，直接分裂社区就好了，不同价值观的人加入到不同的社区就好了。

如果审查是在这个框架下运作的话，虽然不完美，但至少会在一种公允的基础下运作，是透明公开的，也是集体决策的。

开源软件社区是一个很成功的示范，所以，我觉得只有技术而没有一个良性的可持续运作的社区，是不可能解决问题的，干净整齐的环境是一定要有人打扫和整理的。

 

欢迎关注我 npub1w6r99545cxea6z76e8nvzjxnymjt4nrsddld33almtm78z7fz95s3c94nu
欢迎关注我 npub1w6r99545cxea6z76e8nvzjxnymjt4nrsddld33almtm78z7fz95s3c94nu

这两天在网络上又有一个东西火了，Twitter 的创始人 @jack 新的社交 iOS App  Damus 上苹果商店（第二天就因为违反中国法律在中国区下架了），这个软件是一个去中心化的 Twitter，使用到的是 nostr – Notes and Other Stuff Transmitted by Relays 的协议（协议简介，协议细节），协议简介中有很大的篇幅是在批评Twitter和其相类似的中心化的产品，如：Mastodon 和 Secure Scuttlebutt 。我顺着去看了一下这个协议，发现这个协议真是非常的简单，简单到几句话就可以讲清楚了。

目录

通讯过程

  • 这个协议中有两个东西，一个是 client，一个是 relay，client 就是用户社交的客户端，relay 就是转发服务器。
  • 用户不需要注册，用户只需要有一个密钥对（公钥+私钥）就好了，然后把要发的信息做签名，发给一组 relays
  • 然后你的 Follower 就可以从这些 relays 上订阅到你的信息。

技术细节摘要

  • 技术实现上，nostr 使用 websocket + JSON 的方式。其中主要是下面这么几个指令
    • Client 到 Relay主要是下面这几个指令：
      • EVENT。发出事件，可以扩展出很多很多的动作来，比如：发信息，删信息，迁移信息，建 Channel ……扩展性很好。
      • REQ。用于请求事件和订阅更新。收到REQ消息后，relay 会查询其内部数据库并返回与过滤器匹配的事件，然后存储该过滤器，并将其接收的所有未来事件再次发送到同一websocket，直到websocket关闭。
      • CLOSE。用于停止被 REQ 请求的订阅。
    • Relay 到 Client 主要是下面几个指令：
      • EVENT。用于发送客户端请求的事件。
      • NOTICE。用于向客户端发送人类可读的错误消息或其他信息
  • 关于 EVENT 下面是几个常用的基本事件：
    • 0: set_metadata：比如，用户名，用户头像，用户简介等这样的信息。
    • 1: text_note：用户要发的信息内容
    • 2： recommend_server：用户想要推荐给关注者的Relay的URL（例如wss://somerelay.com）

如何对抗网络审查

那么，这个协议是如何对抗网络审查的？

  • 识别你的身份是通过你的签名，所以，只要你的私钥还在，你是不会被删号的
  • 任何人都可以运行一个或多个relay，所以，就很难有人控制所有的relay
  • 你还可以很方便的告诉其中的 relay 把你发的信息迁到另一个 relay 上
  • 你的信息是一次发给多个relay的，所以，只要不是所有的热门realy封了你，你就可以发出信息
  • 每个relay的运营者都可以自己制定规则，会审查哪些类型内容。用户据此选择即可。基本不会有一个全局的规则。
  • 如果你被全部的relay封了，你还是可以自建你的relay，然后，你可以通过各种方式告诉你身边的人你的relay服务器是什么？这样，他们把这个relay服务器加到他们的client列表中，你又可以从社死中复活了。

嗯，听起来很简单，整个网络是构建在一种 “社区式”的松散结构，完全可能会出现若干个 relay zone。这种架构就像是互联网的架构，没有中心化，比如 DNS服务器和Email服务器一样，只要你愿意，你完全可以发展出自己圈子里的“私服”。

其实，电子邮件是很难被封禁和审查的。我记得2003年中国非典的时候，我当时在北京，当时的卫生部部长说已经控制住了，才12个人感染，当局也在控制舆论和删除互联网上所有的真实信息。但是，大家都在用电子邮件传播信息，当时基本没有什么社交软件，大家分享信息都是通过邮件，尤其是外企工作的圈子，当时每天都要收很多的非典的群发邮件，大家还都是用公司的邮件服务器发……这种松散的，点对点的架构，让审查是基本不可能的。其实，我觉得 nostr 就是另外一个变种或是升级版的 email 的形式。

如何对抗Spam和骗子

但是问题来了，如果不能删号封人的话，那么如何对抗那些制造Spam，骗子或是反人类的信息呢？nostr目前的解决方案是通过比特币闪电网络。比如有些客户端实现了如果对方没有follow 你，如果给他发私信，需要支付一点点btc ，或是relay要求你给btc才给你发信息（注：我不认为这是一个好的方法，因为：1）因为少数的坏人让大多数正常人也要跟着付出成本，这是个糟糕的治理方式，2）不鼓励那些生产内容的人，那么平台就没有任何价值了）。

不过，我觉得也有可以有下面的这些思路：

  • 用户主动拉黑，但很明显这个效率不高，而且体验不好
  • 社区或是同盟维护一个黑名单，relay定期更新（如同email中防垃圾邮件也是这样搞的），这其实也是审查。
  • 防Spam的算法过滤垃圾信息（如同email中干的），自动化审查。
  • 增加发Spam的成本，如: PoW 工作量证明（比特币的挖矿，最早也是用于Email），发信息要花钱（这个对正常用户伤害太大了）等。
  • ……

总之，还是有相应的方法的，但是一定没有完美解，email对抗了这么多年，你还是可以收到大量的垃圾邮件和钓鱼邮件，所以，我觉得 nostr 也不可能做到……

怎么理解审查

最后，我们要明白的是，无论你用什么方法，审查是肯定需要的，所以，我觉得要完全干掉审查，最终的结果就是一个到处都垃圾内容的地方！

我理解的审查不应该是为权力或是个体服务的，而是为大众和人民服务的，所以，审查必然是要有一个开放和共同决策的流程，而不是独断的。

这点可以参考开源软件基金会的运作模式。

  • 最底端的是用户（User）参与开源社区的使用并提供问题和反馈。
  • 用户在使用过程中了解项目情况后贡献代码和文档就可以晋升为贡献者（Contributors），
  • 当贡献者提交一定数量贡献之后就可以晋升为提交者（Committers），此时你将拥有你参与仓库的代码读写权限。
  • 当提交者Committers在社区得到认可后，由项目管理委员会（PMC）选举并产生PMC成员（类似于议员），PMC成员拥有社区相关事务的投票、提名和共同决策权利和义务。

注意下面几点

  • 整个社区的决策者，是要通过自己贡献来挣到被选举权的。
  • 社区所有的工作和决定都是要公开的。
  • 社区的方向和决策都是要投票的，PMC成员有binding的票权，大众也有non-binding的投票权供参考。
  • 如果出现了价值观的不同，那么，直接分裂社区就好了，不同价值观的人加入到不同的社区就好了。

如果审查是在这个框架下运作的话，虽然不完美，但至少会在一种公允的基础下运作，是透明公开的，也是集体决策的。

开源软件社区是一个很成功的示范，所以，我觉得只有技术而没有一个良性的可持续运作的社区，是不可能解决问题的，干净整齐的环境是一定要有人打扫和整理的。

 

欢迎关注我 npub1w6r99545cxea6z76e8nvzjxnymjt4nrsddld33almtm78z7fz95s3c94nu
欢迎关注我 npub1w6r99545cxea6z76e8nvzjxnymjt4nrsddld33almtm78z7fz95s3c94nu

这两天在网络上又有一个东西火了，Twitter 的创始人 @jack 新的社交 iOS App  Damus 上苹果商店（第二天就因为违反中国法律在中国区下架了），这个软件是一个去中心化的 Twitter，使用到的是 nostr – Notes and Other Stuff Transmitted by Relays 的协议（协议简介，协议细节），协议简介中有很大的篇幅是在批评Twitter和其相类似的中心化的产品，如：Mastodon 和 Secure Scuttlebutt 。我顺着去看了一下这个协议，发现这个协议真是非常的简单，简单到几句话就可以讲清楚了。

目录

通讯过程

  • 这个协议中有两个东西，一个是 client，一个是 relay，client 就是用户社交的客户端，relay 就是转发服务器。
  • 用户不需要注册，用户只需要有一个密钥对（公钥+私钥）就好了，然后把要发的信息做签名，发给一组 relays
  • 然后你的 Follower 就可以从这些 relays 上订阅到你的信息。

技术细节摘要

  • 技术实现上，nostr 使用 websocket + JSON 的方式。其中主要是下面这么几个指令
    • Client 到 Relay主要是下面这几个指令：
      • EVENT。发出事件，可以扩展出很多很多的动作来，比如：发信息，删信息，迁移信息，建 Channel ……扩展性很好。
      • REQ。用于请求事件和订阅更新。收到REQ消息后，relay 会查询其内部数据库并返回与过滤器匹配的事件，然后存储该过滤器，并将其接收的所有未来事件再次发送到同一websocket，直到websocket关闭。
      • CLOSE。用于停止被 REQ 请求的订阅。
    • Relay 到 Client 主要是下面几个指令：
      • EVENT。用于发送客户端请求的事件。
      • NOTICE。用于向客户端发送人类可读的错误消息或其他信息
  • 关于 EVENT 下面是几个常用的基本事件：
    • 0: set_metadata：比如，用户名，用户头像，用户简介等这样的信息。
    • 1: text_note：用户要发的信息内容
    • 2： recommend_server：用户想要推荐给关注者的Relay的URL（例如wss://somerelay.com）

如何对抗网络审查

那么，这个协议是如何对抗网络审查的？

  • 识别你的身份是通过你的签名，所以，只要你的私钥还在，你是不会被删号的
  • 任何人都可以运行一个或多个relay，所以，就很难有人控制所有的relay
  • 你还可以很方便的告诉其中的 relay 把你发的信息迁到另一个 relay 上
  • 你的信息是一次发给多个relay的，所以，只要不是所有的热门realy封了你，你就可以发出信息
  • 每个relay的运营者都可以自己制定规则，会审查哪些类型内容。用户据此选择即可。基本不会有一个全局的规则。
  • 如果你被全部的relay封了，你还是可以自建你的relay，然后，你可以通过各种方式告诉你身边的人你的relay服务器是什么？这样，他们把这个relay服务器加到他们的client列表中，你又可以从社死中复活了。

嗯，听起来很简单，整个网络是构建在一种 “社区式”的松散结构，完全可能会出现若干个 relay zone。这种架构就像是互联网的架构，没有中心化，比如 DNS服务器和Email服务器一样，只要你愿意，你完全可以发展出自己圈子里的“私服”。

其实，电子邮件是很难被封禁和审查的。我记得2003年中国非典的时候，我当时在北京，当时的卫生部部长说已经控制住了，才12个人感染，当局也在控制舆论和删除互联网上所有的真实信息。但是，大家都在用电子邮件传播信息，当时基本没有什么社交软件，大家分享信息都是通过邮件，尤其是外企工作的圈子，当时每天都要收很多的非典的群发邮件，大家还都是用公司的邮件服务器发……这种松散的，点对点的架构，让审查是基本不可能的。其实，我觉得 nostr 就是另外一个变种或是升级版的 email 的形式。

如何对抗Spam和骗子

但是问题来了，如果不能删号封人的话，那么如何对抗那些制造Spam，骗子或是反人类的信息呢？nostr目前的解决方案是通过比特币闪电网络。比如有些客户端实现了如果对方没有follow 你，如果给他发私信，需要支付一点点btc ，或是relay要求你给btc才给你发信息（注：我不认为这是一个好的方法，因为：1）因为少数的坏人让大多数正常人也要跟着付出成本，这是个糟糕的治理方式，2）不鼓励那些生产内容的人，那么平台就没有任何价值了）。

不过，我觉得也有可以有下面的这些思路：

  • 用户主动拉黑，但很明显这个效率不高，而且体验不好
  • 社区或是同盟维护一个黑名单，relay定期更新（如同email中防垃圾邮件也是这样搞的），这其实也是审查。
  • 防Spam的算法过滤垃圾信息（如同email中干的），自动化审查。
  • 增加发Spam的成本，如: PoW 工作量证明（比特币的挖矿，最早也是用于Email），发信息要花钱（这个对正常用户伤害太大了）等。
  • ……

总之，还是有相应的方法的，但是一定没有完美解，email对抗了这么多年，你还是可以收到大量的垃圾邮件和钓鱼邮件，所以，我觉得 nostr 也不可能做到……

怎么理解审查

最后，我们要明白的是，无论你用什么方法，审查是肯定需要的，所以，我觉得要完全干掉审查，最终的结果就是一个到处都垃圾内容的地方！

我理解的审查不应该是为权力或是个体服务的，而是为大众和人民服务的，所以，审查必然是要有一个开放和共同决策的流程，而不是独断的。

这点可以参考开源软件基金会的运作模式。

  • 最底端的是用户（User）参与开源社区的使用并提供问题和反馈。
  • 用户在使用过程中了解项目情况后贡献代码和文档就可以晋升为贡献者（Contributors），
  • 当贡献者提交一定数量贡献之后就可以晋升为提交者（Committers），此时你将拥有你参与仓库的代码读写权限。
  • 当提交者Committers在社区得到认可后，由项目管理委员会（PMC）选举并产生PMC成员（类似于议员），PMC成员拥有社区相关事务的投票、提名和共同决策权利和义务。

注意下面几点

  • 整个社区的决策者，是要通过自己贡献来挣到被选举权的。
  • 社区所有的工作和决定都是要公开的。
  • 社区的方向和决策都是要投票的，PMC成员有binding的票权，大众也有non-binding的投票权供参考。
  • 如果出现了价值观的不同，那么，直接分裂社区就好了，不同价值观的人加入到不同的社区就好了。

如果审查是在这个框架下运作的话，虽然不完美，但至少会在一种公允的基础下运作，是透明公开的，也是集体决策的。

开源软件社区是一个很成功的示范，所以，我觉得只有技术而没有一个良性的可持续运作的社区，是不可能解决问题的，干净整齐的环境是一定要有人打扫和整理的。

 

欢迎关注我 npub1w6r99545cxea6z76e8nvzjxnymjt4nrsddld33almtm78z7fz95s3c94nu
欢迎关注我 npub1w6r99545cxea6z76e8nvzjxnymjt4nrsddld33almtm78z7fz95s3c94nu

被广泛用于模拟真实浏览器指纹的 uTLS 库存在一个严重的指纹泄露漏洞，进而对主流的代理工具构成了严重威胁。

该漏洞会导致 uTLS 在模仿浏览器时，有 50% 的概率创造出一个矛盾的 TLS 指纹：即外部连接声称优先使用 AES
加密，但其内部 ECH 功能却使用了 ChaCha20。这种矛盾的指纹组合在真实浏览器中绝不会出现，因此可以被立即识别。此漏洞存在于 2023年12月至2025年10月之间的所有 uTLS 版本。

依赖 uTLS 进行指纹模拟的代理工具均受此影响。例如，在 Xray 中 uTLS 功能 fingerprint 默认设置为 chrome，这会直接导致指纹泄露。用户需要手动将其修改为 firefox 或其他浏览器指纹以作规避。

此漏洞可被 GF*W 等审查系统利用，从而极大地提高识别效率。虽然单个连接的泄露概率是50%，但由于代理工具会持续产生大量连接，审查系统识别出用户流量的成功率几乎可以达到100%。比较讽刺的是，如果你不使用 uTLS 伪装，GFW反而更难识别出代理流量，因此当前如果没有必要请勿开启 uTLS 伪装。

消息来源：信号旗

https://github.com/refraction-networking/utls/commit/24bd1e05a788c1add7f3037f4532ea552b2cee07

目前sing-box表示已修复该问题。
https://github.com/refraction-networking/utls/pull/375
https://github.com/SagerNet/sing-box/releases/tag/v1.12.10
https://github.com/SagerNet/sing-box/releases/tag/v1.13.0-alpha.22
mihomo也表示修复该问题。

https://github.com/MetaCubeX/mihomo/releases/tag/v1.19.15
https://github.com/MetaCubeX/ClashMetaForAndroid/releases/tag/v2.11.18