Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 15 additions & 3 deletions 78.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,16 +6,28 @@ Arbitrary custom app data

`draft` `optional`

The goal of this NIP is to enable [remoteStorage](https://remotestorage.io/)-like capabilities for custom applications that do not care about interoperability.
This NIP defines some events that do not require interoperability.

### Event `30078`: remoteStorage-like Event

The goal of this kind is to enable [remoteStorage](https://remotestorage.io/)-like capabilities for custom applications that do not care about interoperability.

Even though interoperability is great, some apps do not want or do not need interoperability, and it wouldn't make sense for them. Yet Nostr can still serve as a generalized data storage for these apps in a "bring your own database" way, for example: a user would open an app and somehow input their preferred relay for storage, which would then enable these apps to store application-specific data there.

## Nostr event
**Nostr event**:

This NIP specifies the use of event kind `30078` (parameterized replaceable event) with a `d` tag containing some reference to the app name and context -- or any other arbitrary string. `content` and other `tags` can be anything or in any format.

## Some use cases
**Some use cases**:

- User personal settings on Nostr clients (and other apps unrelated to Nostr)
- A way for client developers to propagate dynamic parameters to users without these having to update
- Personal private data generated by apps that have nothing to do with Nostr, but allow users to use Nostr relays as their personal database

### Event `78`: Versatile Event

When creating Nostr-based applications, suggesting a new kinds each time can be burdensome for developers. For purposes like testing or for applications that do not require interoperability, it is acceptable to use the defined event here.

**Nostr event**:

This NIP specifies the use of event kind `78` (regular event) with a [`client` tag](https://github.com/nostr-protocol/nips/blob/master/89.md#client-tag). `content` and other `tags` can be anything or in any format.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, client tag is not indexable. I think that should use single letter tag to filter events.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should I define a new single-letter tag?
I don’t have any ideas about which letter to use.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Considering that clients use various tags, I think the d tag is a safe choice.

1 change: 1 addition & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -94,6 +94,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
| `42` | Channel Message | [28](28.md) |
| `43` | Channel Hide Message | [28](28.md) |
| `44` | Channel Mute User | [28](28.md) |
| `78` | Versatile Event | [78](78.md) |
| `1021` | Bid | [15](15.md) |
| `1022` | Bid confirmation | [15](15.md) |
| `1040` | OpenTimestamps | [03](03.md) |
Expand Down