©CC BY-NC-SA 4.0

频道: cx.ms/channel
笔记: cx.ms/memo
博客: cx.ms/blog
剪贴: cx.ms/clip
社交: cx.ms/sns
#吐槽

In reply to nevent1q…z6ga
_________________________

找了一份自动字幕, 用 Gemini 2.5 Pro 做了一份机翻字幕, 视频也传到了123云盘, 虽然下个字幕不用登录账号, 但还是单独传了个字幕.
现在去用磁力下应该能秒离线了: a539fb0cfb3d86b1b505e5d1a1adf3bd32bd99b1

视频: https://cue.su/u/eel-jaguar-goat 提取码: 2643
字幕: https://cue.su/p/sloth-seal-mole

有效期一周

via Nostr@cxplay
#吐槽

小子, 这不只是去中心化, 这还有分布式!
一条消息在 Amethyst 完全体的信箱模型里面直接被发到了 40 个中继上, 恐怖如斯 :bili_fantastic:

via Nostr@cxplay
#吐槽

In reply to nevent1q…yx4f
_________________________

必须要配置的只有前面两组收件箱和发件箱中继, 其他的就算不配置也不影响你用 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 任何时候都会拒绝去连的中继. 后续会被重新翻译为 "中继黑名单".

via Nostr@cxplay
#吐槽

看了一个过时的国内某技术交流活动的吃瓜集锦 PPT, 包含要素过多: 未成年, 跨性别, 女权, 性骚扰, 商业内幕, 个人隐私, 公关危机, 黑吃黑, 草台班子, 诉讼威胁

还挺有意思的, 特别是 "商业内幕" 部分, 其他的要素全都是直接或间接源自领导班子.

via Nostr@cxplay
#吐槽

#雀魂 的角色养成难度比米哈游的角色养成还要难, 其他二游都是活动来发抽卡资源的, 雀魂是拿活动发角色养成资源.
终于给我的一姬养得终于会说话了, 泪目, 孩子终于会说话了. :bili_fantastic:

via Nostr@cxplay
#吐槽

#雀魂 排位是这样的, 一不注意它就⬇️⬆️⬇️⬆️⬇️⬆️给你看, 打一天跟没打一样.

via Nostr@cxplay
#吐槽

很多晚上通风的时候从窗缝飞进卧室的甲虫和蜜蜂都是在里面力竭而死的, 到处乱飞乱撞, 喜欢撞顶灯和玻璃窗. 晚上还是要拉窗帘.

via Nostr@cxplay
#吐槽

In reply to nevent1q…4e6p
_________________________

Accent and pronunciation issues have always been an obstacle for learners of English, and I think it's not a serious issue, just as internet memes mocking British pronunciation are partly a result of human influence, It's overblown. My teachers used to emphasize the difference between "British" and "American" English and correct us on our Chinglish, but luckily, a lot of schools emphasize English but don't actually test students' speaking skills at all🤷‍♂️

via Nostr@cxplay
#吐槽

想做个专门代理短链接的小玩具, 之前在 URLCheck 那篇文章里面说过, 短链接的隐私问题可以用代理分流来缓解. 但是没有代理怎么办呢? IP 之外的信息如何剥离? 访问一个链接并不需要多完整的 User-Agent. 短链接就算只是 30x 实现的, 访问也得跑到浏览器里面, 送给它一堆客户端标头, 这是不必要的.

我对短链接的看法一直是中立的, 谁都可以用, 我也在用, 不要妨碍我选择不用就行了. 有时原文被到处复制和保存之后, 作者实际上就是失去了对原文的控制. 这在网上倒也无所谓, 如果不能要求删除, 那我就会用短链接把重要的东西包在里面, 在我想要的时候随时让它失效.
这里表达的意图是: 原文包含的只是短链接, 我只为现在我写的和引用过的文字以及这条链接负责, 如果失效, 就说明短链接被我主动删除了, 链接背后的东西也不再是解释本文的必要内容.

毕竟所有外链都不受第一来源控制, 费尽心思加外链中间页的目的除了获得分析数据, 也在声明链接归属和预防有些不稳定外链指向什么不该指向的东西, 这个 "门" 可以被人常开, 但没有门就变成自己的问题.

我建议所有网络出版物, 在对外链产生疑虑的时候使用完全受第一方作者控制的短链接来包装一遍, 也要尽量避免使用那些不必要的外链, 或者去使用存档快照来确保未来的任何时刻访客看到的外链内容都是和自己当前一致的. 出版物重新分发次数越多, 作者对其保留的解释权就越弱, 被其他人重新解释和演绎的概率就越大, 网络方便了内容出版也方便了这个传播过程.
这可能也是网络时代的网络作家才会有的特有问题, 传统出版物哪里有什么超链接可以用, 只有逼仄的脚注, 网络出版更没有 DOI 这种东西来统一外部引用.

PS: 短链接这种用途对于链接本身删除和链接指向内容的删除应该是要区分 HTTP:404 和 HTTP:410 才合理.

via Nostr@cxplay
#吐槽

"互联网隐私" 是一门很好的新生意, 可以在不冒犯潜在客户的情况下贩卖焦虑, 就算不卖出任何商品, 也能把所有涉及 "隐私" 的供应商的蛋糕越做越大.
就像某紫色邮件和某红色邮件才是事实上的竞争对手, 但他们都会不约而同营销出自己的对手是 "Big Tech" 的样子, 也从来不会撕破脸. 可能是这块蛋糕目前还是太小了吧, 但确实是个 "蓝海" 市场.
比起数字主权这种受制于政治因素的技术趋势, 还是无国界也无边际的隐私更好营销.

via Nostr@cxplay
#吐槽

In reply to nevent1q…6ww2
_________________________

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 过滤的反病毒安全软件之间的兼容性问题.

via Nostr@cxplay
 
 
Back to Top