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?
I want this device to record VR-video content! There are no good and cheap device to make good VR videos, custom setup with dual action cameras is a hassle.
I'll definitely add support for this!
What are the credentials? Is it based upon the W3C specification for Verifiable Credentials?
I also have a new NUT for cashu that needs more reviews and eyes on it.
https://github.com/cashubtc/nuts/pull/250
This is an implementation of a signer that stores the keys on the secret service of linux and communicates through abstract sockets:
Considered doing it by extending NIP-46? We are working on doing a remote signer for Bitcoin in relation with Angor in this manner: https://github.com/nostr-protocol/nips/blob/master/46.md
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?
Please share what you see in your mind! Would love to get some input ❤️
User Relays should be "sharded", meaning we should all be put in a pool of relays together automatically by the Nostr clients.
Instead of each popular Nostr client hosting their own single large relays for everyone, there should be a pool to select from. Those should have some metrics API available to allow Nostr clients to consider migration away from certain relays if the become slow and unresponsive.
Nostria will host many relays and distribute user's across them, ensuring scaling will never be an issue.
I wrote about this here:
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.
After Nostria finished the initial discovery process of people I follow, I was left with this list of "dead" relays. A lot of "digital rot". Might be a couple false positives, but I verified them all and it's mostly dead domains, 404 and invalid certificates.
Taking a break from coding to enjoy a nostr:nprofile1qyxhwumn8ghj7mn0wvhxcmmvqyv8wumn8ghj7urjv4kkjatd9ec8y6tdv9kzumn9wsqzp4sl80zm866yqrha4esknfwp0j4lxfrt29pkrh5nnnj2rgx6dm622n97yv ... mmm 🤙 
I was thinking of adding Podcast Studio functionality into Blockcore Notes some years ago. Probably a good idea to build a decent Podcast Studio app that runs on Nostr, utilizing Blossom for storage, episode info in some specific kinds for it, etc.
I mean that Nostr clients should help user's decide if they should unfollow an account depending on it being stale/dead and utilizing too many obsolete relays. "Friends help friends", allowing me to see "this person is not utilizing Nostr well, maybe I can send them a DM about it".
Yes, even was an user with relay "coracle" as relay URL.
After discovery process of all my following, the result is that Nostria has given a timeout to all of these relays.
Nostr clients need to be good citizens and help user's maintain their relay lists and remove dead relays. I will also help users maintain their following lists, making sure they remove accounts that are stale.
The kind of things that Nostr developers need to deal with... Makes me wonder which Nostr client added this to the URL value?
People I follow that has published their Relay List to Purple Pages relay. Many accounts I think are not being used much, so they still only have the old relays on their following list.
lol, I was performing some actions on X and I thought it was on Primal 😂
I believe the best way is to make the purchase of relays very seamless within Nostr clients, either as an included feature for Premium access, or one-click rent your own. I will attempt to make that into my new Nostr client (Nostria).
Perhaps the issue before has been that you purchase access to a larger shared relay, instead people should purchase their own relays. As long as Nostr clients implement the outbox-model nicely, it shouldn't be an issue discovering users and their content.
I wrote about "Discovery Relays" here, that should solve it and then everyone can have their own smaller set of relays, not needing large popular relays:
Implemented the "People" feature in Nostria, similar to Blockcore Notes. Work-in-progress for sure, but looks awesome.