That's quite a popular opinion actually.
Discussion
In the first day of Nostr we didn't have the concept of "replaceable" anything, but my first relay implementation had kind:0 hardcoded as a replacement target because I didn't want to store a ton of old profiles.
How do you think the incentives would play out going forward with all sorts of event kinds being created?
I also remember when nostr:npub1qqqqqqyz0la2jjl752yv8h7wgs3v098mh9nztd4nr6gynaef6uqqt0n47m 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 nostr:npub1q3sle0kvfsehgsuexttt3ugjd8xdklxfwwkh559wxckmzddywnws6cd26p'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, nostr:npub1v0lxxxxutpvrelsksy8cdhgfux9l6a42hsj2qzquu2zk7vc9qnkszrqj49 has also recently proposed getting rid of the notion of replaceables. nostr:npub1acg6thl5psv62405rljzkj8spesceyfz2c32udakc2ak0dmvfeyse9p35c, nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s and Clojure lover nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn 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.
I never believed reactions should be replaceable. Poll votes are too hard to count if they are regular.
I think replaceable events are very good if only for this:
"nostr_events_replaceable_idx" UNIQUE, btree (kind, pubkey) WHERE kind >= 10000 AND kind < 20000 OR (kind = ANY (ARRAY[0, 3]))
"nostr_events_parameterized_idx" UNIQUE, btree (kind, pubkey, d) WHERE kind >= 30000 AND kind < 40000
The fact they are unique makes lookups very fast.
If we allowed multiple, filters like `{ kinds: [0], authors: [alex, fiatjaf, patrick], limit: 3 }` wouldn't work right anymore and would have to be split into 3 different filters (now 3 individual REQs if only one filter per req).
BTW my solution to insert performance (aside from the obvious ones like rate limiting and blocking Amethyst draft events), is to upsert instead of delete and create. This results in a huge performance improvement for things like giant follow lists.
Whats Upsert?
Tell me about amethyst draft events.
Where is the pain here?
This is an old screenshot. Purple line is Amethyst "draft" events, which is unusually high compared to every other event kind. I was having performance issues. But it wasn't because of this. It was a red herring. So in the end, my biggest issue with it is that it pollutes my logs and makes it look like something bad is happening. I blocked them anyway.
Talked about this with nostr:nprofile1qydhwumn8ghj7emvv4shxmmwv96x7u3wv3jhvtmjv4kxz7gqyprqcf0xst760qet2tglytfay2e3wmvh9asdehpjztkceyh0s5r9ctw9ket already a long time ago, and he says Amethyst is debouncing them. But I've had the kind blocked for so long I don't know if there's any difference nowadays.
If an event kind is only displayed by one client…. Should it be on a relay? Drafts should be local imo
More discussion and rationale here: https://github.com/nostr-protocol/nips/pull/1124#issuecomment-2184077181
Amethyst sends a draft every second!!! A draft should be saved locally. Maybe saved on a relay if the person decide to save the note as a draft.
This is too much.
There is a nostr based drafts NIP. Example use case: start draft on mobile app, continue writing and expand on desktop and larger monitor.
Indeed, that's the reason, but often if I start writing a post and don't submit it there's a reason. I don't want to be haunted by that. 😂
NIPs acceptance don’t adhere to any formal process at this point...Or at least thats how I feel about it.
We are using NIPs as the birth place of nostr…. they really shouldn’t be. Once something is completely implemented, tested, and agreed upon on a large scale. Then it should become official.
We need a NIPs purge.
One issue I see is that NIPs don’t go through stages like TC39 proposals do. NIPs require at least one working implementation, not that most major clients implement it. It would be counterproductive to require major client or relay to support every single NIP before it becomes official.
* requires two implementations
One implementation is not enough.
It needs at least 5 recognizable implementations with all 5 clients commenting on the GitHub NIP signaling full implementation.
1-3 clients is not enough.
No merge process is too loose.
What counts as an "implementation"? It's all subjective at the end of the day. Bureaucratic processes just exist to create confusion and extra work to cover the actual process, which is not and cannot be defined and changes as the power dynamics change.
Agreed.
If i make a PR to add a NIP about some funny Kind i invented. Then me and some other developer decided to implement it in our apps...does that consitute as nostr now and gets added to the list of NIPs.
There must be some decision making process about adding NIPs. whatever that process is, can it be stricter?
Exactly.
Why do you want it to be stricter? What NIPs have been merged that you feel shouldn't have?