nips
nips copied to clipboard
nostr-protocol
Add kind 30079 in NIP-78 (#1503)
By convention (and implementation) kind 3xxxx are always parameterized replaceable events, you should choose something in the range 100-9999 for non-replaceables.
I think 7078 is going to need at least 1 tag to distinguish different apps from each other. The replaceable event has the 'd' tag.
Personally I may use this for my gossip relay test injected events as 7078 but I'll want to isolate them from other uses with some tag of some sort.
@mikedilger Thank you for your input! Here’s my perspective on the use of the d tag for kind 7078:
Consistency with Existing Standards: The operation of the d tag in kind 7078 follows the same principles as kind 30078. Furthermore, kind 30078 itself adheres to the conventions established by kind 30023. This ensures consistency and compatibility across these kinds.
Separation of Users and Databases: The separation of data for different users or databases can be effectively managed using a combination of the d tag and the author field. These provide sufficient granularity to isolate data as needed.
No Naming Rules Required: There are no strict naming rules for the d tag; it is a simple string that can be used to distinguish between entities. Applications or users can implement their own logic based on string matching without requiring predefined naming conventions.
By maintaining this approach, we can ensure flexibility and simplicity while still providing robust methods for data segmentation and application-specific customization.
Let me know if you have any further thoughts or suggestions!
@mikedilger Thank you for your input! Here’s my perspective on the use of the d tag for kind 7078:
I wasn't suggesting adding a 'd' tag to kind 7078. It wouldn't work because relays wouldn't honor it because 7078 is not replaceable. Any 7078 event with the same author would replace all other 7078 events irrespective of their d-tags. And the whole point of this PR is to have a non-replaceable kind, right? So that you can have multiple versions?
What I was suggesting (or hinting at) is that what might be ideal is to have an addressable but not-replaceable event. That way we could separate different contexts by the address. But we don't have that in nostr.... yet.
In fact this can be solved without this PR if replaceable events were re-interpreted (see #1670).