As promised an updated list of devs involved in #nostr projects:
Thank you from heart 💜🧡
Forgive me if I forgot someone. Add yourself in the comments and I will make sure you are included in the next update.
#[1]
#[2]
#[3]
#[4]
#[5]
#[6]
#[7]
#[8]
#[9]
#[10]
#[11]
#[12]
#[13]
#[14]
#[15]
#[16]
#[17]
#[18]
#[19]
#[20]
#[21]
#[22]
#[23]
#[24]
#[25]
#[26]
#[27]
#[28]
Dear devs,
I think how clients set the default relays is a very important key topic to ensure future decentralization of the nostr protocol. The non-tech masses won't care about relays, they just want it to work. Max performance/connectivity and max decentralization are not the same route. We have to find the right balance.
We should develop a best pratice how to set default relays on clients.
Some form of randomness is vital to not fall for the centralization trap. It should be combined with some important metrics (eg traffic, reputation, ping, uptime, location ...). Defining these metrics and combine it with randomness is the key from my perspective.
Example for 12 default relays:
1. Connect to random ~3 relays with high user count, reputation score > 90 and uptime >99
2. Connect to random ~4 relay with mid user count, reputation score > 80, ping < 500 and uptime >95
3. Connect to random ~5 relays with low user count, reputation score > 70, ping < 100 and uptime >90
Let me know your thoughts on this.
Relays we subscribe to could be based on who we follow… kinda easy to figure out the right balance that’s needed by analyzing relays someone’s following send to.
The relay list would end up being different from one user to another, keeping centralization to a minimum.
Thats great but not applicable for new users right, since they don’t have a following list yet, right?
The concept should also include the follower list, to make sure you reach your audience or is it included in the same list?
Of course, new users would have to bootstrap somehow in a more centralized way, I guess. Thing is, relay subscription could evolve in the background without the user noticing. Just making sure to keep in touch with the most people with the least possible amount of subscriptions.
I’d still keep a list of relays, so that the client can start quick, without needing to download a ton of profiles doing so.
I also see smart clients noticing a much needed relay becomes unstable or down, and replace it with another automatically.
As power users, it’s OK we can select relays in the current nostr state, but least technical people won’t want to tinker with this, or even know it exists.
Should just feel like magic. ✨
Yes agree. However, I think the option for manual management should still be there, just to endure censorship resistance. If you take the choice away of choosing your relays manually means that controlling your relays = controlling you. Even so most people won’t use it anyway. Or do I miss something?
*to ensure
Sounds like the perfect solution to me 🤙
What has #[26] built?
Working on it :)
#followed and added. Thank you 🙏
Highly recommended to follow all of these people. They are in the trenches building the very services that you're using right now. 🤝
Standing ovation to all of you great people 👍
https://github.com/dtonon/nostr-ruby
https://github.com/dtonon/nostr-ruby-playground
Just proof of concept code, but usable; more to come :)
this is so handy to have StackSats, any idea who is working on Android App Nostros, enquiring for a nostrich
Congrats 🍾🎉🎊🎈
Thank you all for creating #Nostr
Congratulations!
nostr:npub1hycynfhz23ardfmf9kgwfw4gpyqj2fsh24r2zuehg4x7lx4kn5cqsqv4y3, we need to add nostr:npub137c5pd8gmhhe0njtsgwjgunc5xjr2vmzvglkgqs5sjeh972gqqxqjak37w to the list!
I have not maintained this list for a long time. No idea why it suddenly pops up again. But yeah, I have to update this and create a list on listr.lol
