replaceable event 为什么会有这个问题?是不是使用的方式不对

Reply to this note

Please Login to reply.

Discussion

用eventid作为 bookid,所以就会这样。 书的所有章节 如何知道是这本书的,都是通过eventid关联的。

如果“书”是一个可变事件,就不应该使用 event id 做关联

“书” event:

kind: 3xxxx

d-tag: booka

// 其他信息……

文章 event:

kind: 30023

d-tag: booka:a

A-tag: 3xxxx:pubkey:booka // A-tag 是参考 NIP-22 的定义

d-tag: booka 这里有个问题要求是不重复的书,如果很多人建立书,不重复 我就想用eventid挺好的,结果。。。现在知道了这个问题,如果当初设计为uuid 也可以。 当然如果专门解决这个问题用一个空事件来产生一个eventid 也可以的。

只是最初设计的时候没有想到这个问题。现在的方案基本是类似的,修改后记录老的eventid(就相当于用了他的id功能了),

d-tag 不存在多人导致重复的问题,它是跟 pubkey 的。空 event 还不如 uuid

那么用户需要自己命这个 d-tag,也就是创建书的作者来写d-tag ?之前eventid比d-tag方便的点,就是eventid 在写书,展示书的时候 一次索引就可以,如果用d-tag是不是需要2次索引。

其实我还有另一个疑问,我之前发30023,发现d-tag 是5,6位数(含字母),那么是怎么保证 这5,6位不重复的呢?

谁来命名 d-tag 不重要,你可以用 title + 随机字符串生成 d-tag,也可以直接随机字符串。五六位的 d-tag 可以包含多少个事件了😂 一个人不至于产生那么多文章吧,觉得不保险可以加多几位。

我不太明白你说的两次索引是啥意思,有 kind, pubkey, d-tag 就可以直接找一个事件了

》》五六位的 d-tag 可以包含多少个事件了😂 一个人不至于产生那么多文章吧 ,

关键的问题是,如果设计的 正好重合了,就会把用户的旧书给覆盖了。为了防止重合 每次去把用户的历史记录拿出来排重,这显然不可行。

我觉得不是很需要考虑,五位已经上千万了,如果你用 title + 五位随机数,我不认为需要考虑重复的情况

这个问题类似于,如果有人生成了别人在用的比特币地址该怎么办

差不多,我看了ndk源代码是title+6位随机数,如果没有title就是16位随机数。概率应该很小了。