It's probably not a big deal when it is pretty easy for other clients to filter out long-form notes that are recipes rather than blogs or articles. That said, I wouldn't characterize the view that notes with different types of content should use different kind numbers as a "purist perspective." Rather, it is simply the considerate path to take when designing a client that has a different use-case from existing clients. Otherwise, the client using an existing kind in a non-standard way is creating extra work for the devs of existing clients to keep them working the way they intended, with the type of content they wanted to have included. A good example of this is how I am not able to use a feature I would love to use on npub.pro simply because zap.cooking is using long-form. I would love to have my npub.pro site (https://dikaios1517.npub.pro/), simply display any article I have published, without any need to manually add it after publishing. However, because I have published a recipe at zap.cooking in the past, I cannot enable this feature without npub.pro also displaying that recipe on my site. You mentioned that there's not really a way to go back now, since there are 2 years worth of content on zap.cooking that already use kind 30023, and it would be terrible for all that work to be erased. I agree. Maybe there is an alternative way forward though. You could create a new note kind specifically for recipes and every new recipe created on zap.cooking would use that kind number going forward. However, the site would still display any kind 30023 notes that were created as recipes in addition to the recipes created using the new note kind. Is that a possibility?