mention the possibility of easily eliminating the uglyness.

7A.md

@@ -17,6 +17,7 @@ Every other client can just display the patch as a normal `kind:1111` comment wh
   "kind": 1111,
   "content": "PATCH\n<patch-content>",
   "tags": [
+    ["patch"],
     ["e", "<event-id-being-patched>", "<relay-url>", "<pubkey>"],
     ["k", "<kind-of-event-being-patched>"],
   ]
@@ -76,6 +77,10 @@ In case a patch can't be applied, the reader client can just leave it as it is,
 
 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.
 
+## "This patch format is ugly and not human-readable"
+
+The current patch format is a middleground between human-readable and simple and computer-readable, so it isn't perfect. If this is a concern, though, reader clients that don't want to apply the patch directly (which is a reasonable choice) can easily parse the `<patch-content>` and display it in a more human-readable way (for example, with colors, removing the numbers, or by displaying it with context from the original post). Clients already parse every note's content for references, URLs, hashtags, so this would just be a thin extra parsing layer that wouldn't require a lot of changes.
+
 ## 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).