Is this for kind1 or in general? Is it easier for long form?
the nostr relay model is a double-edged sword, especially if your client needs to aggregate data from a bunch of pubkeys: dump pipes makes writing and running relays a breeze but dumps all the complexity to clients. now you don't need a backend but you do have to implement caching, storage and indexing on the client side with subpar primitives (at least on the web) just to get a half decent UX. i'm convinced that clients centered around relays are the sanest way to build apps: nostr:npub17n4cuc4d6y6qh89dekvxrenfkt5s0n49xns00uavjaxpr36c55dq87fyh9 and nostr:npub1gm7gw8q6akeft2pjt270we35vlff0v9g2fene6cxkz2h68q5hl6qls0fte embrace this idea.
Discussion
good question. it's the same problem for every app that tries to show content from the pubkeys you follow, regardless of the kind.
so get the author kind 3, and the tagged ones kind 10002 (if it's microblog), after that you have to do something smart in the selection, you can use only the author ones for a short introduction, and after that recover