Is that stuffing things into relays?
Yes, I think relays adding anything more computationally intensive than what they already do is stuffing. AFAIK they already have enough problems to solve in terms of storage and bandwidth.
We already have a problem with relay discovery, right? It seems like it'd complicate things further by having relays implement bespoke NIPs. Are they relays or everything-lays?
The internet's design works because each layer (approximately at least) does the minimal amount of work necessary for its layer to function. It lets that layer (in this case relays) optimize its functionality to death like ISPs do to the IP layer. Specialization scales well.
AFAICT relays already have enough functionality to optimize: event storage and making that storage highly available through basic queries while also protecting itself from abuse. That's A LOT to do well even at the network's current size.
Counting and search and complicated queries are stuffing IMO. Yet, they are absolutely necessary for meeting user expectations. Some relays could provide multiple layers at one address if they wanted, but architecturally, it makes more sense to add this kind of additional functionality in a layer - a layer relays do not concern themselves with - rather than make a single heterogeneous relay layer.
Anyway, sorry if I'm getting this thread off-topic or if this makes little sense to more active nostr devs. These are just thoughts I've had when considering how to build a reasonably good SN on nostr - it needs relatively complicated aggregation, which I couldn't expect relays or clients to do, yet ideally this aggregation is provided in a protocol layer so that it could continue to use relays for storage/retrieval and be decentralized.