Tell me about amethyst draft events.
Where is the pain here?
Discussion
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?