-

@ Anthony Accioly
2025-03-09 11:55:09
GM Hoppe. It could work for sure, the main problem with this approach is that kind 1 notes were standardised a long time ago with inlined and signed content. Changing this would require every relay, client, and library to adjust how they handle one of Nostr’s most fundamental kinds.. In other words, it would be like a Python 2 to Python 3 migration (but in a distributed, decentralised) ecosystem. So, IMO, breaking changes like this should be a last resort.
nostr:nprofile1qqsyvrp9u6p0mfur9dfdru3d853tx9mdjuhkphxuxgfwmryja7zsvhqpzamhxue69uhhv6t5daezumn0wd68yvfwvdhk6tcpz9mhxue69uhkummnw3ezuamfdejj7qgwwaehxw309ahx7uewd3hkctcscpyug's proposal /Amethyst’s implementation uses a new kind 1010 event, which tags the original kind 1 note. The great thing about this approach is that it allows for timestamp versioning. Clients that don’t want to deal with edits can simply ignore kind 1010. The issue, as outlined in Fiatjaf’s article, is that clients must track (i.e., store and cross-reference before displaying) both kinds of events if they want to support edits. In other words, it’s no longer a simple query for kind 1 notes and forget workflow.
GitHub link: https://github.com/nostr-protocol/nips/pull/1090/files
Here’s a good tracker thread for alternative proposals:
GitHub link: https://github.com/nostr-protocol/nips/issues/1569
I’m not sure if it covers all edit proposals, but it links to great discussion on different ways to handle updates, including two alternative proposals by nostr:nprofile1qqsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8gprfmhxue69uhkcmmrdd3x77pwve5kzar2v9nzucm0d5hszxnhwden5te0wpuhyctdd9jzuenfv96x5ctx9e3k7mf0qydhwumn8ghj7un9d3shjtnhv4ehgetjde38gcewvdhk6tc4rdlnm:
1. A "delete and publish a new note" approach.
2. A method similar to what you’re suggesting, but backwards compatible. Basically it suggests a kind 1 note quoting a new replaceable kind 31000 note.
The PRs and comments in the thread are a great read for anyone trying to understand the issue or suggest/implement alternatives.