nostr-protocol / nostr

a truly censorship-resistant alternative to Twitter that has a chance of working

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Why are relays needed and how does the key-based routing work?

alexhkurz opened this issue · comments

I have two questions.

In one extreme case every client could also be a relay, right? What are the advantages of introducing separate relays?

How does routing traffic to public keys work?

Sure, one could imagine a system in every client ran a relay. But since most clients do not have stable IP addresses, domain names, or SSL certs, and may have very limited bandwidth/energy (mobile) there isn't much of a point for them to run a relay. In that more realistic scenario, relays are a persistent store of events which can maintain data much longer and more efficiently than most clients, and in predictable locations.

There is no traffic routing, at least not in any planned/organized sense. Clients connect to a set of relays (determined statically, or dynamically), and open subscriptions to request events. Clients will typically broadcast events to a static set of relays that they have either paid to be a member of, or that they know are willing to accept free/public traffic.

Relays can act as aggregators, listening to other relays in order to increase how many events they make available. But this is totally unspecified and up to the individual relay if they want to do this.

You may notice in some clients (Amethyst for sure), there is an option to "broadcast" a chosen event (which attempts to publish it on all the relays the user normally writes to). This is yet another mechanism by which an event that exists on one relay may get sent to other relays.

Does that help make sense of things?

Thanks a lot. This makes total sense. The reason for relays is that we still need IP addresses. Do you know whether there have been built networks, eg by directly connecting mobile devices, that do not use IP addresses? What would it take to develop an alternative addressing mechanism?

I also understand now how the routing works (at least the big outline).

I started to teach distributed systems this semester and plan to extend this in the future. If you have any ideas of projects that students could engage in, I'd be very much interested. The whole space seems to be moving fast and I am still a newcomer ... thanks again.

commented

What would it take to develop an alternative addressing mechanism?

DHT: bittorrent (zeronet), IPFS (slow because DHT-over-TCP, how ipfs is broken), tor hidden services (tox messenger), gnunet, ...

non-DHT: bitmessage (all nodes have all data, similar to bitcoin)

for many other failed projects see https://github.com/croqaz/awesome-decentralized

Can Nostr work like DHT? I think DHT helps with the dissemination of information, and relay only needs to play a forwarding role, which should not increase the burden.
It can even serve as a forwarding server directly without saving content, which greatly reduces storage space usage

In fact, my point of view is that Nostr still has significant shortcomings in breaking the information blockade. There is an insurmountable information gap between different relays, and users obviously cannot add all relays.
Therefore, DHT may help change this situation and make information more free.

I want to read your stuff, you publish to relay A, I connect to relay A and read your stuff. There is no need or advantage whatsoever in disseminating information.

It is necessary to connect to the same relay to read content, which is not conducive to information dissemination.