If you run an nostr:npub1aghreq2dpz3h3799hrawev5gf5zc2kt4ch9ykhp9utt0jd3gdu2qtlmhct they have an app for continuous backup to a private relay
I’ve been struggling with the NDK NIP 7 signer. Wondering if anyone that’s got some experience is open to DM-ing a bit.
It’s so odd, I’m getting success from NDK but the events I’m publishing are not on the relays.
#asknostr
Thanks for posting these thoughts. It’s amazing to watch Damus develop in real time.
I also think this architecture you’re developing is amazing. It may be the best shot we have at avoiding centralised relays and avoiding centralised servers for more algorithmic feeds. The performance is truly amazing.
So sorry for the confusion!
Hey yeah, I saw it called both 315 and 38. Colloquially it seemed to be 38 but in the NIP repo in GitHub it was originally named 315. Wasn’t sure how to reference it. Glad it got cleared up!
Subscriptions align incentives better.
If people want pay once for something that has recurring costs to provide, they want to get something for free (eventually)
Sure but right now no relays publish any useful metadata to help with that (like community preferences or other tags)
Cool I’ll add the ability to publish NIP 65 lists on https://relay.guide
Do you think the “right” solution is using what’s in kind 3 events? It seems like it gives a longer and more useful list.
But NIP 65 is more purpose built to solve this issue.
I can imagine it going either way.
If kind 3 is the right place for this info then I’ll submit a PR for NIP 2 to update it since it explicitly says to ignore the content field.
Gotcha. So a client still has to know a relay which you are likely to have published the NIP 65 event so they’re still going to check a bunch of high usage relays to look for a NIP 65 list or mentions of you to find a relay that’s likely to have it?
Nice and that relay list should be published following NIP 65? (Relay list metadata)
I guess this just isn’t commonly respected by clients yet? I’m not finding usage of this kind of event anywhere.
Good to know 🤔
A problem for sure. Do you know how clients check if the users has set preferred relays?
I've been trying to do this as well. I thought the best way would be through relays that publish the kinds of community they want to foster.
But I haven't found any that can or do publish "community preferences" as out lined in NIP 11: https://github.com/nostr-protocol/nips/blob/master/11.md#community-preferences
But I'm building https://relay.guide so that if that day comes you can search by that. Right now you can only search by features supported and paid or not.
Is it just part of a kind 3 (contacts list)?
I see the relays I follow as the content of the latest kind 3 event I was able to find.
Does that mean that on my metadata event (kind 0) I’m setting my preferred relays?
So I checked the Damus relay for an event of that kind from my pubkey and didn’t get any events with that kind. But Damus still knows my preferred relays.
I’ve tried to look through the snort and iris codebases but had a hard time parsing what they’re doing when they save an update to their relay list.
When I move from one nostr client to another and log in, how does the client know the relays I want to send and receive events from?
I'm struggling to find the event kind that's used for this (if there is one)
What would you suggest to measure how active a relay is? I just tried something to go from not sorting to sorting by something.