NIP-37

Editable Short Notes

draft optional

This NIP describes a flow for editing kind:1 notes that is mostly backwards-compatible (as long as clients support NIP-09 properly).

The flow for editing a kind:1 note consists of creating a new kind:1 note to be published in its place, then issuing a kind:5 delete request for the first, in both cases attaching special tags that denote the nature of the operation to clients that want to support a more rich edit flow.

Example flow

Support <bob> publishes

{
  "id": "aaaaa",
  "kind": 1,
  "pubkey": "<bob>",
  "content": "ehllo"
}

And now, for whatever, reason, he wants to edit the note to say "hello", so his client will publish the following two events:

{
  "id": "bbbbbb",
  "kind": 1,
  "pubkey": "<bob>",
  "content": "hello",
  "tags": [
    ["s", "aaaaaa"] // this indicates the note that is being replaced
  ]
}

{
  "kind": 5,
  "pubkey": "<bob>",
  "tags": [
    ["e", "aaaaaa"], // this indicates the note that will be deleted in all non-upgraded clients
    ["edit", "bbbbbb"], // this indicates the notes that replaced the one just deleted
  ]
}

Backwards-compatibility

For all non-upgraded clients, this operation will look like a normal delete-and-replace. Replies, likes and everything else sent to node aaaaaa will be lost, but the feed will be intact and fine, with no need for any custom handling or complex replaceability.

Progressive enhancement

Progressive enhancement may be applied, for example: when a user clicks to open note bbbbbb the client might try to query for {"ids": ["aaaaaa"]} upon seeing the s tag. And vice-versa, upon opening any other note a client might query for {"#s": ["..."]} to check if any edit is available. Both operations can enhance the focused note screen, but they don't have to be performed while loading a feed, and they remain strictly optional regardless.

Full-blown upgrade

More complex clients that want to treat edits as pure edits and note as standalone notes may choose to hide any kind:1 note that contains an s tag as a standalone entity, instead choosing to attach it to its "parent" that was edited. That must be combined with a refusal to actually delete notes whenever the kind:5 deletion request includes an edit tag. Such deletion request would then be only used as hints that an edit was performed, so it can be fetched and the note contents replaced in-place.

2.4 KiB Raw Permalink Blame History