I completely reject the idea of:
Dumb relay, smart client
Why would we want the more powerful hardware that is online all day to be dumb?
It has all the potential to do the computing people want and all day to do it
Instead we want clients to, in real time, digest all these notes and compute them, filter them etc?
Anyway I'm gonna keep making smarter relays
when you frame it like that, it seems kind of obvious for relays to be less dumb
And why should relays store and transmit junk only to be filtered out by smart clients?
Because you can't trust the relay as much as the client. Simplicity is durability, compatibility, reliability.
Really? I don't think one or the other would be more or less trustworthy.
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.
Aight aight I’ll try one of your relays. Let’s see how this goes.
It’s an interesting question. “Embrace and extend” was one of the techniques that Microsoft used to attack open protocols. They would make their implementation better and therefore create a new standard that only they controlled.
The risk would be if your relays extend the protocol, creating lock-in for the custom clients using it.
Same. Dude. Same.
I think alot of the functionality we want in relays is better off as separate services. This isn't to say relays can't do anything clever, but the more we rely on relays to provide these services, the more centralization risk exists.
If you're concerned with centralization of one implementation. Strfry is running on most major relays. This is why we want more.
I want my clients to connect to one relay that acts as a client to the other relays
Yes I also think this is the way
The next evolution of nostr, client that run on servers.
I'm working on doing that programmically, from Sybil, with a Linux broadcasting bot that runs with my npub.
I don't know if it needs to be within a relay, but it's a nice sort of plug-in or utility.
Like, if I write something directly to my laptop relay (ws://localhost), I want it to broadcast to TheForest and TheCitadel, but nowhere else.
If I write something to sovbit.host, I want it to broadcast to a whole list of relays and auto-repost 6 hours later (cuz of time zones).
And I want to regularly pull everything from my follow list from that long relays list (excluding AUTH relays, to protect people's privacy) and broadcast it (and any embedded notes) to my localhost relay, theforest, and thecitadel.
Then I could just write to the one or the other, like having public or private channels in a logger.
Yes. This makes sense to me.
I absolutely would love to set something like this up, preferably running on my own hardware, but I have always tended to be more of a power-user for everything I get into, including Nostr.
I don't expect most users are going to have any desire or aptitude to set up their own relay that can do this for them, not unless it is dead simple to spin up and walks them through it like a 5th grader.
Does it have to be the relay or a separate service?
If it is a separate service aren't we splitting the responsibilities and controls better?
Same 💯
smart relay, client controlled ? (api)
relays can be a lot smarter, i just don't think anyone should mess relaying up with file storage
Redundant relays, smart client.
I have no problem with smart relays, so long as I can have the same data across multiple relays. That’s the idea I am working with.
Well I like my Bitcoin node dumb, "smartness" brings a higher attack surface.
Keep foundations simple.
The concept of “dumb relay,” as it was initially coined, in my opinion should be framed in terms of minimum and necessary functionality. The backbone of Nostr must be able to sustain itself with relays that expose the minimum functionality provided by NIP-01, each addition being a bonus, cooperating with what clients can make available.
This is not a matter of shifting workloads from one end to the other, but of seeking synergy, where the result is richer than the algebraic sum of the two parts.
There will inevitably be overlaps, redundancies, and that is good, as this is also in its way a form of decentralization on the relay-client axis.
I agree 👍 I think the idea behind “dumb relays” has held relays back a lot, and it hasn’t been true for a long time. There’s a lot of power and value relays have increasingly provided to users by being smarter without sacrificing the core principles of Nostr.
Even clients have started incorporating relays into their code, blurring the lines of what is a client and what is a relay.
There’s just nodes on Nostr 2.0. ✅
Yeah servers have a purpose and function, utilizing it fully is reasonable. I think we may want q mix of both complex and simple relays.
Runtime costs of simple relays are lower and that has a decentralization benefit.
We defo need nostr 2.0, but it only becomes successful if there's a uniform interface. #ditto is the best effort so far.
You have it wrong. In terms of "algorythms" the ideal is:
dumb relay,
dumb client
Dumb public relays = from the protocol point of view. From there everyone is free to do whatever they like.
