Feature Request: Define New Kinds for Cumulative Database Functionality in Nostr

[ShinoharaTa]

I view Nostr as an open database. However, using kind 30078 requires constantly monitoring the original values, which makes it unsuitable for use as a cumulative database.

To utilize Nostr as a cumulative database for topics and records, I would like to propose defining new kinds. Additionally, I aim to define the data structure using NIP numbers.

Proposed Data Structure

{
  ...
  "content": "{\"title\": \"The workout log.\", \"about\": \"my training logs.\"}",
  "tags": [
    ["d", database_identify_name],
  ],
  ...
}

The basic structure involves using kind n to define title, about, and other fields in the database. In the tags, the "d" tag will be used to include identifiers such as table names.

Using kind n+1, the identifier is updated. The "e" tag will be used to associate with events of kind n, enabling the retrieval of lists. The data will be stored as JSON strings in the content field, allowing flexibility in data representation.

{
  ...
  "content": "data object to string",
  "tags": [
    ["e", <database_create_event_id>, <relay-url>],
  ],
  ...
}

Rationale

While this approach is very similar to kind 40, 41, 42 used in Public Chat, it should be classified separately to serve distinct roles from Public Chat functionalities.

Currently, I considered combining kind 1 with hashtags, but this approach would lead to timeline pollution, making it unsuitable for my intended use.

Benefits

Implementing this mechanism would allow, for example:

Daily Workout Logs: Users can maintain daily workout records and compare them with friends.
Relay Monitoring: It becomes easy to monitor the operational status of relays and keep logs akin to system logs.
Conclusion

Defining new kinds for cumulative database usage in Nostr will enhance its functionality and provide more structured and efficient ways to manage and retrieve data without the need for constant monitoring of original values.

[staab]

Normally, it's best practice to create a new kind for each new data type. What you're doing (and what nip 78 is doing) is creating a namespace-within-a-namespace. Better to just use kinds, unless you have no aspirations for interoperability. If that's the case, I wouldn't object to an PR to NIP 78 that adds support for non-replaceable events. Just be aware that using public relays for this kind of thing may be considered spam.