Add annotations

[staab]

Annotations are preferable to edits, because they leave the original content of a note unchanged. This reduces the amount of possible confusion when comments don't match the version of the note that is fetched. You can see a revealed preference for this behavior on github issues and stack overflow posts; it is far preferable when editing comments to add a new line beginning with EDIT or UPDATE than to transparently update the main body of content.

[fiatjaf]

I like it.

This also fixes broken URLs and all sorts of things?

[fiatjaf]

Could clients reliably implement this by just visually appending the content of annotations to the bottom of the original post?

[vitorpamplona]

Maybe rename it to "Additions", then?

[staab]

Could clients reliably implement this by just visually appending the content of annotations to the bottom of the original post?

That's how I would do it, maybe after a rule

---

EDIT: like this

[mikedilger]

Of the last 5 PRs, I like this one the best.

[vitorpamplona]

So, I was testing this out and I realized that if people start using the EDIT annotation for real, most posts in the feed will have an EDIT below them. Some will have two or three.

The edit notation only works for folks coming back to something they have already read. That's what @staab mentioned. However, because of the nature of kind1s, most posts will be new ones. And if it is a new post, you don't want to read the post and read 2-3 edits. You will be like: "Just fix the main post. Delete it and write it again. Whatever. But don't pollute my feed"

[dtonon]

So, I was testing this out and I realized that if people start using the EDIT annotation for real, most posts in the feed will have an EDIT below them. Some will have two or three.

If you are evaluating this using as data source the current Amethyst edit function, it could be a false positive, related to the fact the users are induced to use the edit, even several times, because it seems transparent to the original notes. So they probably put less attention when they compose the original notes.

Il like this annotation proposal, it requires more awareness in content creation.
But why use a new kind? If we use the kind-1 with an additional field to the e tag, all clients that does not support annotations will show them as a reply, and this definitely makes sense, otherwise the addition would be lost, and his informative value could be crucial to the meaning of the original note. E.g.

{
  "kind": 1,
  "pubkey": "<pubkey>",
  "tags": [
    ["e", "<event_id>", "<relay_hint>", "annotation"]
  ],
  "content": "EDIT: I forgot to say...",
  // ...other fields
}

You could also use a new tag to report the annotation, if you do not want to extend the basic e structure.

[mikedilger]

I think I agree with @dtonon. Normally a new feature should not break existing clients, and we ensure that by using something distinct that existing clients won't recognize. But an annotation would be even more broken if it wasn't shown at all by old clients. They need to work in existing clients that don't support annotations by being (in that case) a reply. So using an "annotation" marker makes the most sense to me at this point. The clients supporting annotations can check if the pubkeys match and render these special replies inside the original note, and those that don't will show them as replies so the content is not lost.

EDIT: Actually they probably have to be marked "reply" to work in old clients... and then have some additional signalling mechanism indicating that they are an annotation style reply.

[staab]

Agreed, just updated the NIP text.

[mikedilger]

Approved

[mikedilger]

Implemented in gossip on a private branch, will move through unstable to master once the impl is cleaned up.

[mikedilger]

I've discovered a kink. What if someone replies to the annotation event? I guess I can show it as a reply to the main event.

[staab]

What if someone replies to the annotation event? I guess I can show it as a reply to the main event.

This is probably ok. If annotations aren't supported, it'll work as usual, if they are, then clients should have a strategy for handling this. I'll add it to the NIP.