©CC BY-NC-SA 4.0
🚩加入 Nostr!moe 社区: https://join.nostr.moe
🚩加入 Nostr!moe 社区: https://join.nostr.moe
刚买手柄的时候由于游玩环境里的无线信号条件比较复杂所以不得不用有线连接手柄, 但是一般的 USB-C 数据线都太粗太硬了, 有点碍手, 于是想着有没有一种又细又软的 C 口数据线, 但找了很多地方店都没有合适的. 现在用的线是小米的十块钱白色 C 口数据线, 不是很细也不是很软, 但好在不碍手, 勉强能用. #吐槽
via CXPLAY's Memos
via CXPLAY's Memos
路上我遇到了一个三岔路口, 行人大部分都在往右, 寥寥几人在往左, 没有人往中间, 但我知道这几条路的目的地其实都是一个, 所以我出于好奇选了中间. 走到目的地接下来是一个 T 形路口, 路牌指着往右, 路面标记画着往左, 地图上标记着往右, 行人都在往左, 交通管制人员在指示来这边的人往右. 但是我不知道这次我要去的目的地是应该往左还是往右. #吐槽
via CXPLAY's Memos
via CXPLAY's Memos
另外, 对 nostr 的探索记录除了会发在我的主页还会发在新的 Telegram 频道:
https://t.me/nostrzh
有点难以想象, 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
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
Mailspring 是个很不错的电子邮件客户端, 但是现在只要登录了他们的账号, 就会在通过它们客户端发送的邮件里附加一个 1 像素的 GIF 图片, 用来跟踪邮件阅读回执. 问题在于这个邮件阅读回执是高级订阅才能使用的, 但就算不订阅他们的高级订阅还是会附加跟踪像素, 也看不到分析结果.
类似的问题在两年前被提出:
https://github.com/Foundry376/Mailspring/issues/33
期间由于链接追踪用的域名 SSL 证书过期还影响到了正常使用(让用户发出了一些暴论)
https://github.com/Foundry376/Mailspring/issues/2231
后来社区为了摆脱对 Mailspring 自作主张造成的中心化依赖还出了一个专门用来解决该问题的分支版本 Mailspring-Libre:
https://github.com/notpushkin/Mailspring-Libre
最后在上游一次提交中合并了一个可选退出追踪的方式: 在使用客户端可以选择不登录帐号, 那就等于无法获得帐号对应的追踪用 CID, 于是邮件同步器里的值就变成了空值...
问题被一种「曲线救国」的办法解决了, 但是不登录帐号大部分增强功能都不能用, 比如邮件全文翻译, 而插件生态又几乎为零. 已读回执居然不是种可选的功能, 高级订阅好像还对邮件内的链接内嵌追踪...
我还从来没有见过哪个电子邮件规范有做到已读回执, 对于这种类似的功能, 在即时通讯上也许会很好, 但是对于电子邮件未免有些变态. 大多使用了已读回执的, 收件人对此都是不知情的状态, 这倒是很像一些社交分享里不请自来的跟踪器. #nostr
类似的问题在两年前被提出:
https://github.com/Foundry376/Mailspring/issues/33
期间由于链接追踪用的域名 SSL 证书过期还影响到了正常使用(让用户发出了一些暴论)
https://github.com/Foundry376/Mailspring/issues/2231
后来社区为了摆脱对 Mailspring 自作主张造成的中心化依赖还出了一个专门用来解决该问题的分支版本 Mailspring-Libre:
https://github.com/notpushkin/Mailspring-Libre
最后在上游一次提交中合并了一个可选退出追踪的方式: 在使用客户端可以选择不登录帐号, 那就等于无法获得帐号对应的追踪用 CID, 于是邮件同步器里的值就变成了空值...
问题被一种「曲线救国」的办法解决了, 但是不登录帐号大部分增强功能都不能用, 比如邮件全文翻译, 而插件生态又几乎为零. 已读回执居然不是种可选的功能, 高级订阅好像还对邮件内的链接内嵌追踪...
我还从来没有见过哪个电子邮件规范有做到已读回执, 对于这种类似的功能, 在即时通讯上也许会很好, 但是对于电子邮件未免有些变态. 大多使用了已读回执的, 收件人对此都是不知情的状态, 这倒是很像一些社交分享里不请自来的跟踪器. #nostr
Hexo 新版好像新增了一个功能? 在启动本地预览服务器后编辑可以被实时渲染的源文件时, 如果源文件语法导致渲染错误会直接把源文件回退到上一次修改. #吐槽 #blog
via CXPLAY's Memos
via CXPLAY's Memos
nostr 速览
「Gab和Mastodon的例子清楚地表明，仅仅有代码的开放是不够的。建设过程和标准的设计也必须是开放的。否则就会出现一小队人马，大部分是自愿为一个活动项目工作，最终成为该平台的 "仁慈的独裁者"。」
> rust-nostr/VISION.md at main · rajarshimaitra/rust-nostr · GitHub
#nostr #article #read
「Gab和Mastodon的例子清楚地表明，仅仅有代码的开放是不够的。建设过程和标准的设计也必须是开放的。否则就会出现一小队人马，大部分是自愿为一个活动项目工作，最终成为该平台的 "仁慈的独裁者"。」
> rust-nostr/VISION.md at main · rajarshimaitra/rust-nostr · GitHub
#nostr #article #read
互联网中常见的几种通讯方式按照效率和碎片化程度排行的话: 1. 博客(Blog) 2. 电子邮件(Email) 3. 短信(SMS) 4. 社交媒体(SNS) 5. 电话(Tel.) 6. 即时通讯(IM) 越靠后效率越高, 但碎片化的概率也越高. #note
via CXPLAY's Memos
via CXPLAY's Memos
试试 nostr：
Pub:
Relay:
Pub:
npub1gd8e0xfkylc7v8c5a6hkpj4gelwwcy99jt90lqjseqjj2t253s2s6ch58hRelay:
wss://nostr.cx.ms #note
Guest Post: An Introduction to The Dandelion Dynasty by Ken Liu
#article #read
#article #read
Fanfiaddict
Guest Post: An Introduction to The Dandelion Dynasty by Ken Liu | FanFiAddict
Welcome to Dara! This series took up the bulk of my time and creative energy over a ten-year period. I learned a lot about myself as a writer, as a father, ...
