rich1.0sandwich (npub1ua…q99rx)https://yabu.me/npub1uac67zc9er54ln0kl6e4qp2y6ta3enfcg7ywnayshvlw9r5w6ehsqq99rxnjumphttps://yabu.meSo that when req'ing notes only root notes are returned. Building a feed is already difficult enough, we have many kinds there's no reason why kind 1 should share space with replies. The "backwards compatibility" argument to keep kind 1 replies as kind 1 is myopic and demonstrates a lack of intellectual maturity on the subject of protocol development or ecosystem growth rules; one of which is to progressively eliminate DX friction points (not irrationally cling to them) Old clients will break, yes, but old clients are already broken. We accept unmaintained clients will break just as we accept bit-rot on public and free relays; so the "old client preservation argument" is BS and doesn't make it two steps past any logical counter-argument. In the short term clients would have to support two patterns, but the kind 1111 pattern is a fraction of the implementation complexity of the kind 1 reply publish/aggregation pattern, so the overhead is minimal while the payoff for everyone is huge, especially on a long enough time-scale. Most client devs know this nostr:npub1q3sle0kvfsehgsuexttt3ugjd8xdklxfwwkh559wxckmzddywnws6cd26p nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft Over time there would be less and less kind 1 replies, eventually, clients would drop support entirely, and once again, everybody wins: - Relays win because they don't have to return a haystack so that clients can find needles (less bandwidth, less clock-time for relays = higher throughput, easier scaling) ... this particular solution imposes zero new scope on relays. - Users win because everything is snappier and consumes less of their data plan - Client developers win because they just eliminated 2-3k lines of complex, buggy and fragile code and countless tests from their source tree and now have a predictable pattern. Either that or extend filters to include `IS SET` and `IS NOT SET` operand such such `["?p"]` and `["!?p"]` (nostr:npub12262qa4uhw7u8gdwlgmntqtv7aye8vdcmvszkqwgs0zchel6mz7s6cgrkj) ... don't make me start yet another operand battle nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6