-
Notifications
You must be signed in to change notification settings - Fork 325
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Why are relays needed and how does the key-based routing work? #160
Comments
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. |
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. |
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. |
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. |
"no need or advantage whatsoever in disseminating information"
Isn't dissemination the way social media create value?
… On Jun 10, 2024, at 10:21 AM, fiatjaf_ ***@***.***> wrote:
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.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
It is necessary to connect to the same relay to read content, which is not conducive to information dissemination. |
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?
The text was updated successfully, but these errors were encountered: