Thread

I am considering enabling Amethyst to write a replaceable kind 1 (new kind:30111) to allow users to edit their past posts at will. It would work in a similar way Habla News works, but using Kind 1's style of small posts instead of markdown and long-form content of kind:30023. Of course, we could also write kind:30023 (blog posts) directly, but it would pollute most of the Blogging interfaces with short posts. What do you all think?

Replies (74)

I'm not up to date on the various note kinds, but I'm mostly: * NACK: nostr notes don't need editing, period. And it does screw up the context for, potentially, the entire reply / quote ref interactions. * or meh, even with editing, the original versions should always be available (when possible) in the UI. And / Or always have to assume that some relay somewhere still has the original version around, anyway. Or some clients refuse to show the updated version. So the worst case scenario can't be resolved (no such thing as truly erasing a mistake) while the more innocuous cases (just a little cleanup) aren't enough of a win to justify the effort / hassle / UI muddle of a somewhat clunky solution that maybe / probably won't get broad adoption anyway.
No, please don't destroy Nostr. This is a tool for scammers, and politicians will love this feature of you. If historical posts could be edited, Nostr would become a den for scammers. I like the feature of Nostr that posts cannot be deleted, because the posts made by each of us, regardless of joys, sorrows, typos, and emotional opinions, represent our true selves on Nostr. Blogs are academic essays, while short posts are about life and yourself.
↩ replying to Vitor Pamplona
No one will blame you if you fail to stop politicians and liars. But if you prepare tools for politicians and liars to deceive people more easily, you will be denounced by people. I know this is not your original purpose, it is just a technical discussion. Please don't do evil. This is not the purpose of our coming to Nostr. Short article posts on Nostr are historical records of our life thoughts. In real life, we will say the wrong things, make mistakes, and have emotional breakdowns, but these are real people, not a perfect academic paper. Or not a politician who is packaged as flawless and perfect.
Do you mean the "edits" would be diffs against the original post? Because if so, none of the history is lost and the client can let the reader see older versions through an interface extension (if the client supports it). A diff format (last update note1xxx + diff) could potentially be backwards compatible with clients that don't support applying the diffs and the timeline could show the old post as edited again as a fresh note (similar to a repost).
Can’t comment on the technical implementation you’re discussing with others, but from a user perspective an editable note (ideally time bound, 3min? 10min?) is clearly in demand and a nice feature. Like others I’d like to drill down into a history of previous versions. I don’t think the history should truly disappear.
While it might sound useful, I think, starting with myself, many nostriches got used to the immutability of Nostr notes. Edit history is something else as it keeps the record, but even that might not be needed for shorter posts. Unlike blog posts that are better modified in case of typos and content updates.
My initial reaction was sure, why not. Delete is important, and edit is just like deleting + posting + some UX sugar. But on the other hand much of Nostr’s power is its simplicity. Adding another kind puts a little more burden on new clients. Maybe good enough delete is good enough. Twitter didn’t have edit for a very long time.
↩ replying to npub16zsl...92l7
Hm, good point. But I think most of the clients that don’t support delete do so for philosophical reasons. So are they more likely to display the kind 300111 maliciously and not respect the edits or to not show it at all? I think in the long run if 300111 gets traction they will just show it without edits and we’ll be back to square one. It’s an assumption though.
↩ replying to Vitor Pamplona
Yes, they are very annoying to deal with, but that is made simpler by the fact that they are not expected to be displayed in realtime in a constantly updating feed that may or may not be cached locally and/or by relays. Kind 1 notes are easy to deal with in this "live" scenario: they either exist or they don't. All events always have the same id, so it's easy to match and cache and I'm probably forgetting a dozen other arguments that me and others have given in the past against having editable events.
↩ replying to fiatjaf
Event Twitter has a lot of trouble with editable posts, sometimes you are reading a post and it has a message saying "there is a new version", and then you click on that and it doesn't exist anymore or other shenanigans. I don't know how it's implemented internally, but I imagine it wouldn't be too different than this, except for the fact that they have a single codebase. In Nostr it would either be unusable chaos or everybody would just resort to using the same client.
↩ replying to Vitor Pamplona
I think that is bad too, accepting the fact that things don't change is probably the best way, but seems much simpler to implement and not very harmful to clients that don't implement it. Probably the most honest UI, if you want, would be to have a "nuke" button that tries to delete everything, but decouple that action from the act of creating a new note. Let people manually delete and then make a new one.
↩ replying to fiatjaf
+1 for decoupling. You can "delete", and then post a new one. Clients following the delete request can choose how to display it in the UI. In all other clients, it would be cool if it just looks like a quote tweet of the old note. == Benefit of quoting each of the edited versions - you can wee what engagement/comments were there with the specific previous versions of the note. == UX-wise, in terms of other users experience (who might have responded/boosted/quoted) your old note - I don't see any clean way how to allow edit without actually NOT hiding the previous versions.
Agree it is good to keep the kind segregated. Makes sense as it will definitely create some noise in the signal. But this will happen one way or the other. The question is what is best. Obviously we want to avoid as many legacy creations as possible. But no one knows the future exactly!
I'm not a developer and I'm not paying close attention to what's happening with the evolution of the nostr protocol, so maybe this already exists or maybe it's nonsense, but my understanding is that there's a danger here to bloating the protocol. My thought is that, without modifying the underlying nostr protocol, is it possible to build a parallel styling protocol that clients can implement in their own way, or choose not to implement? An analogy would be that this could serve sort of like a CSS layer to nostr's HTML? The solution in this case for editing could be some kind of "tag" that indicates the user intends the post to be "deprecated" and if the user goes back to the post and assigns the tag, the clients can honor it or not using their own implementation of the style for that tagβ€”for example, greying out the text or adding strikethrough? The idea being that the style layer can be separate from the data protocolβ€”and optional and customizedβ€”and that way not bog down the underlying framework? This also gives the clients some room to flex differentiation in their interpretation of the style tags? @Vitor Pamplona @fiatjaf View quoted note β†’
I'm late at the party. I agree with the position of @fiatjaf, @ hodlbod, @semisol, @CameriπŸ¦β€πŸ”₯ and many others: no new kind for kind-1 edits. However I like the patch idea, for small edits/addendum. It could be implemented as a simple kind-1 reply with a special tag. This way it would be always visible in the same thread; clients can choose to use it to overwrite the parent and let the user inspecting the history. In this case they should also manage (merge?) replies and reactions. But to make it usable on every client the patch format should be really simple and understandable in plain text, something like like a quote (>) paradigm. This would also permit to use the edit manually on clients that formerly doesn't support it. Examples of edit and append: ~the bat is on the table the cat is on the table +PS: the original source is xxxxx