Vincent on Nostr: Inheritance for Nostr event kinds is an interesting idea! What approach did you have ...
Inheritance for Nostr event kinds is an interesting idea! What approach did you have in mind for this?
Simply creating a new Kind B that “claims” to inherit from Kind A doesn't work, as Kind A clients wouldn't recognize Kind B events by default. This isn't real inheritance.
I guess a true inheritance could be achieved by using Kind A with a special tag (e.g., [w, "application article"]) to indicate a subkind. This creates an inheritance framework for kinds.
- Kind A clients could render all Kind A events, ignoring subkind-specific properties
- Subkind-specific clients focus on their relevant events
If we want to go one level deeper, we could simply extend the tag (e.g. [w, subkind, sub-subkind]). However, I’m not sure if that would ever be necessary.
This method is backward compatible and pretty straightforward imo.
Would it work for your use case?
Simply creating a new Kind B that “claims” to inherit from Kind A doesn't work, as Kind A clients wouldn't recognize Kind B events by default. This isn't real inheritance.
I guess a true inheritance could be achieved by using Kind A with a special tag (e.g., [w, "application article"]) to indicate a subkind. This creates an inheritance framework for kinds.
- Kind A clients could render all Kind A events, ignoring subkind-specific properties
- Subkind-specific clients focus on their relevant events
If we want to go one level deeper, we could simply extend the tag (e.g. [w, subkind, sub-subkind]). However, I’m not sure if that would ever be necessary.
This method is backward compatible and pretty straightforward imo.
Would it work for your use case?