add "global" relay lists #1786
add "global" relay lists #1786
Conversation
|
I agree that more attention could be paid to relays as such. I call this relay de-commodification, or "keep relays weird". In order for this to work, relays have to be able to serve a unique, curated dataset (whether by scraping the network, authenticating writes, or publishing their own content). These datasets can't be interesting in a global sense, because people have different interests. Which means relays have to be interesting along some axis, whether because their content coalesces around a topic, person, institution, conversation, group, whatever. So relay recommendations need to be classified in some way. In the past, we had kind 2, which no one used. Nowadays we have relay sets. I still like NIP 32 for this kind of thing, since it allows you to create "collections" around some arbitrary "label" that can belong to an ontology (so it has out of band semantics), or completely user-defined. This is slightly different from relay sets, because why someone might put a relay into a relay set depends on what they intend to do with the relay set. Putting something in a labeled collection might be equally ambiguous, but it's closer to being a "fact" than a "command", and so is decoupled from actual use case. An example of this is how Coracle decouples lists and feeds. You can add a user to a list, then add multiple lists (maybe curated by someone other than yourself) to a custom feed. This separates the "what" from the "what for". All that to say I think I want the same thing you do, but I think classification of relays is necessary. "Relay collections" would be a better way to articulate this than "Global relays", and there should be some "target" tag to classify the relays. Since these should be single-letter in order to be indexed, and since collections will inhabit the same namespace regardless of association, I think NIP 73 references are probably the best way to do this. So, concretely, I'd change this to use a kind in the 3xxxx range with a |
|
Are you suggesting what we already have -- "relay sets", kind 30002? |
|
That would be the simplest solution, although relay sets don't really provide any machine-readable way of classifying stuff, just a human-readable name. It would be nice if clients could filter topic-based relays from url-based etc |
|
I guess I'm ok with this. It is a discovery mechanism for popular relays, and sometimes you want to know which relays are popular for a lot of different reasons. And the answer to that question is in the hands of the people and distributed and can change over time. So this is fine. |
|
IMO, specialized relays need specialized clients. But not in terms of functionality. In terms of brand alignment, ready-to-go onboarding, and UI for culture/community building. If I operate a relay, I don't want to say: "download Amethyst and then add my relay there"... I want to say "download MyClient and just browse our stuff". Everything is already set up for that user. There are no feature that conflicts with what the relay is offering. There are no off-brand distractions. The community is the app. Take your Brazil-focused relay, for instance. In one way, you can just add that relay to Amethyst. But that is boring because Amethyst has too many other things and defaults that don't make any sense to Brazil. Now picture a relay operator that makes a fork of Amethyst, deletes most stuff, changes the defaults and makes the UI with the Brazilian colors. Now we are talking. The app's UI hits the brand/culture head-on. "It just works". All users have to do to onboard new people is to ask them to install the app. There is no weird setup with some random app. Some clients can do well with relay-based feeds. But they will always be limited by the common denominator to all those relays. Clients that are specialized to what the relay wants to curate will go much further. |
I agree this is ideal for certain applications, but it's demonstrably false as a general rule. "Follow me on twitter", "visit www.whatever.com", "subscribe on patreon", "in your favorite podcasting app". It's great to follow people (pubkeys), but relays should be first-class citizens too, and require similar (but different) handles. |
|
I don't disagree that "relays should be first-class citizens too". I just don't ever see that catching on without good branding from the relay. If the relay keeps being this hidden server that doesn't even have a website in its own domain to help users visualize its contents and determine if it is a good curator or not, they will never build the traction they need to assemble their community. Literally just putting a good web client into the relay's domain name will already make a big difference from today's world. If they can customize the client to match their brand, even better. Like, not even @nostr-wine, which has the best relay brand on Nostr, has a good website for users. |
Perhaps a bit off topic but how can we improve? |
Add a way for users to visualize who is in your relay and how awesome the discussions are. Maybe a global feed on your website to showcase the content you have on the relay. Make them want to participate and be there. Give them a real-time taste of the awesomeness. |
|
This is all irrelevant to my proposal here, but I do agree with @vitorpamplona about relays having to care about their brands and have webpages. I don't agree with clients that only talk to one specialized relay, though, that would be catastrophic. |
The proposal is fine. It just doesn't solve much. As you said, we already have relay sets. The many clients, including all of the bigger ones, allow people to choose which relays to use for Global and store it in their own ways. This PR only creates a way for those settings to be interoperable. Which is nice, but if the idea could solve the issues from your first post, it would have solved already. |
|
That's fair, but do you agree these problems exist? Do you have another clear solution in mind that I'm not seeing? |
I may be going crazy, but this is an attempt at a proposal to address some "discovery" issues Nostr has.
For the microblogging, DM, mentioning and any use cases where you know from whom you're reading it's clear to clients the relays they should read from or publish to, but this is not true in some other instances.
I've long been wanting to promote the idea of specialized relays, community-operated relays, whitelisted relays of any kind, but one thing that is missing is a list of relays known to be public squares where (basically) anything goes. Not a relay you're signaling to others to be your main place where you publish stuff, but perhaps a place where you also publish your stuff just in case. Or maybe this list includes known "aggregators" that slurp content from other places.
If hopefully Nostr grows a little more even these public squares tend to become more spreaded, and even today there is a natural distinction (even enshrined in apps codebases) of the "default" relays being different if you're in Japan, Thailand or Brazil.
Use case 1:
For example, if you want to browse comments made about some random website, to what relays do you connect for reading?
a) do the outbox model and connect to relays your friends publish to;
b) connect to hardcoded relays defined by the app (some developers may be tempted to hardcode a ton of relay URLs here);
c) give the user the option to define their own list, starting with some defaults (which will often be nos.lol, relay.damus.io, relay.nostr.band, I don't know);
d) use relay sets -- and the user has to pick one or create one.
This new proposed list streamlines the b/c process by standardizing it across multiple apps and also by allowing these lists to be shared, so when the relays that were hardcoded (and that were, at the time of the hardcoding, known to be such public squares) get shut down then clients can automatically or manually switch to new ones.
Use case 2:
There are relays and DVMs out there today trying to promote "discovery" by categorizing notes and creating personalized feeds. Although other approaches would be possible, they tend to rely on hardcoded big lists of relays, which is not very wise.
In this case, having some key users define what is the "global" would make it easier to find a source for filtering content to be recommended.
Clarifications: