Also tl;dr at the end of the note ;)
One of the first things that caught my attention early on when I discovered Nostr was that relays were dumb and clients were smart. All relays could be used homogeneously and interchangeably. The more relays, the better, right? The bigger and more distributed the network, the harder it is to shut it down or prevent someone from using it. In other words, in this topology, decentralization and censorship resistance scale horizontally. And this is true, I really believe it. But as Nostr evolved, more use cases emerged, new attacks appeared (spam, etc.), and Nostr started to need more specialized relays, hardened specs, rules, and so on. This shifts the balance between dumb relays and smart clients, and in my view, it’s a logical evolution.
A one-size-fits-all solution is difficult, if not impossible, to achieve. We’re seeing this tension now with the buzz (I used this world deliberately 🐝) around chats, groups, and so on. NIP-29 is a clear example, it acknowledges this tension from the start and accepts it to make things work. From my perspective, this is the right approach, and I completely agree with Constant (npub1t6j…ksrw) :
"The point of Nostr was never to get rid of servers; the point of Nostr is to be free again to leverage them for what they are good for. "Platforms" conflated purposes, also taking responsibility for identity and by extension the social graph, resulting in the capture of the user."
Relays are servers too ¯\_(ツ)_/¯
Accepting this limitation of "dumb" relays means accepting that not every use case will fit into general purpose infrastructure. Expecting any use case to work reliably, beautifully, and without issues in such a setup is a stretch. Specific use cases with constraints or requirements need specialized services that can support them.
On the other hand, the problem with specialized relays is that they scale vertically, unlike general purpose ones. This means each specialized kind of relay becomes its own decentralization and censorship resistance vector. This does create some tension with Nostr’s original promise, but in my view, it’s a fair and honest one. Specialized relays make sense, and we shouldn’t feel aversion towards them.
Beyond this, there’s a third path I’ve been exploring with ContextVM (npub1dvm…3jdm) , moving the "smart" logic to a separate service that runs alongside relays and just uses them as a bus. This way, complex or specialized logic can be offloaded from relays, which can remain as dumb and homogeneous as possible. Before CVM, DVMs already offered this characteristic, it’s just RPC over Nostr. From my perspective, this approach strikes a great balance. As I mentioned earlier, if relays are standard and not specialized, they remain homogeneous, decentralization and censorship resistance scale horizontally, and the network becomes more resilient and harder to shut down. CVM also doesn’t impose storage pressure on relays, making relays cheaper and more sustainable to run. A clear example of this is Cordn coordinators, an specialized service that handle ordering so the MLS encryption state machine can work without issues. They interface through relays and store encrypted blobs, but nothing is stored in the relays themselves. Any relay accepts their traffic, and it works well.
Another nice feature of offloading logic from relays and running it in a separate service is that the bus doesn’t know what’s running, and the logic service doesn’t have network visibility. This creates a nice balance that benefits privacy and deniability. To wrap up this section, another interesting advantage is that running CVM servers is easier than running a relay. Relays need to be exposed, requiring network configurations and touching parts of the internet’s permission backbone (DNS). Of course, you can run a relay on Tor, but a CVM server doesn’t need any configuration, you just run it, and it’s accessible. You can even run it from your laptop in a coffee shop.
TL;DR: Dumb relays are great for decentralization and censorship resistance but fall short for use cases with specific requirements. Specialized relays are necessary and make sense for supporting those use cases, but decentralization scales vertically. CVM is a third path that leverages a network of dumb relays while offloading logic from them.
quotingtldr in caps at the bottom.
nevent1q…27qe
Everyone has this list of demands that can never all be true as far as 'groups' are concerned.
The most sensible straightforward, ensured to just work now, and in the future, thing is NIP29. But in the long list is demands, NIP29 does not comply because it is tied to a specific relay, and it is not encrypted.
Now is that a problem? Not really, you can migrate to another relay if there are any issues with the relay you happen to use. Relays are also one of the easiest type of server to run, so its the lowest threshold thing we can offer the world in terms of infrastructure requirements. If you want privacy, use a relay you trust for some reason, which is probably the least of your worries anyway because you also need to trust every participant not to leak stuff.
Its already better than everything else we use, be that telegram, or discord or whatever in terms of being able to use whatever server/relay you want, use whatever software/client you want and those clients can interface with whatever group, regardless of what relay they happen to run at. All of it better than what is already out there in the world.
But again, this impossible list of demands...
So people much rather just chase their own tail going in circles and circles, coming up with "new" things, in a domain of known trade-offs. that are bound to break at some point, or at best end up working shitty; but you won't notice that directly because any silly system works at small scale in a low complexity environment. By the time things do break down, or start to stutter, people won't understand why, because it is obscured with all these bells and whissles. And to fix or patch them, you are bound to move closer to what would ultimately look like NIP29 anyway.
Underneath it all is actually a fundamental misunderstanding concerning Nostr...or lack of complete understanding rather. This lack of comprehension is exemplified by the 'Nostr is the identity layer' crowd; they understand they key/signature part of Nostr, they ignore the Relay part of Nostr. Don't get me wrong, I am not trying to diss anyone here, it took me a long time before i got it myself:
The point of Nostr was never to get rid of servers; the point of Nostr is to be free again to leverage them for what they are good for. "Platforms" conflated purposes, also taking responsibility for identity and by extension the social graph, resulting in the capture of the user. In that model, users and the network-effect-value they bring is locked in and tied to a particular server. And because those users are stuck, the server can force feed them any algo it wants. The whole point of the keys is that users themselves are able to generate them, subsequently sign their publications making them tamper-proof, which in turn reduces the trust-relationship and purpose of servers into simply relaying those publications, giving control back to users as to what they get to see. The point of Nostr was to shift our relationship to servers, using this 'trick'. But that also means a shift in the relationship between servers and their users. It free's servers, just as much as it did the users, no longer being beholdend to juggle the impossible combination of interests.
All of this opens up an entirely new landscape, and the implications create a spectrum that runs with that twofold liberation of both the user and the server on either end.
On the one end the server/relay is general and non-specific; and on the other the server/relay is particular and specific. Outbox-model on one extreme, NIP-29 on the other; and all the flexibility in between.
We are all figuring this out as we go, especially because most of it was/is stuck inside of the head of some mumbling guy with a silly accent that just assumed all the implications would be obvious to everyone from the get-go. But mostly because its all new, and we are all a bunch of uncoordinateable cats tinkering in decentralized chaos.
These posts always escalate to the point where they were probably better done as a long-form post with some care to remove the typo's and things...but i got to go, so it is what it is. The take-away:
USE RELAYS FOR WHAT THEY ARE GOOD FOR WHICH IS CURATION AND ORDERING; USE RELAY FEEDS, USE NIP29, USE NIP63, ETC.
Nostr.
nevent1q…a9pu
nevent1q…9wvn