Dustin Dannenhauer on Nostr: Interesting alternative to kinds - I think the main benefit here is that the ...
Interesting alternative to kinds - I think the main benefit here is that the replacement to the “kind” is now English readable. So instead of having to look up what the kind number is, the new “event path” literally says what it is.
We could still have path term overload issues, although they might be less common.
Unfortunately it will still require coordination amongst devs to ensure we don’t have a billion top level folders… which would end up replacing kinds with single words.
We could still have path term overload issues, although they might be less common.
Unfortunately it will still require coordination amongst devs to ensure we don’t have a billion top level folders… which would end up replacing kinds with single words.
quoting note1q3j…g0xfNIP-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.
https://github.com/nostr-protocol/nips/pull/1266