You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the readme states that edits are an "unplanned feature".
I originally didn't want to allow edits because I don't like the fact that you can "take back" something that you said. I believe that responsible social networking needs to hold users accountable for what they share.
However, as blog posts get longer, the likelihood you'll find a typo or error after you click the "Post" button increases dramatically. 😣 It's frustrating when the only recourse is to post a comment saying "Oops, on this part here I actually mean to say this."
I think we can introduce some mutability in the UI without making the data store mutable.
I'm not fond of the way Nostr implements this:
you have to create a post of a separate type that has a "d" tag that makes it "replaceable".
You can create a new post with the same "d" tag to replace the previous one.
The server may delete old versions matching that "d" tag. (But it might not!)
Every client needs to deal with the possibility of receiving multiple items with the same "d" tag and dedupe them.
In particular:
I don't want the original to be deleted by servers. It should remain, because other items may refer to it. Other web sites may link to that item by ID. It also holds the user accountable for what they posted.
We shouldn't have to pre-tag items as replaceable with some other ID.
My brainstorm fix/implementation:
Create a new type of Item that acts like a "ReplyTo", but provides an update to the original Item.
Update ItemListEntry to include a "LatestUpdate" field, which the server can populate to let clients know that there is an update to that item.
Clients can choose whether/how to fetch the original and updated versions, and replies to both.
When users compose replies to a post, clients should add a ReplyTo the version that the user read. (ex: if the user read the original, the ReplyTo will cite the original. If the user read the updated version, then it uses that ID.) This way there is no doubt which version users saw when they replied/quoted the content.
The text was updated successfully, but these errors were encountered:
Currently, the readme states that edits are an "unplanned feature".
I originally didn't want to allow edits because I don't like the fact that you can "take back" something that you said. I believe that responsible social networking needs to hold users accountable for what they share.
However, as blog posts get longer, the likelihood you'll find a typo or error after you click the "Post" button increases dramatically. 😣 It's frustrating when the only recourse is to post a comment saying "Oops, on this part here I actually mean to say this."
I think we can introduce some mutability in the UI without making the data store mutable.
I'm not fond of the way Nostr implements this:
In particular:
My brainstorm fix/implementation:
Item
that acts like a "ReplyTo", but provides an update to the originalItem
.ItemListEntry
to include a "LatestUpdate" field, which the server can populate to let clients know that there is an update to that item.ReplyTo
the version that the user read. (ex: if the user read the original, the ReplyTo will cite the original. If the user read the updated version, then it uses that ID.) This way there is no doubt which version users saw when they replied/quoted the content.The text was updated successfully, but these errors were encountered: