Mirror/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-12-13 19:06:24 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

nip37: optional kind:1 edits.

Browse Source
This commit is contained in:
fiatjaf 2024-10-30 17:56:26 -03:00
parent 8e2523e331
commit 9b6956ddad
1 changed files with 59 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

59
37.md Normal file
View File

@ -0,0 +1,59 @@
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](./09.md) 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
```jsonc
{
"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:
```jsonc
{
"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.