Many people are saying “put it in the client”. Of course, this would be ideal. 

A few challenges:

1) Right now, each client can only connect to a limited number of relays. For example, Damus recommends ~10. This forces nostr clients to connect to a small number of large (high bandwidth) relays to reach all other users. Basically, if you can only connect to 10, then you want to connect to the same 10 as everyone else so that you can reach everyone. 

2) If relays were installed in phones, they would quickly go online and offline. Each client would then be forced to connect to a massive number of low bandwidth relays. This is the opposite of what happens today. 

3) Mobile devices have limited bandwidth and aren’t designed to be low latency servers. Desktops can handle more load, they generally have higher bandwidth limits, and can be left running for longer. People need to be motivated to run desktops to support the network. 

To move the relays into the clients (which should be done to make the network decentralized) the core underlying protocol would need to be completely redesigned. 

I’ve been brainstorming and experimenting with such a thing but it’s not ready for presentation. I think I’ve loosely “solved” the broadcasting piece (hint: bees and flowers). But I still have two massive missing pieces. 

First - replies (replying to someone else’s message so that 3rd parties can see it)

Second - data efficient discovery (eg. how to allow hashtags in a way that doesn’t drown your device in spam).

Both of the missing pieces are essentially data discoverability problems so perhaps they will eventually have a common solution 🤞

The challenge is minimizing latency, bandwidth, and data replication. Also, no matter what, moving the relays into the clients will likely degrade the UX. Centralized systems are faster, more responsive, and therefore generally have better UX. nostr:note1l7yww5ltcd5an05vcevht5ltqx4z5rnrus29j28zddwgeskns7dsrrqtw0