NIP-XX: Versatile event

[tiltpapa]

Define simple events, akin to text notes, along with replaceable events as defined in NIP-78.

Versatile event

draft optional

This NIP defines a simple event that do not require interoperability.

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 (versatile 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.

#994

[fiatjaf]

I think this can be added to NIP-78.

[tiltpapa]

I have attempted to refactor 78.md. feel a bit uncertain about the structure of it.
If everything looks good, I will delete XX.md.

[fiatjaf]

Looks good to me.

[fiatjaf]

Can you add 78 to the README?

[tiltpapa]

OK.

[tiltpapa]

added.

[v0l]

Kind 78 is regular event, probably don't need to specify that it has a d tag, it can have any tags.

[tiltpapa]

@v0l
Right. d tag don't need.

[pablof7z]

Concept NACK

You can already do this without defining it as a NIP (the NIP process is entirely optional) and defining a kind for non-interoperable things will be the easy way out for anyone that doesn't want to give a second thought about how to be interoperable.

I think this leads to laziness.

The only positive side to standardizing this is that I'll be able to block this kind from my relays, but I don't think that small benefit is enough.

[tiltpapa]

You can already do this without defining it as a NIP (the NIP process is entirely optional) and defining a kind for non-interoperable things will be the easy way out for anyone that doesn't want to give a second thought about how to be interoperable.

I think this leads to laziness.

Although it may be true that it can lead to laziness, I would like to emphasize that the purpose of this NIP goes beyond simply not considering interoperability. I want you to recognize that it can also be utilized for testing interoperable scenarios on production network.
I perceive "kind" as something akin to frequency. I believe it is not preferable for individuals to use their preferred "kind" before it is recommended in NIPs.

[tiltpapa]

I understand that NIPs is not the law. But too much freedom is also a problem.
I think it is necessary to give some guidance.

[AsaiToshiya]

Shouldn't there be some indexable identifier like the client tag to avoid conflicts between clients?

[tiltpapa]

Initially, I recommended using the d tag, but it has been removed. The client tag is essential for defining application-specific data.

I apologize for the comments, but I feel that what I was trying to propose can be achieved with #667 . I was not aware of this when I created this.

Should we close this Pull Request?

[AsaiToshiya]

I feel like they are the same, but I like this one better because it is added to NIP-78.

[tiltpapa]

I apologize for leaving this unattended for so long.
I’ve made the client tag mandatory. I’m now satisfied with the changes—how does it look to you? If there are no issues with the wording, I’d appreciate it if you could merge it.

[kehiy]

@tiltpapa we can support 3 versatile event kinds. ephemeral, regular, and addressable. then it would support more unique cases for all type of ideas.

[AsaiToshiya]

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

[tiltpapa]

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

[AsaiToshiya]

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

[tiltpapa]

@tiltpapa we can support 3 versatile event kinds. ephemeral, regular, and addressable. then it would support more unique cases for all type of ideas.

@kehiy That idea had crossed my mind as well, but I was thinking of waiting until kind78 gets adopted first.
Would it be better to define everything all at once at this point?
kind78(7078?), 20078

[kehiy]

@tiltpapa we can support 3 versatile event kinds. ephemeral, regular, and addressable. then it would support more unique cases for all type of ideas.

@kehiy That idea had crossed my mind as well, but I was thinking of waiting until kind78 gets adopted first. Would it be better to define everything all at once at this point? kind78(7078?), 20078

@tiltpapa i think if we add new nip, reserve new kinds and tag names for each possible thing using nostr, we will ran out off space for this and this repo would be a hell soon. i think we need to standardize the crucial stuff which is shared among all relays and client. specific client/relay usage like: chess pgn, kanban bords, and even git stuff in my opinion should use a range of general purpose kinds. when some clients see them, based on their specific usecase they can interpret it. or just define a code or tag for it to don't get confused. other wise in future we need to have kinds and nips for spread sheets, presentations, games, todo lists and more.

the issue with my idea is that nips are nostre implementation possibilities. so anyone adding these stuff i names are correct and im wrong. but i believe this thing would be bad for us. better to keep crucial and general purpose stuff here.