Anthony Accioly on Nostr: Not according to Vitor Pamplona. To be fair, NIP-01 states: > for kind n such that ...
Not according to Vitor Pamplona (nprofile…deau). To be fair, NIP-01 states:
> for kind n such that 10000 <= n < 20000 || n == 0 || n == 3, events are replaceable, which means that, for each combination of pubkey and kind, only the latest event MUST be stored by relays; older versions MAY be discarded.
So, my interpretation is the same as yours (i.e., Amethyst / clients should be filtering for the latest event instead of expecting relays to return only the most up-to-date event). Still, upserting replaceable events by kind and pubkey is a reasonable suggestion. Either way, I just want one side to fix this so that Amethyst stops spamming my relays :D.
> for kind n such that 10000 <= n < 20000 || n == 0 || n == 3, events are replaceable, which means that, for each combination of pubkey and kind, only the latest event MUST be stored by relays; older versions MAY be discarded.
So, my interpretation is the same as yours (i.e., Amethyst / clients should be filtering for the latest event instead of expecting relays to return only the most up-to-date event). Still, upserting replaceable events by kind and pubkey is a reasonable suggestion. Either way, I just want one side to fix this so that Amethyst stops spamming my relays :D.