Clarify the relay role regarding other relays #111
Conversation
A relay service might want to serve content that was not posted to it. So, a relay could talk to another relay for this syncing. There is a new relay code proposal that calls it "yesstr protocol": github.com/hoytech/strfry
|
on nostr, relays don't talk to relays on purpose. when a relay talks to a relay, it's acting as a client, not as a relay, even though it can be both, it is better to keep that separate. |
|
I agree 100%. I am not proposing any protocol changes. It just felt to me that the README can be clarified to say that a relay might talk to another one to sync content (it is working as a client as it does it, but it is still a relay, be it from the point of view of a relay software developer or a relay operator). |
but it's not, it's a client that is talking to both relays, it just happens that that particular client has a direct db access to a relay |
|
A client that has direct access to the DB of a relay is a somewhat very special client. I am not sure if the wording I used for the proposed change on the README is very good and clear, or if it creates more confusion... But it is related to this description given here https://github.com/hoytech/strfry#syncing:
|
|
I think this change is good. I am very afraid of changing anything right now. I think a bigger change in this README is needed, but I am even more afraid of doing that. Will think more about it. |
|
@fiatjaf In all likelihood there’s probably nothing you can do one way or another besides advocating. People are going to do what they are going to do. But I’m going to advocate here for you to advocate… As more people start using nostr and it slams into scaling pain points there are going to be pretty obvious short-term, shortcut solutions to these issues that involve relay -> relay communication. I noticed the strfry / yesstr proposal quoted above, but I’m seeing a lot of other similar things peppered around in my nostr feed. I could be totally wrong - there’s no way to see the future - but my intuition is that these types of proposals are a slippery slope from here to mastodon hell. If nostr relays don’t stay dumb, commodifiable, and ALL over the place, I don’t see how nostr can scale. And if relays start talking to each other, I don’t see how that doesn’t end up with federation, silos, and the mastodon sub-centralization clusterfuck that nostr’s six degrees of kevin bacon approach is the antidote to. For me, the most interesting thing I read in this repo’s readme are exactly the words that this PR wants to change. And I’m not arguing against changing them. But I’d probably want to change them in the opposite direction of this PR. I’d also argue in favor of incorporating some clarifying language about relay -> relay communications in NIP-01. As I wrote in another NIP issue (about reactions) recently, the more bare and spare that the nostr protocol is, the better chance I think it has of working which I define as enabling people to build feature-filled, performant clients and relays, extending the core protocol beyond twitter-like social media, staying truly and meaningfully decentralized and censorship-resistant in practice, and being able to successfully scale beyond the (I think) few thousand regular daily users that are active on nostr now. So I am advocating that you advocate for no relay -> relay comms as an inviolable cornerstone of the nostr protocol. |
ghost
mentioned this pull request
Nostr nobody here, just pointing out that The Nostr protocol is not going to "revoke" any relay's privilege to communicate with others on the network, whether it communicates directly (with strfry) or indirectly (as a "client") with other relays. The worst it can do is to rigidly assert that such communication is not sanctioned by the protocol. As long as "behind the scenes data transfer" is a feature desired by end users, it's development will persist, which may end up splitting or weakening the protocol. While The Nostr protocol is being built to keep centralizing forces at bay, this will be a forever battle with many shifting fronts. As a living communications protocol, The Nostr needs to remain adaptable to a changing environment and to stay in front of an evolving definition of "what is" decentralized social media. We may not like it, and it won't be easy, but this need to be flexible is "built in" to the architecture of decentralization. Only by understanding when and how to pivot, will The Nostr protocol be able to stay relevant in its mission. The question is never "if". |
A relay service might want to serve content that was not posted to it. So, a relay could talk to another relay for this syncing.
There is a new relay code proposal that calls it "yesstr protocol": github.com/hoytech/strfry