Really? I don't think one or the other would be more or less trustworthy.
Discussion
You're running the client. Someone else is running the relay.
Neither is necessarily the case. Moreover, even if the client is doing absolutely everything locally, it doesn't mean I as the user have any idea how it works under the hood. There's just as much trust involved either way.
You are able to choose which client to run, or even write your own. If there's a bug you can switch to another one until it's fixed. Depending on your circumstances you can choose between convenience and security. Relays are shared by everyone, and simplicity improves stability.
Let's see if this equally applies to relays.
You are able to choose which relay to connect to. - True
You are able to run your own relay. - True
You can even write your own relay software. - True
If there is a bug, you can switch to another relay until it is fixed. - True
Depending on your circumstance, you can choose between convenient relays or secure ones. - True
"Relays are shared by everyone." - Not true
Relays are shared by those who choose to connect to a given relay. Someone may choose to run their own personal relay that only they can post to in order to back up their own notes. Or, they may run a relay to back up their notes and all the notes they care about from others (anyone they follow) that they also allow others to read from, but not write to. Or they may run a relay that is only for a small group of people to read and write to, such as their church. Or they may have the hardware and bandwidth that can handle running a large public relay that anyone can post to or read from, but even then that does not mean everyone will use it.
Relays are just as diverse as clients, if not more so, and users have a lot of choice about what relays they will connect to, or even run their own. So again, I see no real reason why users should trust clients more than relays.
Bringing the🔥! It seems to me that more people will run clients than relays, and the client has the last word before your eyeballs, so I would say that you have to trust the client more than the relay. And you can only connect to relays that implement all of the features that your client expects, so adding sophisticated features to relays has lower marginal utility than adding them to clients. OTOH, pushing all of the complexity into clients results in fewer clients that are harder to build, and you don't want that either. There's a balance that the community will ultimately find, and my expectation is that it will involve clients testing out new ideas, and relays adopting ones that have become stable and expected.
But what really matters is that it doesn't matter who does what where because it's all an open protocol and gfy we're living in the future! 🤙 🚀
There are some things that need to be implemented by both client and relay in order for them to work properly, but there's plenty of things relays can implement on their own without clients needing to do anything at all.
I think one of the most important things relays MUST do for their own continued existence, is mitigate spam as best they can, or else they will quickly fill up their data-stores with garbage that no one wants to see. Each relay must determine for itself what it considers to be spam, and the methods they use to combat spam should require as little cooperation from clients as possible. That said, they should be able to implement things like PoW as a spam mitigation method and expect clients to support it, because that has been a core NIP for quite some time. NIP-13, as a matter of fact. See the details here: https://w3.do/Z86qR9oX
Another thing relays should do, for their own safety, is moderate reports of illegal content being hosted on their relay. Unless relay operators are VERY good at concealing their identity and hosting the relay in a way that cannot be traced back to them, they could face serious legal consequences if they do not remove illegal content, but continue to allow it to be available from their server.
I do want to respond to a few other things you mentioned directly.
"It seems to me that more people will run clients than relays..."
This is ABSOLUTELY true, and clients should give their users a lot of control over what they see, regardless of what content is available on the relays users are connecting to. It's a both/and, rather than an either/or when it comes to whether spam and other unwanted content should be filtered at the relay or client level.
"And you can only connect to relays that implement all of the features that your client expects..."
This is not the case. You can connect to any relay, regardless of whether it has features your client supports. How useful that relay will be to you will depend on what your client supports, though. For instance, you might connect to a PoW relay that allows anyone to read what is stored on it, but requires a certain amount of PoW to write to it, unless you are on a white-list. If your client does not support NIP-13 it will simply be unable to write any of your notes to that relay. It will still be able to connect to it and read from it just fine.
"OTOH, pushing all of the complexity into clients results in fewer clients that are harder to build..."
This may not be the case. Not every client needs to have every feature. I don't need #Amethyst to have a Nostr integrated podcast player built into it. I have nostr:npub1v5ufyh4lkeslgxxcclg8f0hzazhaw7rsrhvfquxzm2fk64c72hps45n0v5 for that. I don't need it to have a music player that lets me zap the artists, that's what I have nostr:npub1yfg0d955c2jrj2080ew7pa4xrtj7x7s7umt28wh0zurwmxgpyj9shwv6vg for. I don't need it to have a news aggregator built into it, because that's what Layer3.news is for. I don't need it to have a recipe directory built into it, because that is what nostr:npub1xxdd8eusvdxmaph3fkuu9x2mymhrcc3ghe2l38zv0l4f4nqp659qskkt7a is for. And I don't need it to have a marketplace built into it, because that's what nostr:npub15dc33fyg3cpd9r58vlqge2hh8dy6hkkrjxkhluv2xpyfreqkmsesesyv6e is for.
We can have a bunch of clients that are very good at ONE thing, rather than relying on one client to have ALL the features. There will always be some clients that try to pack as many features in as they can, but at some point they have to pare it down for the sake of not overwhelming their users or making the client super-sluggish, because it is trying to load so much data all the time.
"But what really matters is that it doesn't matter who does what where because it's all an open protocol and gfy we're living in the future! 🤙 🚀"
I WANT TO ZAP YOU FOR THIS! YES! We're all going to do whatever we think is best, and the things that work will live on while the things that don't work will die.
To bring it back to the OP's "Why would we want the more powerful hardware that is online all day to be dumb?", I don't think relays should be smart, I think they should be efficient. As you pointed out they need to protect themselves from things like spam to keep costs down and stay alive. As someone else pointed out, we can have things run in the datacenter as other clients / DVMs, and still have simple, efficient relays. So at the protocol level, my expectation is that the more we burden the relays the less reliable and more expensive they'll become. OTOH we can have simple web clients, fancy web clients, slick mobile clients, and colossal workstation clients, and the cost and reliability is paid for by the person running it. We should try and figure out how to compensate relay runners not so they'll add more features, but just so they'll keep doing what they're doing. It's hard enough already and they aren't getting as much out as they're putting in.
And of course: we're all going to do whatever we think is best, because that's what makes nostr awesome! Apparently all we needed to do was remember that we can change the world. How long have we been sleeping 😞? Well we aren't anymore ☀️ 😎 ☀️
I guess it depends on what we mean by "smart."
They are going to need to have some form of being "smart" in order to weed out spam without weeding out new, legitimate users along with it. They are also going to need to have some form of being "smart" to properly handle reports of illegal content, without leaving opportunity for "report spam" to make the reporting useless.
Outside of that, how smart the relay needs to be will depend on the use-case. There are relays out there that don't store kind1 notes at all. The only reason they exist is to store NIP-47 defined kinds to facilitate Nostr Wallet Connect transactions. Part of such a relay being efficient is being smart enough to refuse all other event kinds. On the other end of things, clients need to be smart enough to only reach out to the specified NWC relays when looking for those event kinds, and not when looking for other event kinds.
So, I think both clients and relays are going to need to have a certain level of "smarts" in order for both to be efficient. But that can definitely go overboard, trying to do too much processing on either the relay side or the client side is going to make them inefficient and unreliable.
you can run both or use relays you trust. for whatever reason.