Oddbean new post about | logout
 Because nobody wants to stifle creativity. We now have a couple dozen kinds of relays that users don't know how to manage or even have visibility into which relays do what. Nostr is becoming a place only devs will be able to use.

The complexity of nostr is growing far faster than we are able to wrangle and make usable for plebs and I'm afraid it is becoming unsustainable.

This is a middle of the night sick stomach ramble. I may not be thinking clearly. Please discuss among yourselves while I get back to     sleep. 
â–² â–¼
 How can we help steer nostr away from becomming some giant distributed ball of mud? 😞 
â–² â–¼
 I feel pretty confident that this is just another transitionary phase. Settling on a common vernacular & translating kind types, as well as relay types, into descriptions that users can understand without searching through repos will help. Minimal relay management for clients emulating the twitter experience, more targeted (or more broad) uses will obviously have to offer more. Branding relays with clearly descriptive names would help too. 
I've been wondering lately about the possibility of relay sets in the future, that users could plug in depending on what they are wanting to do. Just screwing around a lot & not fully understanding what I'm doing, it seems like it's possible 😅  
â–² â–¼
 I largely agree Mike. I'm a pleb with very limited, to say the least, technical ability. It does work for me but I don't fuck about with the settings too much because I'd only break it😂. I do try to read the technical posts that the devs write but it's mainly just🤯 to me😬.  
â–² â–¼
 Some suggestions: 
You are who the builders need to build for! Provide feedback to the devs. If you figure something out worth sharing, write an article using habla. news or wikifreedia. xyz. Article feeds are meant to be more slow, signals "this is important to me" compared to the casual "tweet". 
â–² â–¼
 Agree--still not quite sure how to leverage relays...but this will all come--the innovation is the important part. "Catching up" on documentation, FAQs, primers etc. can happen later.

For now, go forth and create!! 😃  
â–² â–¼
 What are the dozen different type of relays?

Why should non devs care?

How might app devs make these distinctions apparent to end users? 
â–² â–¼
 Im assuming Mike is referring to the list being discussed here: https://github.com/nostr-protocol/nips/issues/1282 
 https://github.com/nostr-protocol/nips/issues/1282

I think we have to have these marketing labels, and users can sign up for the various services they need.  But also clients need to present to users only relays that actually are capable of fulfilling the role.

This part of the problem isn't that bad. Most of what Vitor listed isn't necessary.

But my job is to focus on problems which I continually do even when trying to sleep. 
â–² â–¼
 holy shit. a useful NIP?! 
â–² â–¼
 If we standardize relay functionality, this makes development difficult, ossifies the infrastructure and reproduces the "federation" protocol constraint. If there were a standard "documentation" message so the client operators can make an educated decision, this may allow enough flexibility to prevent stifling development. 
 I'm of several minds here.  On the one hand, yes I think we standardize relay usage labels (or roles) and users (client operators? getting fancy with your terminology here) can pick relays to serve in various roles.

On the other hand, I worry that if we don't "ossify" at least some core parts of nostr (and instead keep breaking them), nostr will fail to interoperate more and more as time goes on. 
â–² â–¼
 True, the "computer interface" obviously needs to be standardized, however backend functionality such as data retention policy, spam handling, etc, these kinds of tapestry need to be documented and communicated to the client operator so they can make an educated decision about whether they want to use the relay. Today this is done with a webpage, and maybe just a link to a webpage is enough, but it could be standardized how to get to this information through the relay list. Another standard could involve linking through to your npub's "public dashboard" on the relay where you can change settings and check the status of your subscription 
â–² â–¼
 "Client operator" yes, a funny term. I mean users of the client (as opposed to people interacting directly with the relay through the relay's webpage) 
 I cant even solve this for users: some relay advertises itself under thousands of different URLs. How can users now manage that? According to every NIP relays are defined by a URL which includes a path part. I have to therefore treat them as separate relays.

I don't want to capture users and say "ignore all those, use my 3 relays" but that is the obvious central solution this mess is driving towards. 
 As a pleb I is a want to a opens a my clients and is a let to post the a notes and a read the a notes in xitter mr. Elon is a very nice ok so he is a take a care of a everything and I a just a read and a shit post and I a beliving a #nostr is a should be a same thank you 
 Don't worry we got ya.  My job is to worry so you don't have to. 
â–² â–¼
 ditto  @banjo
the world is getting faster and faster and trying to keep up with it .... 

the secret, as has always been the case, is focus. find the tools you need and make it happen. 

the white noise - that's other people's projects, using the other tools.

thank you for all you do in the space. 
GM