From 2ecaed58e37df13291f5f2a2da3ad434e0850c03 Mon Sep 17 00:00:00 2001
From: Martti Malmi <sirius@iki.fi>
Date: Tue, 28 May 2024 13:20:20 +0300
Subject: [PATCH] NIP-116: Event paths

---
 116.md | 56 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 56 insertions(+)
 create mode 100644 116.md

diff --git a/116.md b/116.md
new file mode 100644
index 0000000..6737ddb
--- /dev/null
+++ b/116.md
@@ -0,0 +1,56 @@
+NIP-116
+=======
+
+Event paths
+-----------
+
+### Description
+
+Event kind `30079` denotes an event defined by its *event path* rather than its event kind.
+
+The *event directory path* is included in the event path, specified in the event's `d` tag. For example, an event path might be `user/profile/name`, where `user/profile` is the directory path.
+
+Relays should parse the event directory from the event path `d` tag and index the event by it. Relays should support "directory listing" of kind `30079` events using the `#f` filter, such as `{"#f": ["user/profile"]}`.
+
+For backward compatibility, the event directory should also be saved in the event's `f` tag (for "folder"), which is already indexed by some relay implementations, and can be queried using the `#f` filter.
+
+Event content should be a JSON-encoded value. An empty object `{}` signifies that the entry at the event path is itself a directory. For example, when saving `user/profile/name`: `Bob`, you should also save `user/profile`: `{}` so the subdirectory can be listed under `user`.
+
+In directory names, slashes should be escaped with a double slash.
+
+### Example
+
+#### Event    
+```json
+{
+    "tags": [
+        ["d", "user/profile/name"],
+        ["f", "user/profile"]
+    ],
+    "content": "\"Bob\"",
+    "kind": 30079,
+    ...
+}
+```
+
+#### Query
+```json
+{
+    "#f": ["user/profile"],
+    "authors": ["[pubkey]"]
+}
+```
+
+### Motivation
+
+To make Nostr an "everything app," we need a sustainable way to support new kinds of applications. Browsing Nostr data by human-readable nested directories and paths rather than obscure event kind numbers makes the data more manageable.
+
+Numeric event kinds are not sustainable for the infinite number of potential applications. With numeric event kinds, developers need to find an unused number for each new application and announce it somewhere, which is cumbersome and not scalable.
+
+Directories can also replace monolithic list events like follow lists or profile details. You can update a single directory entry such as `user/profile/name` or `groups/follows/[pubkey]` without causing an overwrite of the whole profile or follow list when your client is out-of-sync with the most recent list version, as often happens on Nostr.
+
+Using `d`-tagged replaceable events for reactions, such as `{tags: [["d", "reactions/[eventId]"]], content: "\"👍\"", kind: 30079, ...}` would make un-reacting trivial: just publish a new event with the same `d` tag and an empty content. Toggling a reaction on and off would not cause a flurry of new reaction & delete events that all need to be persisted.
+
+### Implementations
+- Relays that support tag-replaceable events and indexing by arbitrary tags (in this case `f`) already support this feature.
+- [IrisDB](https://github.com/irislib/irisdb) client side library: treelike data structure with subscribable nodes.