Editable Short Notes

[vitorpamplona]

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 Editable Short Notes #1090
• Updates kind1 to accept edits Content-editable kind1s without creating a new kind1.  #1089
• Creates a new content-modifiable short note kind Content-editable Kind1 #1088
• Creates a new fully modifiable short note kind Fully-editable Kind1 #1087

[staab]

NACK, alternative: #1091

[vitorpamplona]

@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.

[staab]

Editing kind 1s is not collaborating on a document. Kind 1s are tweets, edits are bad for tweets.

[vitorpamplona]

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.

[staab]

Can you explain why revealed preference on github/SO is to not edit in place, or why Twitter has chosen to never implement edit?

[vitorpamplona]

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).

[staab]

Revealed preference: https://en.wikipedia.org/wiki/Revealed_preference

[vitorpamplona]

I frankly don't know what you are trying to say/ask.

[staab]

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.

[vitorpamplona]

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.

[staab]

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".

[vitorpamplona]

"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.

[vitorpamplona]

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.

[fiatjaf]

I like @staab's alternative more.

But with regards to this one, why not sending just the deltas instead of the full content again?

[vitorpamplona]

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.

[fiatjaf]

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.

[vitorpamplona]

Looks like we are recreating DID:ION on Nostr :)

[ekzyis]

Both PRs (edits and annotations) can/should exist. They satisfy different needs/use cases.

Why do we need both? Wouldn't full edits already include annotations additions?

That's true, but unless they were done shortly after creation, most of these have never been read. Which illustrates my point

Not every edit is of such significance that this is relevant. I would argue that most edits are minor (hence the volume) and don't use EDIT: because they simply fix typos or rephrase something to make the text flow better for the next reader. Such edits are definitely preferred inline than as EDIT: instead of <typo> I meant <correction>. They might not even exist if it wasn't for inline edits. If someone already read the message and won't see it again, that's fine. They probably still understood the message but if you have access to inline edits, why not improve it for the next reader in a way that doesn't break the flow like EDIT: at the end?

But anyway, this argument ignores that this NIP doesn't limit users to only inline edits. They can still use append-only edits if that's indeed their preference.

So I don't understand why we would want to limit nostr to only append-only edits despite clearly most services offering full edits. I actually don't know a single service that uses append-only edits.

Regarding "revealed preference": Does that mean you believe users would prefer if when they click on edit on Github or SO, that they are only offered an empty textarea that only appends to the existing one? That's how the argument "revealed preference" sounds to me and I can't believe this is true. To me, clearly users want full edits as demonstrated by most if not all services. So I strongly agree with this from @vitorpamplona:

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.

Can you name one service which has edits for posts and comments but not as full edit?

Anyway, if you didn't notice yet, I am in favor of this instead of #1091.

[vitorpamplona]

Why do we need both? Wouldn't full edits already include annotations additions?

They do, but users think about them differently. When you want to edit, you don't want to annotate it. When you want to annotate it, you don't want to edit it. It's just a very different request by users. The whole mindset around it when you are using the app is different.

To me, annotations are almost like the community notes that Twitter has. It's a way to add more info about the post and not necessarily change it. Edits, even those active on Amethyst today, almost never offer new content. In fact, almost all of them are typo/grammar-fixing edits. Typo/grammar-fixing edits as annotations are just terrible UX, like you said.

[jb55]

I like @staab's alternative more.

what is your reasoning?

But with regards to this one, why not sending just the deltas instead of the full content again?

replacement of contents seems simple and straightforward to me. deltas seem unnecessarily complicated.

[fiatjaf]

what is your reasoning?

If it's clear that the "edit" is an annotation then it won't be de facto mandatory, while this one will. If it is mandatory that means implementation becomes harder and we should strive to make kind:1 be the simplest possible common ground, leaving complexity for other kinds or really optional addendums.

Having to fetch updated edits for every post while you're scrolling on a giant feed of notes is a big burden. Sure, there are some clients with local data storage for which such a thing won't be a super big deal -- or others that do not care and will already pull dozens of reactions and replies on every note, but we should keep the door open to other implementations and lighter clients.

[jb55]

what is your reasoning?

If it's clear that the "edit" is an annotation then it won't be de facto mandatory, while this one will. If it is mandatory that means implementation becomes harder and we should strive to make kind:1 be the simplest possible common ground, leaving complexity for other kinds or really optional addendums.

Having to fetch updated edits for every post while you're scrolling on a giant feed of notes is a big burden. Sure, there are some clients with local data storage for which such a thing won't be a super big deal -- or others that do not care and will already pull dozens of reactions and replies on every note, but we should keep the door open to other implementations and lighter clients.

edits should be less common than reactions and reposts, so the additional kind in the filter shouldn't really affect it that much? you can ignore it like damus currently does, so it already meets the criteria of keeping it simple. this only adds additional complexity if you app requires it, and can be otherwise be ignored.

