Decentraleyes 和 LocalCDN 这种浏览器插件大抵是死了
Amethyst 新版对中继资料的图标的显示似乎有些变化, 现在帖子发帖人下方的中继分布图谱中的图标只会使用 NIP-11 定义的图标了, 此前的几个版本都还会直接用 favicon.ico 去显示. 不过在应用设置里面的中继列表中显示的中继图标还是 favicon.
fiatjaf 推出了基于语言的邀请制中继器，这是中文中继器的地址 wss://lang.relays.land/zh 可以用 Jumble 直接访问 https://jumble.social/?r=lang.relays.land/zh
该中继器只接受白名单用户的中文内容，可以在 https://lang.relays.land/zh 中查看你是否在白名单。
如何加入？只需要由一名白名单用户将你的中文帖子发布至该中继器，你就能成为白名单用户。以下是在 Jumble 上的操作方式
白名单用户可以考虑将该中继器作为 write relays，这样以后发布内容时也会发布至该中继器，被更多中文用户看到。
邀请更多认识的中文用户吧！
nostr:npub13zyg3zysfylqc6nwfgj2uvce5rtlck2u50vwtjhpn92wzyusprfsdl2rce nostr:npub19yeqjawls407xjnmgkk6yss7936pcd7qzd5srlj8wye6j8433vrsjazqwk nostr:npub17ryxfn6h8hshzpfmaaxl8vcuvkfnx7sf07aanusd0pgxujgvddjq7y9shm nostr:npub1jz8mcwatcv3wafrn5z43u6lkkwkulzvj3zkf0vh608e544qg6njq6nrg8y nostr:npub1zef95zwy99jgq54nhctdyk49nd8u90qne2fkcmcujcnxxjtr9pzs3whurl nostr:npub1vw4af7qhuwwv5nn2hdhxeulpxwahrr8cas5t8rqkgh5y67npjrrqd3y3g9
这个好
不读史自然就不会去鉴, 五千年的除了某压抑还有被收敛在文字里面的情绪, 当然也包括恨. 察觉不到的, 要么是失去情绪能力了, 要么是已经被情绪浸透了, 习以为常, 也就会在别人恨得咬牙切齿的时候感到畏缩和不解. 还能端出 "后朝人修前朝史" 这种借口来讽刺别人的恨不切实际.
仇恨教育? 这网上不天天都在爱死爱活, 恨来恨去吗的. 最好真的是为了保护谁.
I'm speculating which Nostr icon they'll use.
Cloudflare Worker 自带电子邮件混淆且没办法关闭, 很烦.
目前在浏览器里面的 HTTP/3 搁核 QUIC 还是建议禁用的比较好, 特别是国内的三大运营商环境下面, 避免浏览器发起没意义的 QUIC 连接尝试. 但是并不建议直接在路由器上禁掉 QUIC (443 的 UDP), 因为在客户端和服务端配合良好的情况下 QUIC 还是有用的(特别是 DoQ), 现阶段发现表现太差的是浏览器作为一个 HTTP 客户端在不确认服务端状况的情况下无限制发起的 HTTP/3 和 QUIC, 还经常随着浏览器的缓存在 H2 和 H3 之间反复横跳.
做好了: un.cx.ms
用法就是直接插入到白名单 URL 的域名之前, 将原始域名作为路径, un.cx.ms 作为域名直接访问.
比如原始 URL 是: https://example.com/track?url=123456
附加之后就是: https://un.cx.ms/example.com/track?url=123456
自动覆盖客户端请求的标头:
* Accept-Language
* User-Agent
自动删除客户端请求的标头:
* DNT
* Sec-GPC
* Cookie
* If-None-Match
* Origin
* Referer
* Sec-CH-UA
* Sec-CH-UA-Architecture
* Sec-CH-UA-Bitness
* Sec-CH-UA-Full-Version-List
* Sec-CH-UA-Mobile
* Sec-CH-UA-Model
* Sec-CH-UA-Platform
* Sec-CH-UA-Platform-Version
自动删除服务端响应的标头:
* Accept-CH
* ETag
* Set-Cookie
除此之外被代理的当然也包括客户端 IP.
至于怎么让客户端自动附加, 可以用一些修改请求标头的浏览器扩展, 或者 AdGuard 的 $urltransform 修饰符, Android 上可以用 URLCheck.
主要提供演示, 自己从头造一个非常简单, 所以示例服务只对我自己保证 SLA, 没有用户协议也没有隐私协议 :bili_doge:
删除响应标头:
* Access-Control-Allow-Credentials
* Access-Control-Allow-Headers
* Access-Control-Allow-Methods
* Access-Control-Allow-Origin
* Access-Control-Expose-Headers
* Access-Control-Max-Age
* Access-Control-Request-Headers
* Access-Control-Request-Method
* X-XSS-Protection
goo.gl 现在不放弃了. 并且堂堂登场的是! goo.gle 和 g.gle 🤷♂️
goo.gle 的用途类似 aka.ms, g.gle 是去年才被注册出来现在用在 Google 的电子邮件链接点击追踪.
感觉 Google 其实只是不想用自己域名托管这些第三方重定向了想直接弃用. 但和 GitHub 的 git.io 一样, 最后也还是没有真正完全放弃.
联邦抵制 Meta 还有个正当理由就是会让数据更轻易地未经同意就被用于模型训练. 没有人能够证明社交网络上的数据有多大价值能够被用于训练时分配足够高的权重. 冲浪高手应该都明白, 社媒上互动数据也不能证明内容的文化价值, 广告主能投到这些平台上只看互动数据, 和内容脱钩的互动数据是算法和谄媚算法的内容互相左右产生的, 这比起直接谄媚观众还要恶劣.
OpenAI 会和 Reddit 签协议, 但不见得会和 Twitter 签(现在和马斯克谈判没有优势). Meta 更不是人傻钱多的土豪, 清理自己有的数据就十分甚至九分困难了. Google 早期和 Twitter 签的那份协议可能确实让现在的 Gemini 受益, 但已经超出搜索引擎索引的使用范围了, Google 不可能摆明了说.
以前要提倡保护隐私远离科技巨头, 现在要提倡保护用户生成的公共数据不被不道德利用也要远离科技巨头. 消费者, 也就是用户应该要明白自己手里的筹码除了 "隐私" 又多了一个 "用户生成数据", 要不要用自由换取面包似乎又要完全取决于自己了.
https://media.naeu.net/s/2024/06/28120410-082-18a6fedd-1e1c-4ce7-b63b-0c5388e9a896.webp
多玛姆, 我是来谈条件的
The next step for content creators in working with AI bots: Introducing AI Crawl Control
再去找人复刻一个 Nikocado Avocado 的剧本到身上, 还能再赚最后一笔. 不过不知道良子现在是处于哪个阶段. 看起来大概率没有如此成熟的计划, 他只是在吃和拍视频, 但是谁又知道呢.
重新测试采样了一次, Vercel 平均延迟现在已经降到了 和 Netlify 一个水平.
新加了 AWS CloudFront, H2 + H3 平均延迟是 138ms. 其他的重新测试后的波动都不大.
做好了: un.cx.ms
用法就是直接插入到白名单 URL 的域名之前, 将原始域名作为路径, un.cx.ms 作为域名直接访问.
比如原始 URL 是: https://example.com/track?url=123456
附加之后就是: https://un.cx.ms/example.com/track?url=123456
自动覆盖客户端请求的标头:
* Accept-Language
* User-Agent
自动删除客户端请求的标头:
* DNT
* Sec-GPC
* Cookie
* If-None-Match
* Origin
* Referer
* Sec-CH-UA
* Sec-CH-UA-Architecture
* Sec-CH-UA-Bitness
* Sec-CH-UA-Full-Version-List
* Sec-CH-UA-Mobile
* Sec-CH-UA-Model
* Sec-CH-UA-Platform
* Sec-CH-UA-Platform-Version
自动删除服务端响应的标头:
* Accept-CH
* ETag
* Set-Cookie
除此之外被代理的当然也包括客户端 IP.
至于怎么让客户端自动附加, 可以用一些修改请求标头的浏览器扩展, 或者 AdGuard 的 $urltransform 修饰符, Android 上可以用 URLCheck.
主要提供演示, 自己从头造一个非常简单, 所以示例服务只对我自己保证 SLA, 没有用户协议也没有隐私协议 :bili_doge:
继续删除客户端请求标头:
* Sec-CH-UA-Arch
* Sec-CH-UA-Form-Factors
* Sec-CH-UA-Full-Version
* Sec-CH-UA-WoW64
新增和覆盖响应标头:
* X-Robots-Tag
* Referrer-Policy
* Clear-Site-Data
* Permissions-Policy
* Content-Security-Policy
* X-Content-Type-Options
* X-Frame-Options
* Cross-Origin-Opener-Policy
做好了: un.cx.ms
用法就是直接插入到白名单 URL 的域名之前, 将原始域名作为路径, un.cx.ms 作为域名直接访问.
比如原始 URL 是: https://example.com/track?url=123456
附加之后就是: https://un.cx.ms/example.com/track?url=123456
自动覆盖客户端请求的标头:
* Accept-Language
* User-Agent
自动删除客户端请求的标头:
* DNT
* Sec-GPC
* Cookie
* If-None-Match
* Origin
* Referer
* Sec-CH-UA
* Sec-CH-UA-Architecture
* Sec-CH-UA-Bitness
* Sec-CH-UA-Full-Version-List
* Sec-CH-UA-Mobile
* Sec-CH-UA-Model
* Sec-CH-UA-Platform
* Sec-CH-UA-Platform-Version
自动删除服务端响应的标头:
* Accept-CH
* ETag
* Set-Cookie
除此之外被代理的当然也包括客户端 IP.
至于怎么让客户端自动附加, 可以用一些修改请求标头的浏览器扩展, 或者 AdGuard 的 $urltransform 修饰符, Android 上可以用 URLCheck.
主要提供演示, 自己从头造一个非常简单, 所以示例服务只对我自己保证 SLA, 没有用户协议也没有隐私协议 :bili_doge:
DNT 的问题是它俩至今没有在市占率第一的某浏览器中默认启用, 而 Sec-GPC 更是没有被支持, 所以会主动启用的用户, 反而是给客户端添加了一个特征, 不得不说现实很讽刺. 我甚至敢暴论一下: 开启 DNT 的用户可能比用 Firefox 的用户还要少, 而带有 Sec-GPC 这个标头的用户要么是 Firefox 用户要么就是 AdGuard 本机客户端用户. :bili_fantastic:
做好了: un.cx.ms
用法就是直接插入到白名单 URL 的域名之前, 将原始域名作为路径, un.cx.ms 作为域名直接访问.
比如原始 URL 是: https://example.com/track?url=123456
附加之后就是: https://un.cx.ms/example.com/track?url=123456
自动覆盖客户端请求的标头:
* Accept-Language
* User-Agent
自动删除客户端请求的标头:
* DNT
* Sec-GPC
* Cookie
* If-None-Match
* Origin
* Referer
* Sec-CH-UA
* Sec-CH-UA-Architecture
* Sec-CH-UA-Bitness
* Sec-CH-UA-Full-Version-List
* Sec-CH-UA-Mobile
* Sec-CH-UA-Model
* Sec-CH-UA-Platform
* Sec-CH-UA-Platform-Version
自动删除服务端响应的标头:
* Accept-CH
* ETag
* Set-Cookie
除此之外被代理的当然也包括客户端 IP.
至于怎么让客户端自动附加, 可以用一些修改请求标头的浏览器扩展, 或者 AdGuard 的 $urltransform 修饰符, Android 上可以用 URLCheck.
主要提供演示, 自己从头造一个非常简单, 所以示例服务只对我自己保证 SLA, 没有用户协议也没有隐私协议 :bili_doge:
最早 Chrome 支持 gQUIC 的时候被人发现用来显示 YouTube 广告, 被 Brave 一发新闻稿, 大伙以为 Google 又在 Be Evil 了.
(2017/04/25) QUIC in the wild | Brave
https://brave.com/blog/quic-in-the-wild/
这个时候, Google 才开始和 IETF 推进 iQUIC 标准化. 大伙不爽的地方是 QUIC 被拿来发广告且无法被 uBlock Origin 这类活在浏览器应用层里面的插件拦截 (好了现在 MV3 直接把老家端了). Brave 此时推出显式禁用 QUIC 的功能就是为了防止只有 Google 在用的 gQUIC 被拿来发广告.
这不禁让我想起了只有微信在用的 mmTLS :bili_doge:
最近在多个平台部署了一个简单的 API, 有的还用一些 CDN 套了一层, 然后用一个客户端去测试全部 GET 多次取平均值, 目前的结果是 (速度降序):
* 阿里云 ESA: 411ms (H2 + H3)
* Cloudflare: 383ms (H2 + H3)
* 腾讯 EdgeOne: 252ms (H2)
* Gcore: 243ms (H2)
* Fastly: 177ms (H2 + H3)
* Vercel: 142ms (H2)
* Netlify: 80ms (H2)
都是免费的套餐. 还不清楚运营商们是不是真的把 QUIC 和 UDP 统一对待, 但 QoS 应该还是有的. 目前浏览器(Chromium)普遍是先 H2 连接, 发现并缓存了 Alt-Svc 标头之后才会去尝试 H3, 并且似乎只要 H3 出现了一次错误, H3 的尝试就会被拉黑一段时间.
腾讯云 EdgeOne 的 H3 需要付费, 虽然有一个付费套餐但还没测试; Vercel 和 Netlify 这两家 PaaS 的边缘节点都还没支持 H3; Gcore 的 H3 已经在路线图正在进行, 但已经两年了还没出来.
为了加上一个简单的流量鉴权, Netlify 得要用边缘函数来实现, 消耗套餐配额. Vercel 一条规则就搞定了, 还有清晰的日志.
那还挺唯心的, 可能这就是你不喜欢 JavaScript 的原因吧, 我理解了.
? 那你知不道 Nostr 是一个基于 WebSocket 的协议? 你到底在说什么? 你要喜欢禁用 JavaScript, 那现阶段 90% 的在浏览器运行的 Nostr 客户端都无法使用, 你真的了解过这个协议吗?
那我也要问了, 纯前端如何在不用 JavaScript 的情况下完成 WebSocket 协议升级?
发现 Google One 里面附带的 Gemini 2.5 Pro 对比用 API 和对话客户端组合的 GPT-5 更倾向于谄媚用户一方(一个问题一开头 Gemini 基本必然要以积极的态度总体评价一次用户的问题质量), 可能是 Google One 的 Gemini 是个具体的产品, 而 GPT-5 的 API 是个面向开发者的服务.
等会试试用 Gemini 2.5 Pro 的 API 再继续对比看看, 大概率是系统提示词给 LLM 调成了这种不同状态.
Just like jumble.social does. A timeline consisting of one or more relays.
才得知 Quetta 浏览器极大概率是国产出口的. 责任主体 Quetta Networks Limited 是个注册在英国的私人公司, 网友怀疑只是个空壳.
在它开源之前, 质疑只会越来越多.
Why is Quetta querying Alibaba servers? : r/browsers
https://www.reddit.com/r/browsers/comments/1fbsbvw/why_is_quetta_querying_alibaba_servers/
不是很懂你在说什么. 私信主体全部都是加密的, 配置你的私信收件箱只是为了方便对方发消息给你, 你自己接收起来也更容易. 担心中心化, 随便你喜欢配置多少个, 也没见多少人自己托管中继.
你想要的应该是像丢漂流瓶到太平洋一样不可靠的私信吧.
可以删啊, 刚试过了
Nostr 中文圈： https://following.space/d/musdrpjpdmbr ，值得关注的 nostr 中文用户都在这儿！😎
刚刚开始收集，用户数量很少，欢迎大家推荐&自荐呀~ 😀 #nostr中文
有些跨网的 Fediverse 用户并不算是 Nostr 的, 域名标签是 mostr.pub 和 momostr.pub 的都不是.
必须要配置的只有前面两组收件箱和发件箱中继, 其他的就算不配置也不影响你用 Amethyst. 其他的中继都只是用来精细化设置客户端的行为和中继功能的.
1. 公共时间线中继 (发件箱): 你发帖子的时候 Amethyst 会首先保存这些帖子到的中继.
2. 公共收件箱中继 (收件箱): 你打开 Amethyst 的时候获取消息的时候首先获取的中继, 别人用 Amethyst 提及你和给你发消息的时候也会发到这些中继里面.
3. 私信收件箱中继: 可选. 你专门用来接收别人发给你的私信的中继, 就是收件箱中继, 但是允许你单独设置
4. 私人中继: 可选. 最好是本地中继, 比如 Android 上的 Citrine (黄水晶). 当然你也可以设置成一个只能用你的私钥授权来读取的远程中继, 是用来存草稿和 Amethyst 的本地软件配置的.
5. 代理中继: 可选. 比如 Bostr 这类聚合了多个中继的中继, 这里专门用来读. 如果设置了, Amethyst 就不会完全用信箱模型, 而是优先从你的这个代理中继列表里面查消息.
6. 广播中继: 可选. 和上面的代理中继是反过来的, 这里专门用来写. 也会覆盖信箱模型的行为. 如果设置了, 你发帖的时候会额外往这个广播中继发, Amethyst 还会把这个广播中继作为提示数据直接嵌入到事件的 JSON 里面, 方便别的客户端读取提示.
7. 索引器中继: 可选. Nostr 有一类只会存公钥元数据的中继, 这些中继就和 Google 一样是为了查消息和账号是不是存在有意义的元数据的, 在 Nostr 中主要用来查账号资料和信箱配置(也就是别人的发件箱和收件箱).
8. 搜索中继: 可选. 支持 NIP-50 这个 Nostr 搜索协议的中继. 你用 Amethyst 搜索功能就会优先从这些中继里面查.
9. 本地中继: 可选. 手机本地回环网络里面跑起来的中继(Android 上的 Citrine), 主要用来当缓存用, 可以帮你保存消息, 然后没网的时候也能打开 Amethyst 看, 也可以没网直接发帖, 又网了才重新广播出去.
10. 可信中继: 可选. Amethyst 新版本会默认用内置的 Tor 网关来连那些被 "隐私选项" 里面选项命中的中继, 随着你改隐私配置, 大部分中继就会变成不可信的中继, 所以 Amethyst 就决定用 Tor 来连. 你要是有自己的代理方案, 直接去隐私选项里面的 "Tor 和隐私预设" 改成基础就好了. 如果不改, 这部分设置里配置的中继即使是不可信的, Amethyst 也不会用 Tor 去连.
11. 屏蔽的中继 (中继黑名单) : 字面意思, Amethyst 任何时候都会拒绝去连的中继. 后续会被重新翻译为 "中继黑名单".
哪有 "干掉" 中心化就能成就去中心化这种简单的事情, 海底光缆你能干得掉? DNS 和 BGP 也干不掉.
这种底层协议顶多只能保持向前兼容性去替代.
ECH 还是太试验状态了, 除了 Cloudflare 之外 Akamai 和 AWS 都没想法, 更别说其他供应商了, Cloudflare 自己也给高级计划默认禁用了 ECH, 现在就像 Cloudflare 在用免费客户测试这个功能, 免费计划默认开启, 无法禁用.
反制的办法也很多, 除了对 ECH 的那个还是要用的那个通用 SNI 下手. DNS 层面也能直接对 HTTPS 记录动手, Cloudflare 也针对有流量控制需求的企业给出了具体的办法:
> https://developers.cloudflare.com/ssl/edge-certificates/ech/#enterprise-network-applicability
ECH 只是个对 TLS 1.3 的隐私改进, 不是给抗审查设计的. 如果不使用大型供应商提供的服务去把那个通用 Client Hello 隐藏进他们的 SNI 里面, 那独立部署实现 ECH 其实只是给 SNI 找了个替身, 就像客户端本地的 SNI Proxy 一样, 现在变成了服务端配置, 而且还需要 DNS, HTTP 客户端和 Web 服务器共同努力, 感觉会比 QUIC 还难推进. 真的实施, 供应商完全可以为不同客户实行 KYC 后根据客户的特征分配不同的通用 SNI 标志, 免费用户一个 SNI, 付费用户一个 SNI, 欧盟用户又一个 SNI.
DoH, DoT 和 DoQ 都得经过 TLS 和 DNS Bootstrap 才能进行 DNS 解析, 这是个先有鸡还是先有蛋的问题. 我觉得 ECH 主要还是补上了这些加密 DNS 的最后一块拼图, 把加密 DNS 的的 SNI 也隐藏在了通用 SNI 下面. 不过就我个人来说, 加密 DNS 完全可以用 IP 证书, 这就直接没了 SNI 也不需要 DNS Bootstrap, 很适合小规模部署 DNS 代理的组织和个人(也不知道市场里的 IP 证书是否经济实惠). 现阶段几乎所有(包括积极跟进 ECH 的 AdGuard)的 DNS 客户端在查询这些加密 DNS 上游的时候都没有支持 ECH, 当然最主要的还是这些加密上游都没有支持并且用到并且核心开源库也都没支持.
#AdGuard 在 23 年给自己作为 HTTPS 中间人过滤这个角色加入了 ECH 客户端, 所以现在理论上 AdGuard 能给所有的加密连接过滤之后发出之前全部启用 ECH. 所以这也是个问题: 反病毒安全软件的 HTTPS 中间人过滤会直接破坏 HTTP 客户端(特别是浏览器)的原生 ECH, 如果安全软件不能在请求过滤之后发出本机之前重新恢复 ECH 那浏览器们一众实现的客户端侧 ECH 就失效了. 我也不知道 AdGuard 是在安全软件之前还是之后过滤加密流量, 越来越觉得 AdGuard 有点像个不能反病毒的安全软件了.
> https://forum.eset.com/topic/38340-web-access-protection-and-encrypted-client-hello-ech/
对于 ECH 的问题现阶段的问题还是一众浏览器们都只会在设置里面显式启用加密 DNS 之后才能启用 ECH, 这就意味着本地 DNS 代理和路由器下发的 DNS 服务器配置都实际对有这种强制要求 HTTPS 记录查询也加密的客户端无用. 所以如果不使用 AdGuard 这样的中间人, 就得给自己的本地网络回环下部署的 DNS 代理也上 SSL 证书, 然而这又撞上了自签证书的信任问题, 不过好在有 mkcert 这种工具包简化了自签本地证书并信任的流程.
简而言之, 现阶段的 Edge, Firefox 和 Chrome 主流浏览器都对 ECH 启用条件十分苛刻, 它们不允许用户在使用本地回环网络的 DNS 服务器的情况下启用, 即使它们本来的上游就是加密 DNS 也能完成 HTTPS 记录的中继. 而非浏览器应用的 HTTP 客户端更没有动力去支持 ECH.
> https://github.com/DNSCrypt/dnscrypt-proxy/wiki/Local-DoH#creating-your-own-certification
PS: AdGuard for Windows 现阶段依旧还在解决和带有 HTTPS 过滤的反病毒安全软件之间的兼容性问题.
ECH 还是太试验状态了, 除了 Cloudflare 之外 Akamai 和 AWS 都没想法, 更别说其他供应商了, Cloudflare 自己也给高级计划默认禁用了 ECH, 现在就像 Cloudflare 在用免费客户测试这个功能, 免费计划默认开启, 无法禁用.
反制的办法也很多, 除了对 ECH 的那个还是要用的那个通用 SNI 下手. DNS 层面也能直接对 HTTPS 记录动手, Cloudflare 也针对有流量控制需求的企业给出了具体的办法:
> https://developers.cloudflare.com/ssl/edge-certificates/ech/#enterprise-network-applicability
ECH 只是个对 TLS 1.3 的隐私改进, 不是给抗审查设计的. 如果不使用大型供应商提供的服务去把那个通用 Client Hello 隐藏进他们的 SNI 里面, 那独立部署实现 ECH 其实只是给 SNI 找了个替身, 就像客户端本地的 SNI Proxy 一样, 现在变成了服务端配置, 而且还需要 DNS, HTTP 客户端和 Web 服务器共同努力, 感觉会比 QUIC 还难推进. 真的实施, 供应商完全可以为不同客户实行 KYC 后根据客户的特征分配不同的通用 SNI 标志, 免费用户一个 SNI, 付费用户一个 SNI, 欧盟用户又一个 SNI.