一种中间人攻击.
> 当人与人之间的信任崩塌后, 最后只能靠计算机重新构建信任网络.
不知道什么时候开始, 大多数人下意识认为 HTTPS 就等于 "可信", 可能是浏览器的那个上锁的图标, 也可能是各种软件里面喜欢用 "可信" 等同于 "加密", 不过那时也不会有人愿意解释也不会有人听为什么 SSL 证书只能做到加密. 到了 HTTPS 在攻击, 防御和渗透中成为常客, 普通用户也经常被 HTTPS 网站钓鱼攻击的时刻, 越来越多人意识到即使 "信任" HTTPS 代表的加密应该被理解为对中心化 CA 机构的信任, 但这种责任转嫁很显然这些证书机构也不想承担, 毕竟他们也在审计这块大费周章也没有改变什么, 这样只会让 SSL 证书的价格越来越高, 诞生越来越高等级的证书, 比如 OV 和 EV 证书, 那么这些 OV 和 EV 证书就能代表 "可信" 吗? 对用户来说, 信任一家商业公司都已经变得越来越困难, 更不用说要在 OV 和 EV 证书里还要信任 n+1 的机构数量.
即使说过 SSL 证书不代表信任只代表传输加密, 宣传工作也进行了很多年, Google 也决定在 Chrome 里把那把用户首先看到的锁换成别的或是藏在二级页面. 但没有什么效果, 因为对 HTTPS 的信任危机已经演变成了对中心化的信任危机, 证书不仅要依赖中心化机构签发, 还要被操作系统 "默认" 信任. 于是连带着对域名系统的不信任的 DNSSEC 后, 对 SSL 证书不信任的 DANE 也出现了. 它们俩代表着人们发现问题并提出解决办法的行动力, 但太早期了, 先进的理念还要被市场验证, 这可能要花很长时间.
早，感觉没睡够，又要回笼觉了。😴
有的人还没睡，有的人刚刚醒。
"你真恶心"
#沙雕
Twitter 开始统一把缩略图的图片格式设置为 WebP 了, 开源节流还在继续.
不登陆小米账号就常驻通知，真有你的 MIUI。
https://media.naeu.net/m/2023/08/02055549-1690955749-IMG_20230802_135503.webp
几个用 rsslay 创建中文资讯账户, 直接从客户端时间线阅读这些订阅内容.
需要在客户端添加 wss://rsslay.nostr.moe 中继为只读才能看到.
Solidot: nostr:npub1mwz0dmq9fev8c6hsvfj6zwzrk8kjzalpfjwspn54jf5mjej2p48qps2qgj
蓝点网: nostr:npub1yx53sqsmfn3khx37alp2xvn94plx6d6gexkalnsjmnl74nv7x2ssm2av4j
少数派: nostr:npub1flsccfq94uwgxacqyarjw9vhq947luzhe9klahe96edltg669v6ss23636
刚才打开微信才看到，感谢支持🥰。1000...0650 #鸣谢
才发现 Mozilla.Social 五月四日公开了候补名单🤣那个时候我还在和 Nostr 搏斗.
https://blog.mozilla.org/en/mozilla/mozilla-social-mastodon-private-beta-announcement/
候补名单: mzl.la/mozsocial
有点难以想象, nostr 用于实现转发动态的提议 NIP-18 居然不包含任何上下文(甚至不指向被转发的目标动态). 社区里的一些人似乎还很喜欢用人品来评价作品.
https://github.com/nostr-protocol/nips/pull/140
我对此的看法发表在同一个 issue 串上:
https://github.com/nostr-protocol/nips/pull/140#issuecomment-1534191629
---
今天, 我在探索 nostr 的时候不可避免地遇到了相同的问题: https://github.com/scsibug/nostr-rs-relay/issues/122
但这次我只是一个并不精通编程技术的普通 nostr 用户, 但我依旧想要发表一些我的想法:
在此之前, 需要提到 "repost", "comment", "reply", "quote" 和 "ref.", 这几种类型在我写作的时候经常遇到, 所以需要先明白这五个概念并不完全相同:
1. "repost": 将一个事件重新发表到自己的时间线上, 它可以是本来就是自己已经发表过的事件, 也可以是别人的事件. 并且, 这些事件可以是任何种类的事件, 比如是 NIP-23 定义的 kind-30023, 也可以是 kind-1 中的常规事件. 并且 "repost" 不需要存在新内容(相对于被 "repost" 的目标事件).
2. "comment": 对一个事件的评论(注意, 不是 "reply"), 这与 "reply" 常常混淆在一起, "comment" 是需要有明确上下文的事件, 但 "reply" 不需要.
3. "reply": 这本应该只在即时通讯中使用, 不过由于 nostr 也可以做到 IM 所以也应该加入到这个列表中. 因为 IM 不会一直是线性的, 所以它其实根本不需要上下文, 如果需要也变成了另外的一个: "quote".
4. "quote": "repost" 另外一个事件和包含对此事件的 "comment" 的独立事件, 这与 "repost" 的区别是: 它必须包含新內容, 否则就不构成 "quote". 常常也与 "ref." 产生混淆. 实质上, 实行 "quote" 就是同时 "comment" 并且 "repost" 一个事件.
5. "ref.": 在一个事件中包含另一个事件的内容, 用于组成本事件内容的一部分. 由于互联网由 URL 组成, 所以在这里, "ref." 的内容也可以是另一个事件的 URL. 这里也存在上下文, 但是是用户手动摘录的其他事件内容或者 URL, 是本事件内容的一部分.
1. repost = Post an existing event.
2. comment = Post content that points to the context.
3. reply = Post content but no context(Specifically in IM).
4. quote = Post an event containing already existing events and comments.
5. ref. = Part of the event content, but this part is extracted from other event content.
---
所以, 对于 repost 最重要的是什么? 是要包含一个已经存在的事件, 然后才能发展出 repost 和 quote. 并且与 comment 不同, 他必须是一个独立的事件.
对于这种 repost 存在的性能负担应该是客户端的, 因为中继应该只提供这个 repost 中包含的是哪一个已经存在的事件的 ID(?), 客户端会进一步检索这个已存在的事件然后显示出来.
repost 并不需要包含那个已存在事件的内容, 相反, 如果这样做则更像是在 NIP-23 的长内容里 embed 了一个完整的 JSON 表单, 这样的话就应该遵守 NIP-23 的规范.
#nostr
才发现 Mozilla.Social 五月四日公开了候补名单🤣那个时候我还在和 Nostr 搏斗.
> https://blog.mozilla.org/en/mozilla/mozilla-social-mastodon-private-beta-announcement/
候补名单: https://mzl.la/mozsocial
#社交媒体
本来打算给手里的小米解锁 Bootloader 刷类原生的，结果都备份好了给我来个账号要绑定设备 168 小时。🥲
加拿大人明天就去住火星
瑞士的永久中立和银行业保密已经成为历史了，如果还有人用瑞士这个国家做保密和中立的招牌，我会直接当作是笑话。
