Aspie96 on Nostr: > At least for now, kind1 is the common ground everybody has and it should remain ...

> At least for now, kind1 is the common ground everybody has and it should remain that for the foreseeable future, at the basic level it's super easy to get started, easy to read, easy to write, easy to display.

I think it should remain the case *forever*.
Other protocols will work differently, but Nostr should remain (uneditable) kind1-focused, in my view.

I also have my objections to edits on Nostr.

quoting nevent1q…3rt5

FWIW, I think deletions on Nostr are a "meh" idea and edits are a bad idea. Consider the following:

- It's an additional layer of complexity. Nostr should arguably be simpler and it's already more complex in some ways centralized platforms are not.
- Different relays will disagree on whether to accept the edit or the delete event, so the original note may stay available. It may also become apparently unavailable and then available again in the future. Someone could send the old version to relays you don't use.
- Unlike some specific features like articles, zaps and whatever one can think of, it only makes sense if consistently implemented, but that's something we can only assume to be true of NIP-01.
- It makes retrieving a note less efficient. You now need to wait a response from all relays, just in case one of them has a deletion or a modification the first one to reply doesn't have.
- There is value in having modifications, but there is also value in having platforms that don't allow modifications, IMO, where an ID truly identifies a specific piece of text and nothing else. Now that Twitter allows modifications, Nostr can use the fact that it doesn't to diversify itself so as to convince users to use both (otherwise the network effect plays against Nostr).

On centralized platforms which allow modifications, users sometimes write a post with the plan of modifying it later. On Nostr that would be a bad pattern, however and I think the modification features can lead to bad usage of Nostr and, therefore, a bad user experience.

Ultimately it will prevail if clients and relays implement it and fail otherwise, but I'm not in favor of it.