Proximity to relay servers is important for quality of experience. Did a little test with the @Nostria Find app with a few selected relays to see.

Here is a demonstration of the issue with profiles (metadata) not being accessible on the User Relays. I hope all clients, like Primal, Damus and others will begin to always publish Relay List and Profile to all relays whenever the user modifies either their profile or their relay lists. If that happens, everything will be working better for everyone.

Doing a "high-performance" decentralized lookup of hundreds of Nostr profiles is very, very hard to do. Many lack Relay Lists, many have massive amount of relays, many don't have their profiles published on all their relays. Many keep stale and dead relays in their lists. It becomes impossible to ensure a very good experience, it will be an best-effort and sometimes fail the first attempts. Hopefully as people user Nostr more and Nostr clients helps users maintain their Relay lists, this will improve in the future. Here is one way to improve in Nostr clients: Make sure that your client broadcasts Relay List/Following List/Metadata whenever the user modifies their relays. Ensuring that any Nostr clients can pick a smaller set of relays when they attempt to retrieve that important data for the health of the network.

Working on populating the Nostria Discovery Relay, here is the results so far: First: Purple Pages Relay Second: Discovery Relay with Damus backup (10002) Third: Discovery Relay with Damus backup (10002+3) Fourth: Discovery Relay + nos dot lol. Some of the profiles without photos are discovered, they just don't have a profile image anymore. I will implement different styles depending on discovery status. Imported 500,000+ relay lists from Damus, almost 200,000 following lists (only those who actually have relays in them). Working on implementing negentrop support, which should make it easier to sync with other relays. So far so good!

As I am working on sync of User Relay lists (kind 10002) to the Discovery Relay, and then looking at the resulting database, I think it's obvious and clear that going the route of backwards compatibility with Following list (kind 3) is not sensible. Though user experience is important and having a portion of your following list not accessible is not ideal either, so I'll do a compromise: If there is already User Relay stored, the Discovery Relay will not accept kind 3. Hopefully all Nostr apps will migrate the users towards a better future, where everyone use Relay Lists and support for kind 3 can be deprecated for getting user relays. Quick validation shows that average kind 3 is 24.75 KB, while kind 10002 is usually always below 1KB. With 1KB pr. user, it only takes 1GB for a million users. Nostrdotband reports almost 43 million known pubkeys now. That means a total of 50GB is plenty enough to keep relay lists for all current accounts (a lot of those are spam and will likely never have any relay list). What is interesting though, is checking with our competitors: Mastodon has 10 million Bluesky has 36 million X has 650 million "500GB should be enough for everyone" - last famous words.

I just wrote and published my latest post on Scaling Nostr, introducing Nostria — Your Social Network. I'll do my best to work hard and make this a reality. Much has already been done, but a lot more to be built. https://medium.com/@sondreb/nostria-your-social-network-9ece58118061

Did some research on the columns widths on various social media apps: Primal is 640 pixels. X is 600. FB is 680 Bluesky is 600 (lots of margin, horrible little space for content) Threads is 640 Mastodon is 600 I'll go with 680 on Nostria, even though I'd much rather have more.

Question for Nostr client devs: Badge definitions (kind:30009) should primarily stay on the issuers relays, right? When someone issues a badge (kind:8), the client should publish on both creator and receiver relays. Should the definition be sent too? I would say No. Badge definitions (designs) can be updated, and if we send them to receivers, it means every update to the design, must also be pushed out to all previous issued user relays. This means rendering the profile badges event (kind:30008) involves discovery of relays for each issuer of the badge, then query for the badge definition at those relays. A user with 10 badges on their profile, could involve connecting to 40 (if each user has 4 relays in their relay lists) different relays to retrieve the definitions. Pushing the definitions to receivers will optimize this (I can get definitions and awards from only relay of the current profile), but there are no true best way to do this so I'm asking what you all think?

GM!

What is this, some kind of attack on Nostr? Pehaps someone can help investigate which kind 10002 or kind 3 event that has added these relays?

Started developing a new Nostr relay (the world cannot have enough implementations of Nostr relays), which is purely focused on being a Discovery Relay. It only supports kind 10002 and kind 3 ("fallback"). I realized there is no way that a lot of existing users on Nostr will begin to publish their Relay Lists, so I am also building an sync utility to grab Relay Lists from existing relays to populate this new one. Performance will be the best of any relays, simply because the feature set is extremely small. While not that impressive with 600 event writes per second, it was reaching the limits due to using Node.js for my load tester utility. What was impressive, it was doing this at 2-4% CPU utilization and 55 MB RAM of the Discovery Relay software. Running a sync from other relays, means that user's who do not adopt the suggestions from NIP-65 and my own interpretations of it, will still benefit as they will be discoverable in Nostria and other clients who want to improve scaling. Let's go!

JavaScript/TypeScript should be your default choice of programming language. If you are doing open-source and looking for contributions and longevity, it's also better as it's the most used language in the world.

Read the Tea Leaves

Why I’m skeptical of rewriting JavaScript tools in “faster” languages

I’ve written a lot of JavaScript. I like JavaScript. And more importantly, I’ve built up a set of skills in understanding, optimizing, ...