©CC BY-NC-SA 4.0
🚩加入 Nostr!moe 社区: join.nostr.moe
🚩加入 Nostr!moe 社区: join.nostr.moe
路上我遇到了一个三岔路口, 行人大部分都在往右, 寥寥几人在往左, 没有人往中间, 但我知道这几条路的目的地其实都是一个, 所以我出于好奇选了中间. 走到目的地接下来是一个 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, ...
这次版本新地图给的花灵「斯露莎」很不错, 除了新的玩法开发, 还拓宽了玩家的 Z 轴地图视野, 对后期地图探索帮助非常大.
使用斯露莎的状态下, 玩家 XYZ 轴可以额外获得 80m 的自由移动范围, 并且不会吸引怪物仇恨. 不过可惜的是只能在荒石苍漠和浮罗囿这两个地区使用. #原神
via CXPLAY's Memos
使用斯露莎的状态下, 玩家 XYZ 轴可以额外获得 80m 的自由移动范围, 并且不会吸引怪物仇恨. 不过可惜的是只能在荒石苍漠和浮罗囿这两个地区使用. #原神
via CXPLAY's Memos
也在大多时候, "网络服务提供商" 只是指提供互联网接入服务的 ISP, 它们也应该只提供网线, 光猫和路由器. 但实际情况下, 只有这三件, 并不就能直接访问 "网络服务", ISP 只给了我进入森林的门票, 而我是一个三次元的生化物体, 可看不懂这数字森林里的 0 和 1. 于是我需要一种工具, 把这些 0 和 1 转译为我人能看得懂的东西, 于是才能看见森林里的鸟和花草树木. 但问题来了, 我所看到的这些鸟和花草树木并不是我自己直接看到的, 是我用的工具转译后才有的, 我作为一个三次元的人并没有直接与数字森林交互的能力. 我在数字森林里需要一双 "手" 去触摸和交互, 需要一个 "大脑" 去存储我想要的一些, 也许还需要一张 "嘴" 去交流信息. 所以我必须还要选择对应的工具来实现这样的目的, 三次元中的工具于是被悄无声息地带到了数字世界. 但可惜, 这些卖工具的逐渐希望你 "租" 它们, 而不是 "买" 他们, 越来越多的工具都争先恐后地想要自己长一个 "大脑", 想要自己存下属于你的东西. 这是好事吗? 也许是好的, 因为森林里的工具不在是无意识的工具, 有的应该可以被称作是 "机器", 设定好你想要做的事情后就能自己在森林的工作, 这是极好的. 但这在三次元里也是这样的, 并且我可不希望一个能够定时工作的电饭煲居然还要租. 我也很清楚, 购买一个崭新的电饭煲并不妨碍制造电饭煲的推出全新一代的产品, 如果它们确实比我现在用的好, 我也有能力购买新的, 那为什么不会去买呢? 难道是有别的厂的电饭煲比这家的好用? 或者是, 新一代产品还不如旧一代? 哈哈, 拜托, 货比三家可是作为一个消费者所应该必备的技能, 也不妨碍我比比同一家的旧产品. 我能买, 并且有必要, 那我不会选择去租. 但是租也有租的好处, 我能租一个月的跑车开开, 体验一下同样是跑车为什么卖的价格这么不一样, 在森林里这叫 "试用", 不过有些跑车, 只能租不能买, 而有的跑车开之后才发现是一台拖拉机, 不仅它服务你, 你还要服务它. "租借" 和 "买断" 应该是同时进行的选择, 应该是可选的, 至少在定价时就应该被考虑到. 制造工具的应该知道对下一代产品的制造可能与买断的收入与制造成本达成不了平衡, 可能是因为产品本身难以再进步, 也可能是产品提供的服务对于制造者来说是一个长期支出. 但也有的就是在 "租借" 掩盖自身不思进取的的想法. #吐槽
via CXPLAY's Memos
via CXPLAY's Memos
