Awesome! Looks really good on mobile, too. One UX request: Add a reorder feature for the ingredients and directions so we can rearrange them without having to delete and re-enter.

Great job 👏

Thank you 🙏

What note kind are you using for the recipes? Still long form (30023)?

Yes, correct

Is the expectation that other long-form clients, such as Primal Reads, Habla, and Highlighter, should display recipes alongside articles and blogs, or should they be somehow filtering them out of their feeds based on certain tags?

We recently explored creating a custom nip for recipes, but this would have essentially erased everyone’s work over the past 2 years, and no real easy way to have it converted. We would essentially have to get every person who wrote a recipe to sign a new note to convert to a new nip. I get that the purist perspective does not like us using long form for this, but it works and clients can filter easily if they want. From what I can tell, primal is the only one who is filtering from the users content. Everyone else, habla, damus, Nostur, YakiHonne, etc display this with the tag for recipes. Perhaps they do limit in the content feeds somehow, but they are connected to the user who writes them.

Congrats and wish best of luck

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?

Yeah I get that. If there is a way, maybe? cc @Constant

A new event kind could open up the possibility of reviews, conversions, alterations, etc. It might take some time to get some social clients to support a new kind, but recipes are already hard to sift out from all the other long-form stuff. I just wanted to throw down my support for the idea, for the opposite reason :)

I know, and I appreciate the feedback 🫂 Really want to build a mobile app. Lots to consider here, basically would be a total rebuild from the ground up.

Its actually all there, a web implementation, a mobile app, and all the code is on github, but the initiative stumbled on the finish line (which il say is my fault). I think the NIPdocumentation and a presentation about it are the parts that never got published as such. I happen to be sick today, but il see if i can find all the links for you at some point. The relay and web-app are not hosted anywhere currently. Also the NIP/eventkind, was rather janky. The idea was to be creative with markdown in the content-field in such a way that (non recipe focussed) clients could opt for a barebones/simplefied implementation of the render/NIP; but i was never satisfied how it got implemented in the two demo apps(web and android), so i doubted it was a good idea (i.e. perhaps the idea was too fancy and would only make things worse for implementation) The event kind provided structured info about recipe relevant data, allowed for flexible rendering and subsequent additional processing on recipe data (allergies, portioning/amounts etc.)

Oh and i forgot, i think the code for transforming the old longform-recipes into the new events-structure is also there; iirc it was not perfect-perfect, but pretty good.

I can get to the repo, have the links. Let’s talk soon once you’re feeling a bit better. DM me.

Whoops, sorry, forgot about this. Talk to Biz! Its all his stuff anyway 😅. And dont forget to say hi from me, i hope he sold a goat by now🤔. Have fun at the event