I'm in full agreement. Also, even if aggregators could theoretically scale, I don't think Nostr wants to replicate the Bluesky/AT architecture, as in practice these components end up being very expensive to run and likely end up in the hands of a few companies with deep enough pockets. Nothing against aggregator relays, directories, "global" firehoses/caches, etc., in the context of specific Nostr experiences. But the less we rely on all of this, the better.

I think that using the relays from the njump.me list below (which includes all of the relays mentioned above), or whatever relays njump.me is using as fallback nowadays is a safe way to go. Somehow njump.me never fails me.

Keyoxide will be merely a consumer of nevents for validating claims. And worst of all, it will be an indirect consumer. I.e., the users will input the nevent as a claim, for instance, using PGP notation and uploading their public key to a PGP keyserver. From there, Keyoxide fetches the PGP key, extracts the nevent from the PGP key notation, and uses nostr-tools to connect to the underlying relays, download the note and validate the "proof" (I.e., specific text in the note).

This means the options here are either telling the user to use a better client to generate a nevent with proper metadata, or hunting for the event blindly. I almost feel like, long term, telling the user to generate a proper nevent is a better strategy. Even if it means slightly worse UX for now.