This was always an unsolvable theoretical UX problem to me. Hard to know what to do from the client side. But I think I found the best possible solution here:

quoting naddr1qq…295e

kind:1 maximalism and the future of other stuff and Nostr decentralization

These two problems exist on Nostr today, and they look unrelated at first:

1. People adding more stuff to kind:1 notes, such as making them editable, or adding special corky syntax thas has to be parsed and rendered in complicated UIs;
2. The discovery of "other stuff" content (i.e. long-form articles, podcasts, calendar events, livestreams etc) is hard due to the fact that most people only use microblogging clients and they often don't appear there for them.

Point 2 above has 3 different solutions:

a. Just publish everything as kind:1 notes;

b. Publish different things as different kinds, but make microblogging clients fetch all the event kinds from people you follow, then render them natively or use NIP-31, or NIP-89 to point users to other clients that would render them better;

c. Publish different things as different kinds, and reference them in kind:1 notes that would act as announcements to these other events, also relying on NIP-31 and NIP-89 for displaying references and recommending other clients.

Solution a is obviously very bad, so I won't address it.

For a while I have believed solution b was the correct one, and many others seem to tacitly agree with it, given that some clients have been fetching more and more event kinds and going out of their way to render them in the same feed where only kind:1 notes were originally expected to be.

I don't think clients doing that is necessarily bad, but I do think this have some centralizing effects on the protocol, as it pushes clients to become bigger and bigger, raising the barrier to entry into the kind:1 realm. And also in the past I have talked about the fact that I disliked that some clients would display my long-form articles as if they were normal kind:1 notes and just dump them into the feeds of whoever was following me: nevent1q…e35c

These and other reasons have made me switch my preference to solution c, as it gives the most flexibility to the publisher: whoever wants to announce stuff so it can be discovered can, whoever doesn't don't have to. And it allows microblogging clients the freedom to render just render tweets and having a straightforward barrier between what they can render and what is just a link to an external app or webapp (of course they can always opt to render the referenced content in-app if they want).

It also makes the case for microapps more evident. If all microblogging clients become superapps that can render recipe events perfectly why would anyone want to use a dedicated recipes app? I guess there are still reasons, but blurring the line between content kinds in superapps would definitely remove some of the reasons and eventually kill all the microapps.

---

That brings us back to point 1 above (the overcomplication of kind:1 events): if solution c is what we're going to, that makes kind:1 events very special in Nostr, and not just another kind among others. Microblogging clients become the central plaza of Nostr, thus protecting their neutrality and decentralization much more important. Having a lot of clients with different userbases, doing things in slightly different ways, is essential for that decentralization.

It's ok if Nostr ends up having just 2 recipe-sharing clients, but it must have dozens of microblogging clients -- and maybe not even full-blown microblogging clients, but other apps that somehow deal with kind:1 events in multiple ways. It's ok if implementing a client for public audio-rooms is very hard and complicated, but at the same time it should be very simple to write a client that can render a kind:1 note referencing an audio-room and linking to that dedicated client.

I hope you got my point and agreed because this article is ended.