nips
nips copied to clipboard
nostr-protocol
Editable Short Notes
This option does not use replaceable events. All edits are always available to Clients.
Read: here
Recap of the 4 options:
- Updates kind1 to accept edits with full history #1090
- Updates kind1 to accept edits #1089
- Creates a new content-modifiable short note kind #1088
- Creates a new fully modifiable short note kind #1087
@staab Annotations are not a replacement for edits. If you want to collaborate on a doc, you need full edits, not annotations.
Both PRs (edits and annotations) can/should exist. They satisfy different needs/use cases.
Editing kind 1s is not collaborating on a document. Kind 1s are tweets, edits are bad for tweets.
Editing kind 1s is not collaborating on a document.
Not today. But they will be.
Kind 1s are tweets, edits are bad for tweets.
Nah.. kind1s are just short blog posts. They can definitely change without destroying the universe. Especially if the full history of the changes is available for Clients to render the UI correctly.
Can you explain why revealed preference on github/SO is to not edit in place, or why Twitter has chosen to never implement edit?
Twitter allows edits (premium feature) Github allows edits. Facebook allows edits. Reddit allows edits. Even YouTube allows you to edit the video in place (paid feature).
Github and SO support edits, yes, but I almost universally see people annotating their posts with an "EDIT:" line rather than updating the comment directly. This is known as "revealed preference", where people show that they want something other than they say they want.
I almost universally see people annotating their posts with an "EDIT:"
"almost universally"? I think you are not counting the number of edits on GitHub that did not use "EDIT:". This repo alone is full of edits without any "EDIT" mention in the text.
Either way, GitHub offers both options. The user can choose to edit the post or just add the EDIT tag at the end. It's the user's choice, not the platform's or the protocol's.
I think you are not counting the number of edits on GitHub that did not use "EDIT:"
That's true, but unless they were done shortly after creation, most of these have never been read. Which illustrates my point. The best way to handle "oh crap" edits is to delay the sending of a note for 30 seconds (like various email clients do). Of course, this doesn't apply to chat/DMs where you want instant send, but I think it's ok for most social media use cases.
EDIT (heh): I suppose you could add something to the spec that says "if created_at is more than 5 minutes after the original publication time, they should be ignored".
"if created_at is more than 5 minutes after the original publication time, they should be ignored".
To me, that is a client decision. Because it will be impossible to block people from signing new modification events, but the receiving client can have cutoffs by time and then have a list of ignored updates if the user really wants to see them.
But frankly, unlimited edits are working well in all the platforms I mentioned. So, I don't subscribe to the idea that we should control edits, especially if the full history is available and anyone can see the author's shenanigans.
In the same way, there might be clients who will never implement edits just because they don't agree with the concept. That's their decision to make.
And part of the reason I started with a separate kind for editable posts.
I like @staab's alternative more.
But with regards to this one, why not sending just the deltas instead of the full content again?
why not sending just the deltas instead of the full content again?
It could work as well. I am just not knowledgeable enough about delta/diff libraries to choose a good one.
No, I don't think you should choose a library, you must come up with your own spec for the deltas that is as simple as possible and easy to implement by hand -- even if the idea comes from an existing library.