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.

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?

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".

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.

Nostxyz 😂