有点难以想象, 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
