pull down to refresh

Interesting dialogue w/ fiatjaf in the discussion. Anybody understand the nostr protocol well enough to talk about the point of conflict?
reply
I only know the protocol a little bit so I'm probably totally wrong.
Anyway, my understanding is that normal notes (kind 1) are NOT editable by design. The proposal would introduce a second note that would be created (kind 31111 - notes in range 30000 are editable, like blog posts). In other words, there would be two notes in existence (an original, and an edited one).
I'm assuming Fiatjaf's objection is either (1) he doesn't want editable short notes at all, and/or (2) doesn't like that this proposal makes two notes (the original one and then an editable one).
I'm guessing an issue is that MOST clients would show the original note (the kind 1) but then other clients might show the updated note (the kind 31111). In my mind, this isn't ideal since the author would basically have two notes in the wild and they'd not know which note readers are seeing since there's no way to know what client the reader is using.
I don't know why Fiatjaf says that it would make it "centralized and censurable" - I'm not smart enough to know how that would be the case, but I'm assuming the "remove elegance" thing is related to my understanding listed above.
reply
There are editable notes in the protocol - these seem to be more so for blog posts. The issue is that not all relays support all the protocols. The relays and clients that support editable notes seem to be ones that are aimed at blog posts. But, I don't think "normal" apps like Damus/etc do anything other than short notes and all the protocols related to those.
Basically, if all relays and all clients supported all protocols (NIPS) then it'd probably not be a big deal to add things like editable short notes. However, most relays and clients only support non-editable short notes. So, to add editable short notes it'd be kind of a breaking "update."
The way NIPS work is that there's a proposal and then eventually it gets "approved." At that point relays and clients need to add the feature. Meaning, not all clients or relays will support all features. This is totally fine but if it means that there are two ways to view the basic note, then it might cause problems.
One thought here would be for a client to have a tool that basically makes your post not go live for 5-10 minutes or something. That way you could post a note, then read it, see your mistake and then fix it. Stacker News does this (though, I don't know if they live post it or just "hold it"). I think this might be a good idea, but it'd just be a client feature (basically don't really post the note until 5 minutes or so).
I mean, is a post a good one if it needs to be edited a few days later? All the replies or reposts would be wonky. For example, let's say I post something that seems tame - then lots of folks repost me. I then change that note to be offensive or something. Now, everyone that reposted me looks bad. Basically, edited notes are possibly not a good idea for a system that reposts/quotes.
reply
Ah, thanks for these thoughtful explanations.
I had always thought such things would do it the way that git does it -- a note would be a unique thing, and then any revisions to the note -- the edit -- would be new things, determined by content-addressability, that could have some relationship to the original thing (e.g., a parent relation, a 'previous-version' relation, etc.) That would disambiguate what people are replying to.
But of course, I'm sure there are a billion nuances to it.
reply