What is Nostr?
fiatjaf /
npub180c…h6w6
2025-02-16 15:36:25
in reply to nevent1q…qxqh

fiatjaf on Nostr: I also remember when cameri proposed the "d" tag for replacing events based on that ...

I also remember when cameri (npub1qqq…n47m) proposed the "d" tag for replacing events based on that parameter instead of based only on the author's public key. I couldn't see any use case at all for it for many months, and the use cases he cited were not very convincing to me either.

Then suddenly both I and many others started thinking about way too many things in terms of "parameterized replaceables", culminating with Alex (npub1q3s…d26p)'s proposal that even poll votes and likes should be such "addressable" events. At that point I realized things had gone too far and now I see a healthy move towards doing more things as "normal" events, such as kind:20 photos and kind:21 video events, Kieran (npub1v0l…qj49) has also recently proposed getting rid of the notion of replaceables. mikedilger (npub1acg…p35c), jb55 (npub1xts…kk5s) and Clojure lover hodlbod (npub1jlr…ynqn) have also spoken against replaceables in the past if I'm not mistaken, even though I think both had a short period of love for them too. Me too, recently, every time I have to deal with addressable events in the context of querying handcrafted databases, feel their pain.

Most things can be "normal" actually, even if they have to change. If you control where they're being publish you can always delete them. But also dealing with events as "facts in the past" helps. If you liked something at some point that doesn't mean you can't dislike it at some other point in the future, and so on.

On the other hand, because of practical concerns since we don't live in the clouds of Rich Hickey, I think all user metadata stuff and all NIP-51 lists should be replaceable still, because these things are updated rarily and then fetched thousands of times by many apps and clients everywhere. Telling all these readers to fetch dozens of events for each target author-kind combination and compute the result locally would be too much of a burden.
Author Public Key
npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6