buttercat1791 on Nostr: We're specifically building the UX to allow remixing or event interpolation. So, for ...
We're specifically building the UX to allow remixing or event interpolation. So, for instance, rather than copy-pasting text from another publication into a quote block, you'd like in the relevant 30040 or 30041 events that you want to quote. Thus, quotes bring their context with them.
Kind 30040 indices could also be used as a new type of collection. Suppose you're publishing a magazine. It contains a number of articles from different authors. The root event of the magazine would have a bunch of `a`-tag references to each of its articles. If your magazine issue has 10 different articles, that's likely 10 distinct npubs just in the `a` tags.
We _could_ try to dream up a new kind of tag to reduce repetition for event trees where all the events are by the same author, but that breaks with the already-widespread use of `a` tags for references (which are typically indexed on relays, per protocol spec).
I suppose if we removed npubs from the references to indexed events, we could discover those npubs from the `pubkey` field of the indexed events themselves, but that places more of a burden on more resource-constrained devices, namely the clients, to do that discovery when needed.
In short, I don't yet see strongly compelling reasons to break with the established specification of using `a` tags in common with other Nostr event kinds.
Kind 30040 indices could also be used as a new type of collection. Suppose you're publishing a magazine. It contains a number of articles from different authors. The root event of the magazine would have a bunch of `a`-tag references to each of its articles. If your magazine issue has 10 different articles, that's likely 10 distinct npubs just in the `a` tags.
We _could_ try to dream up a new kind of tag to reduce repetition for event trees where all the events are by the same author, but that breaks with the already-widespread use of `a` tags for references (which are typically indexed on relays, per protocol spec).
I suppose if we removed npubs from the references to indexed events, we could discover those npubs from the `pubkey` field of the indexed events themselves, but that places more of a burden on more resource-constrained devices, namely the clients, to do that discovery when needed.
In short, I don't yet see strongly compelling reasons to break with the established specification of using `a` tags in common with other Nostr event kinds.