Oddbean

What do you guys think of inheritance on nostr event kinds? Composition is not the answer to everything. I recently splitted kind 32267 for apps, removing all the fields that correspond to a wiki entry and added an `a` pointer to it. But if my kind 32267 *is a* compatible wiki entry, as it implements all fields from wikis kind 30818, it should be read by wiki clients.

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?

Yeah I was thinking the former: kind B claims to inherit from kind A. It is real inheritance but requires manual work (asking clients to include new kinds) How about a `k` tag that declares inheritance? In my kind 32267 I could add ["k", 30818] so then wiki clients can query for { kinds: [30818] } and { "#k": [30818] }