laantungir/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2026-10-05 18:58:44 +00:00
Code Issues Packages Projects Releases Wiki Activity

reorganize and add recommendation for replies to patches.

Browse Source
This commit is contained in:
fiatjaf
2026-08-18 09:40:01 -03:00
parent 97ef9fcd5c
commit 4422dbbaa6
1 changed files with 17 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files
9A.md
+17 -11
View File
@@ -41,15 +41,7 @@ t <tag-name> <new-value>
The indexes and amounts refer to unicode characters, not bytes.
## Broken patches
In case a patch can't be applied, the reader client can just leave it as it is, displayed as a normal comment.
## Multiple patches
If more than one patch has to be made, they should all target the same original event (i.e. the second patch shouldn't tag the first patch), and the reader client should apply one after the other, in temporal sequence.
## Recommendations
## Mandatory Recommendations
This method should not be used to completely replace a thing (better delete and make a new one) or to continuously update it over time (better use replaceable events).
@@ -76,6 +68,20 @@ The event kinds that are expected to be patchable this way are:
- `24` (public messages),
- `1621` (issues).
## Unspecified possibilities
## Broken patches
- I don't know if this is a good idea, but it may be a cool dynamic to allow people to publish patches to events authored by someone else, but in this case these should never be applied automatically, only upon user action that clearly implies this patch isn't by the original author (e.g. by clicking on the patch event that would otherwise just stay there as a normal weird-looking comment).
In case a patch can't be applied, the reader client can just leave it as it is, displayed as a normal comment.
## Multiple patches
If more than one patch has to be made, they should all target the same original event (i.e. the second patch shouldn't tag the first patch), and the reader client should apply one after the other, in temporal sequence.
## Handling replies to patches
If a reader client sees a reply to a patch that was merged on the upstream event, it could display such reply as if it was replying to the original event, possibly with some visual clue that it was targeting the patch (even better if the patch itself could be still accessed somehow, even after applied and hidden).
## Third-party patches
It is probably better to not support these and just ignore them by default, but if a client so desires it, may be a cool dynamic to allow people to publish patches to events authored by someone else.
In this case these should never be applied automatically, only upon user action that clearly implies this patch isn't by the original author (e.g. by clicking on the patch event that would otherwise just stay there as a normal weird-looking comment).