Nostr Web Client

Warning: Long rant (but meant to be informative).

Yes, Amethyst can do it. And fiatjaf is actively campaigning against the way it is implemented because, from his perspective, it’s implemented in a generic and complex way that makes it difficult for other clients to support. This may result in potentially vastly different experiences across clients even for fundamental types such as short notes. The main argument here is that "all powerful" editing capabilities may fractures the Nostr ecosystem. There are plenty of alternative proposals for editing notes, but as far as I know, not much concrete has been done to implement them and gather user feedback.

On the other side, there’s nostr:nprofile1qqsyvrp9u6p0mfur9dfdru3d853tx9mdjuhkphxuxgfwmryja7zsvhqpzamhxue69uhhv6t5daezumn0wd68yvfwvdhk6tcpz9mhxue69uhkummnw3ezuamfdejj7qgwwaehxw309ahx7uewd3hkctcscpyug (Amethyst’s developer), whose argument is basically: It’s useful, and users use it. If they want it, they get it.

Disclaimer: I use this feature myself, just like I edit posts on Mastodon, LinkedIn, Reddit, and a gazillion other places. From a selfish perspective, I’m happy with it. And I also don’t think that not seeing edits on other clients is a big deal for my own use cases. Yeah, zapping a post that originally said “I love kittens” only to see it later changed to “I loathe kittens” somewhere else isn’t great. But I can live with that if it means I can fix my own typos.

Then there’s everyone else: "Nostr influencers" doing whatever they do, folks who want Nostr to be like an "immutable" blockchain, people who oppose edits due to possible abuse (or a myriad of other reasons), and those who love editing and don’t want it taken away. Overall, there are devs supporting both sides, some taking strong stances, others just shrugging it off.

Every few weeks, someone brings this up again. Honestly? Neither side is likely to change their mind. So we’re stuck in an endless debate that will either remain unresolved or be settled by adoption metrics.

My take? Things will likely stay as they are, at least for a while. If they do change, either Amethyst’s editing features will become the de facto standard and other popular clients will slowly adopt it to survive, or a better standard will emerge and Amethyst will have to conform.

Hopefully, this was informative. See you all in a couple of weeks when this topic resurfaces again. :)

hoppe 10mo ago

It seems like there are two irreconcilable positions on this:

One side argues that the edit feature is technically complex, making it difficult for multiple clients to implement. This could lead to centralization, as the feature would be concentrated in a single client, or it could create issues where the same note appears differently in different clients. Therefore, they believe that edit functionality should never have been implemented from the start.

On the other hand, the opposing side argues that this is really a basic, fundamental feature that should be there.

What if, instead of including the content in the note ID, we only include everything except the content itself when generating the ID and then sign it? The content could be stored separately and merely referenced. This way, we could freely modify the content without complex implementations for how replies would refer to it.

And for other users, the note would simply be displayed with the understanding that "this person is saying something that could easily be changed later." What do you think about this approach?

Reply to this note

Please Login to reply.

Discussion

Anthony Accioly 10mo ago

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.

hoppe 10mo ago

Right. Changing the existing kind 1 like that would have too much of an impact. What I was talking about was creating a new kind (like 1999) that functions like a kind-1 note.

After writing a post, users would choose whether to publish it as a non-editable note or a new type of editable note. People would see both kind 1 and 1999 in their feeds the same way, but they might perceive the former as a more responsible statement.

And kind 1 would be made completely uneditable (maybe even undeletable).

Thanks for linking the thread—I’ll read through it when I get home.

fiatjaf 8mo ago

Not a bad idea, I've proposed something similar here: https://github.com/nostr-protocol/nips/pull/1565.

Anthony Accioly 8mo ago

GM fiatjaf. This is what I referred to as "fiatjaf method 2" above. The main shortcoming is the lack of edit history, which can be addressed with a bit of added complexity.

For example, type 31000 could tag a linear history of immutable "edit version" events. Clients would always publish both a new 31000 event and an immutable edit version event. When publishing an edit, clients should mutate the bodu contents of the 31000 event to reflect the contents of the latest version and add a new tag pointing to the latest edit version.

This approach is generic enough to accommodate everyone and is reasonably easy to implement (simpler to read, at the cost of slightly more complex writes).

1. Want the latest version? Fetch kind 31000 and simply display the body.

2. Want purely immutability? Use kind 1.

3. Want the full history, Amethyst style? Check the tags of the kind 31000 event.

The write trade-off here is that clients supporting kind 31000 would need to publish two events: one for the regular immutable edit version, and one updated kind 31000 event. They also need to be aware of potential race conditions. That is, they should replace version kind 31000 n with version n+1, if n+1 correctly tags n. This can also be enforced at the relay level. However, clients would need to retry in a CAS-style manner to avoid "corrupting" the index.

What do you think? Also tagging nostr:nprofile1qqsyvrp9u6p0mfur9dfdru3d853tx9mdjuhkphxuxgfwmryja7zsvhqpzamhxue69uhhv6t5daezumn0wd68yvfwvdhk6tcpz9mhxue69uhkummnw3ezuamfdejj7qgwwaehxw309ahx7uewd3hkctcscpyug

hoppe 8mo ago

People really do think alike. If edits were implemented this way, we could call it a kind of SegWit for nostr. The difference is that, unlike SegWit which excluded the signature to preserve the ID, here it's the content that's excluded.