Thread

If you can you come up with a taxonomy for all the relays in

relays.land

I'll be convinced.

@Vitor Pamplona did a pretty good job with this in the nostra protocol/nips repo; I believe it was an issue not a PR.

I don't think that classification would solve this problem (nor it was its goal). If I remember it correctly it doesn't work for any of my examples.

No, it doesn't directly resolve it, but it is the right approach. All your examples are still technically relays, the issue is you have no way to clasify or express them. Adding an arbitrary number (2-3) of new terms and eliminating usage of the term "relay" might address the stated issue, but creates new ones. What are those 2-3 terms? How are they defined? What percentage of alignment does a *relay* need to be a _____. What if there is a relay that us a combination of all 2-3 types in some way in the future?

wss://relay.damus.io/ is a star. wss://pyramid.fiatjaf.com is a planet. wss://topic.relays.land/whales is an comet. wss://lang.relays.land/es is a meteor. wss://nostr.wine is a starplanet. wss://bucket.coracle.social is an asteroid. wss://impromptu.relays.land is a comet. wss://lockbox.relays.land is a small starcomet.

And wss://purplepag.es is a blackhole?

wss://jellyfish.land is a whole galaxy 🪼❤️ Our proxy will be a kind of wormhole 🫨

Are we urbit now?

That would be an astroid belt... a personal, private relay would be a black hole. 😂 The application of cosmological terminology could actually lend a lot of nuance to explaining function... and it fits very well with people's tendency to call Nostr "the Nostrverse".

Lol @ asteroid btw

Does Urbit have a monopoly on names of space bodies? In that case can you please come up with another analogy please?

T shirt sizes

Sandwiches

Periodic Elements

errrr, Elements from the Periodic Table :D

Finally always wanted to try that out /s

My kneejerk reaction is "this is stupid" because someone else tried using the planet/galaxy analogy with a different social platform. Also, its not self explanatory, but with an explanation the idea might work

We could also use other analogies, like different types of fungi.

If you're going for the least intuitive, then yes, fungi or amendments to compost

We could also have RIPs, "Relay Incantation Procedures," with an arbitrary 2 character index, you know something like RIP-01

🤣🤣

wss://relay.internationalrigh-wing.org

I don't have any ideas, but I would be happy to do it. I think the name "relay" should be abandoned. I don't like it, it's ugly, dry, hard to pronounce, hard to translate. We could replace it with 2 or 3 different names for different types of Nostr message servers.

Oh boy, get ready for the "relays are the standard" mob and their pitchforks.

I'm going to be thinking about this all day. Maybe I'll finally come up with my feedback test note. :)

I have thought about this for years, but it was way to early to attempt to atomize relays. Seems like now is a better time + you already started this effort more than a year ago, no?

Planet

Community Board Group Channel

Can we have a relay type flag on NIP-11 so client devs can block people from putting these relays on their inboxes/outboxes? your issue

GitHub

Relay Type Nomenclature · Issue #1282 · nostr-protocol/nips

We need to find good labels for each relay type. Apps need to request users to put a relay of a given type in certain fields, and relays need help ...

already perfectly describe it

Well, I thought about "Relay Types", which is an improvement. But the question here is if we should keep calling them "Relays" at all. I actually think Relay is the correct technical name for what the thing is doing. But UX-wise, we are calling too many different things "Relays". And that doesn't help anyone. The main issue is that people are adding Community Relays as Outbox Relays... Because everything is a "Relay".

That could be done but what if some relay doesn't use the flag? And what if a client doesn't respect the flag? Ultimately other clients will have to work around this anyway. There are tons of other issues that could arise from kind:10002 relay lists: - the relay may be offline - the URL may be invalid - the relay may have banned the user - the list may be outdated and the relays where the list is being fetched may have banned the user and continued to serve old outdated That's why I think any Nostr app above some threshold of complexity must eventually implement a scheme like seen in

how nostr works

, relying on relay hints from others and decreasing scores for relays as they're perceived to not return new notes from the target users, so new relays get tried until some succeed or until a new better relay list is found.

By the way, this scheme is heavily inspired by an old version of

GitHub

GitHub - mikedilger/gossip: Gossip is a nostr client

Gossip is a nostr client. Contribute to mikedilger/gossip development by creating an account on GitHub.

(the new version is similar too, I think) and is implemented in

GitWorkshop.dev

Decentralized github alternative over Nostr

and used in njump and nak and some other minuscule things. It's also partially implemented in

JSR

hints - @nostr/gadgets - JSR

@nostr/gadgets on JSR

but not used anywhere as far as I know.

Well, community relays are just a relay that exhibit particular behaviors and restrictions; any combination of those (and other) behaviors and restrictions could be atomized and expressed programmatically. How those behavior and restriction flags are defined could be tricky, but it would be far easier to maintain an array of flags in say NIP-11 than it is to constantly update the named properties (such as restricted writes) or to try to group those features under some atomized property. The methodology of using feature flags instead of named properties was one of my motivations behind signaling that we might consider splitting NIPs, which IMO should be specifications that affect relay behaviors from data schema specifications (what I called NAPs); they have different implications, different draft tracks and require different levels of scrutiny. IMO they are relays, as they fit the technical definition, but we shouldn't call everything just a "relay" and there needs to be a way to disscern one from the other. IMO your work on relay types was a good start to this.

I like it, but what exactly are planets? Normal outbox relays? Automated feed relays? Niche and community relays? Special inbox relays? NIP-29 provider relays? Comets, asteroids, meteors, stars?

Nostxyz 😂

I understand the other relay list issues, but having a flag on NIP-11 is a very easy gain to block users from adding relays like purplepag.es or algo.utxo.one to their relay lists (I have seen multiple times), and also display a warning to the user if they have those relays there and explain to the user the relay type

I was thinking of planets as relays that specifically provide feeds. Each planet has its own rules and brings together like-minded people to interact. Switching between relays is like hopping over to another planet to hang out. As for the other relays, I haven’t really figured out names for them yet haha

@daniele may be interested.

I'm following you and wanted to mention you for the same reason. I like the idea (yours too) of relays as something people move between. I don't know if giving them different names would actually help, maybe it's better to use attributes/adjectives.

Island, boat, continent, ship, platform.

island: curated community relays continent: big relays platform: normal relays (inbox/outbox relays) 🤔

Relays are just “event stores”