I hope you know @mieku that I'm just joking around with you. I can see you were frustrated and I thought I'd have a little fun. I take zero offense at your outburst, and I thought it was kind of funny.
If I understood what the problem actually was I might be able to make a suggestion.
you and all the client devs need to stop writing code that uses any other relays than the ones in the relay list, or at least make it possible to disable this functionality
If you want to test a particular relay, mark it as your write relay and your posts will write to it. Or mark it as your read relay and fetches of various types of content will come from it. If you want to follow someone that doesn't profess to use the relay you are testing, gossip will never go to the relay you are testing which doesn't carry their content because they don't post it there. Why would it? Clients go to where the user says they put their stuff, in order to get that user's stuff, and only for the purpose of getting that user's stuff. For other purposes clients are configurable (or should be).
If you want to force a client to go to a particular relay anyways and ignore the user's kind 10002 relay list, perhaps because your relay is actually a proxy, then great, fine. But most clients didn't code for that. Nobody submitted a NIP PR for that. There are clients that do this though. All the clients that don't support NIP-65.
I should take back my statement "gossip will never...". It might support client proxies one day. But I don't plan to. I don't think gossip benefits from that architecture.
If Alex Jones posts on nostr.alexjones.example.com and advertises this in his relay list, gossip will go direct to the source to get his posts. It won't go to eden.nostr.land in the hopes that eden.nostr.land syndicates Alex Jones. It will use Alex Jones' own digitally signed document that claims he posts on nostr.alexjones.example.com because that is direct, that is trusted, and Gossip has no reason to do anything less.
But other clients on phones, due to battery life concerns or similar concerns, might use a client proxy, or trust some syndication service. There are plenty of architectures people can dream up, and there are plenty of services people are drooling to offer to you ... for the right price.
when an event is private, sure, there's a good reason for that, privacy, but anyhow most clients try to find posts by ID on all of the relays in the list if they don't have relay hints... and then you get 10 copies of the events
unless the client is given an entity to find the post this is how it works, but it would be helpful if it were simple to propagate the results back to your write relays so that they are there for next time or for anyone else using the same relay looking for the same things
I don't think I talked about private events. I was just talking about following someone's public twitter-like posts.
Finding posts by ID wasn't the case I was thinking of, but in that case if you don't have a relay hint, I go to the seen-on relay of the event referencing the ID, and then I look at the p-tagged people and search their write relays in case one of them wrote it.
ok, so if i give it my relay set but only set writing to the ones i want to publish to it will search elsewhere for events if they don't appear on my relay set
i still would like to be able to disable this behaviour for testing my relays because getting nothing is confirmation of the relay failing to return something or failing to have stored it in the first place which is an important thing to be able to test, when the relay has ACLs and other kinds of filters running, sometimes you WANT it to not find it to confirm that it didn't store it or is not allowing the authed client to access it
Great. Then use a client like damus that only reads things from your relay set. It would be a huge rearchicture for gossip to do that, it's not just "disabling" a feature, it's rewriting huge amounts of code, because it never before sought events from your specified relays.
