好像新版本的damus发消息时计算出来的event id有问题?有些relay不接收?

大家能看到我上一条消息吗?

盲猜是草稿箱功能带来的bug……

Reply to this note

Please Login to reply.

Discussion

可以

我这看不到。

除了pow外,relay会验证id么,应该是客户端验证吧?

道理上是这样,但是我试了一下,起码最热门的nostream和strfry这两个relay实现都是会验证event id的:

如果sha256对不上的话,会分别返回"invalid: event id does not match" 和 "invalid: bad event id"。

这一点确实和文档不一致。

嗯,了解了,我也不知道就问问,记得最早fiatjaf提出nostr时候说不用,不过实现了也能提供些好处

今天上午遇到了和 #[0] 兄一样的问题,发出的消息在nostr.band看不到。

为了调查这个问题,我使用websocket手动连接relay并重放event来测试,发现了几个有趣的点,和大家分享:

1.通过damus消息右上角的三个点,可以选择复制json,但这个json会丢掉emoji 表情,这就导致我在手动重放时,relay一直返回event id错误(event id 是把消息体sha256得到的,因为消息体少了emoji 表情,所以sha256就对不上了),但是换成其他消息又是正常的,于是就怀疑是早上damus更新导致的问题。后来证实是因为json串里丢了那个⚡️emoji 表情,这应该是个bug。

2.从上面一条就可以看出,虽然nostr文档提到relay不校验event id ,但起码对于重放的event(比如在damus中点击广播,或者手动通过websocket发json),nostream和strfry这两个relay是会校验event id的。

3.早上最初的消息不显示问题,大概率是 nostr.band网页自身的问题,或者我自己手机到relay的连接性问题,这就让我有个猜测:damus在发消息时类似udp,只管发送,不管relay有没有收到,就算超时也不会重发。这个其实在网络不好时有一定的隐患,可能消息只发到了少数几个relay,对于消息传播性和可用性都有不良影响。这也就凸显了relay聚合器的作用。

#[1]

Nostr.band的内容,应该不是实时显示的,relay数据也只是一小部分,并不完全

确实,也不能完全依赖它