I agree with your reasoning at some base level, but we have seen large numbers of users join and leave for not having this feature. It is also continually requested, so we are forced to consider it now.

my biggest concern is UX wise, making sure we make it clear which note someone is replying to, so that it can't be used maliciously if an edit is done like so:

eg:

Alice: I love my puppy!
-> Bob: I love him too!

edited:

Alice (edit): I love hitler
-> Bob: I love him too!

In the latter case it should probably be clear that the reply was to the original note, but if you rely on timestamp you can make it look like the person is replying to the edited post... I think its safer to always assume a reply is to the original... these are more of the issues im concerned about.

[fiatjaf]

Alice: I love hitler
Alice (edit): I love my puppy!
-> Bob (didn't see the original): I love him too!

I think its safer to always assume a reply is to the original

Alice: I love hitler
Bob: I love him too!

[jb55]

excellent point

[fiatjaf]

edits should be less common than reactions and reposts, so the additional kind in the filter shouldn't really affect it that much?

Currently it's perfectly fine to have a client that doesn't load reactions and reposts -- or one that only loads such things when you click on a note in the feed. With edits it will become mandatory to load these things while loading a feed always.

And there is nothing preventing people from making tons of edits, either for minuscule typos or because they want to keep a post "up to date" or for whatever other reason. I've seen a Brazilian who was maintaining multiple huge posts, like mini-dossiers about Brazilian politics stuff, updating them almost daily on Amethyst, and then reposting them, calling his followers to see the updated version.

[jb55]

could we include the edit as reply metadata so clients know which one was actually replied to? otherwise assume its to the original ?

[jb55]

yeah this is getting pretty messy, huge UX landmines

[fiatjaf]

One good compromise would be to do something like this whenever you want to edit:

• {kind: 1, id: 'aaaaa', content: 'I love my puppy!'}
• {kind: 5, tags: ['e', 'aaaaa']}
• {kind: 1, id: 'bbbbb', ['e', 'aaaaa', 'edit'], content: 'I love hitler'}

Actually I don't know if this is good.

[pablof7z]

One good compromise would be to do something like this whenever you want to edit:

• {kind: 1, id: 'aaaaa', content: 'I love my puppy!'}

• {kind: 5, tags: ['e', 'aaaaa']}

• {kind: 1, id: 'bbbbb', ['e', 'aaaaa', 'edit'], content: 'I love hitler'}

I think this is the best compromise; clients that don't/can't support edits won't need to change anything, the worst that would happen is that these clients might miss some of the replies to the original event since they don't understand there was a previous version.

We need to be very wary of introducing unavoidable complexity to the protocol, specially on something as fundamental as kind:1s.

[jb55]

And there is nothing preventing people from making tons of edits, either for minuscule typos or because they want to keep a post "up to date" or for whatever other reason. I've seen a Brazilian who was maintaining multiple huge posts, like mini-dossiers about Brazilian politics stuff, updating them almost daily on Amethyst, and then reposting them, calling his followers to see the updated version.

I wonder if it should be an addressable event where the d tag is the note you're editing? or maybe the other spec does this.

[vitorpamplona]

I just want to say that in 9 months, no Amethyst user complained about edits changing the interpretation of their replies.

And if it happens, the reply can also be edited.

[jb55]

if it can be abused, it will be. just want to make sure we have tools to deal with that.

[jb55]

I think if I were to adopt this spec the main thing I would want is inclusion of the fact you are replying to some specific edited version in the reply tags.

Then we can at least show on the UI which note content was actually replied to.

[vitorpamplona]

I wouldn't mind the edit marker if people want to add it.

[arthurfranca]

This spec creates a bad side-effect of requiring the client to download not only the original note but also potentially all of its edits when loading the feed, i.e. the used filter will be { kinds: [1, 1010], authors: [...], ... }.

Well, doing { kinds: [1010], #e: ["<the kind:1 id>"], limit: 1 } for every visible feed note could be better but the user would end up seeing the content blinking/being replaced. That is, it has worse UX impact than fetching and updating reaction/zap counters.

Clients MAY present a history of changes over time.

Instead of this, I think the NIP should recommend clients to delete old edits to make relay's life easier.

[ekzyis]

I think if I were to adopt this spec the main thing I would want is inclusion of the fact you are replying to some specific edited version in the reply tags.

I like this because it preserves context but would that mean you would lose all replies if you edit something? I guess it depends on if clients show replies of previous versions under the edited event with some hint that it's a reply to a previous version or as a new feed. A new feed is probably bad UX.

Instead of this, I think the NIP should recommend clients to delete old edits to make relay's life easier.

I believe this has been discussed before but I can't find the discussion or remember what the issues were with it.

One issue might have been that deletes don't preserve history of replies.

[arthurfranca]

Despite the drawbacks I will +1 this PR specially cause it is already working fairly well on Amethyst.