1 files changed, 10 insertions, 5 deletions

diff --git a/09.md b/09.md
index fbbd6e1..9eee055 100644
--- a/09.md
+++ b/09.md
@@ -14,14 +14,13 @@ The event's `content` field MAY contain a text note describing the reason for th
 
 For example:
 
-```
+```jsonc
 {
   "kind": 5,
   "pubkey": <32-bytes hex-encoded public key of the event creator>,
   "tags": [
     ["e", "dcd59..464a2"],
     ["e", "968c5..ad7a4"],
-    ["a", "<kind>:<pubkey>:<d-identifier>"]
   ],
   "content": "these posts were published by accident",
   ...other fields
@@ -34,9 +33,9 @@ Relays SHOULD continue to publish/share the deletion events indefinitely, as cli
 
 ## Client Usage
 
-Clients MAY choose to fully hide any events that are referenced by valid deletion events.  This includes text notes, direct messages, or other yet-to-be defined event kinds.  Alternatively, they MAY show the event along with an icon or other indication that the author has "disowned" the event.  The `content` field MAY also be used to replace the deleted events' own content, although a user interface should clearly indicate that this is a deletion reason, not the original content.
+Clients MAY choose to fully hide any events that are referenced by valid deletion events. This includes text notes, direct messages, or other yet-to-be defined event kinds. Alternatively, they MAY show the event along with an icon or other indication that the author has "disowned" the event. The `content` field MAY also be used to replace the deleted events' own content, although a user interface should clearly indicate that this is a deletion reason, not the original content.
 
-A client MUST validate that each event `pubkey` referenced in the `e` tag of the deletion request is identical to the deletion request `pubkey`, before hiding or deleting any event.  Relays can not, in general, perform this validation and should not be treated as authoritative.
+A client MUST validate that each event `pubkey` referenced in the `e` tag of the deletion request is identical to the deletion request `pubkey`, before hiding or deleting any event. Relays can not, in general, perform this validation and should not be treated as authoritative.
 
 Clients display the deletion event itself in any way they choose, e.g., not at all, or with a prominent notice.
 
@@ -46,4 +45,10 @@ Relays MAY validate that a deletion event only references events that have the s
 
 ## Deleting a Deletion
 
-Publishing a deletion event against a deletion has no effect.  Clients and relays are not obliged to support "undelete" functionality.
+Publishing a deletion event against a deletion has no effect. Clients and relays are not obliged to support "undelete" functionality.
+
+## Deleting Replaceable Events
+
+Because of their changing nature it's hard to get rid of all instance of a replaceable event (ranges `10000...19999` and `30000...39999`). We also don't want to publish a `kind:5` targeting an `a` reference and thus permanently delete any future events that could possibly have the same specifieds `kind` and `d`-tag forever.
+
+So instead to delete a replaceable event we **overwrite** it with an event with the same `kind` and `d`-tag, plus a tag `["deleted"]` specifying no other tags.