The thing with Nostr is that the protocol spec expressly forbids relays from forwarding messages to each other.
What this means is that users trying to reach each other need to shotgun messages to many relays, or congregate around specific ones. User profile data will list the relays they listen on, but this suffers from the problem of sticky defaults and makes client authors the kingmakers.
There's lots of centralization pressures like this that the protocol maintainers don't have a good answer to. They tout the simplicity of the protocol, which is often a virtue, but they overdid it and made the protocol too simple to achieve its goals.
> protocol spec expressly forbids relays from forwarding messages to each other.
That statement is false and if you disagree: please provide a source.
There is no such restriction on the NIP (protocol guidelines). I have been writing NOSTR software since years and there was NEVER such restriction in place. In fact, wouldn't even make sense because some relays (e.g. Primal) are super-aggregators for smaller relays.
> users trying to reach each other need to shotgun messages to many relays
This is a false statement. NIP 65 provides a list of which servers the users declares to be using. This way readers for that user know at which door (server) to knock and ask for updates.
there are relays built exactly for this, for rebroadcasting. You can do whatever you want in nostr btw.
this is also not entirely needed since you publish a list of relays you use, and so clients publish notes for you to them and you read from the relays of people you interact with.
there are many different people/teams working on different aspects of nostr, there are no protocol maintainers.
it doesn't explicitly forbdit it. It just doesn't spec it out, because it doesn't need it for the protocol to work. There are already many relays and clients that do just this.
I think GP's point (which I agree with) is that the functionality is almost essential. When it's not part of the spec, then you end up with differing off-spec implementations, and again, centralization risk.
This would be like the HTTP protocol not defining `POST`, and leaving it up to servers and clients to implement it based on however it feels like.
I really like the ideals behind Nostr, but I think its implementation and execution could be better.
It would be more analog to HTTP not specing out how CDNs should work, or Usenet not specing out how DejaNews is going to work. It's infrastructure stuff neither the client nor the simple server has to care about.
The Nostr spec covers what matters, cryptographic identities and unique message ids, that make dumb relays that duplicating messages from elsewhere possible (an area where HTTP or Activity Pub fail at).
But part of the protocol is that user profiles also list the relays where to find their content (where their posts go to) and a second user connects to those relays to fetch their content directly?
What this means is that users trying to reach each other need to shotgun messages to many relays, or congregate around specific ones. User profile data will list the relays they listen on, but this suffers from the problem of sticky defaults and makes client authors the kingmakers.
There's lots of centralization pressures like this that the protocol maintainers don't have a good answer to. They tout the simplicity of the protocol, which is often a virtue, but they overdid it and made the protocol too simple to achieve its goals.