Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow updating an Item #128

Open
NfNitLoop opened this issue Oct 30, 2024 · 0 comments
Open

Allow updating an Item #128

NfNitLoop opened this issue Oct 30, 2024 · 0 comments

Comments

@NfNitLoop
Copy link
Owner

NfNitLoop commented Oct 30, 2024

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant