nostr:nprofile1qqsyvrp9u6p0mfur9dfdru3d853tx9mdjuhkphxuxgfwmryja7zsvhqpzamhxue69uhhv6t5daezumn0wd68yvfwvdhk6tcpz9mhxue69uhkummnw3ezuamfdejj7qgwwaehxw309ahx7uewd3hkctcscpyug am I only spamming my Citrine local relay since I have that defined? And I assume people that don't define it spam all of their relays?
Discussion
All of the write relays, yes. I am adding more popups to help people setup their relays correctly.
The event is replaceable, though. It shouldn't take extra space in a regular relay that deletes old replaceables as they should. Rate limiting is not a good idea for any replaceable.
Most of the work is on fixing the Outbox relay list other clients have created based on the kind 3 list. The Outbox list should have 3 relays max. Many people have 20 relays over there, which is terrible.
Thank you sir. This is all great information.
Re: 20 relays. I have about that many, because I don't know if I remove them if they'll also remove them from my profile or if it's Amethyst client specific.
Interesting. Removing them from Outbox/Inbox sections won't remove them from your profile. It only affects the Outbox clients. So, you can just choose the ones you trully trust for Home and Inbox.
The General Relays list is the kind 3 for the old clients out there. That list should follow the old model.
Amethyst uses the General Relay section to let you authorize connecting to relays to download posts. It will recommend adding based on the inbox/outbox list of your follows.
Again this is all good information. Thanks. It's hard to keep track how specific clients function and evolve over time. If I can't do it, a new Nostrich isn't going to either.
Replaceable doesn’t always mean it will use the same space on disk, the nature of lmdb and append-only dbs like nostrdb means that if we didn’t have rate limiting on replaceable events then it would be an easy way to fill a disk, especially since nostrdb treats replaceable events as a version log.
You should have a policy to delete old versions after a threshold. Keeping them all will not be sustainable on most relays. And most relays already delete them anyway, so it wouldn't be a surprise to users if you do delete them as well.
deleting them doesn’t clear up space, this is just how lmdb and strfry works
That seems like a massive problem, then. Regardless of drafts.
The changes to contact lists alone will fill it up very quickly. Especially now that we are incentivizing more adds and removes from the follow list to avoid getting it so big.
This is why rate limiting is so important, people can fill the disk quickly otherwise. I can always nuke the relay when it gets too big, so it’s not a big deal.
writing a GC for event and enabling the relay operator to define a storage limit was the first thing i did for replicatr... gonna be nice when i finally get it production ready (you can use it but i promise you it will burn your CPU after 24 hours)
you need a garbage collector :)
Standard way to do it is a compact step which rebuilds the DB skipping all the deleted stuff. I still need to make this a feature in nostrdb
Looks like Bitcoin found a use finally
Grrr replied to the wrong note?? What is going on.
it's already available in badger, and it's faster than stink... with batching i wrote a thing that could measure utilization in 8 seconds on 15gb of event data (it was only traversing keys, but that is how you get it to work)
Not your relay, not your notes 😝
I’m glad for all free relays that are broadcasting my notes, thanks to all of you #RelayRunners 🔥
One day I’ll be able to make my own, but for now I’ll need to learn perfectly node management with bitcoin mainchain in depth and then I can focus on Nostr relay, it seems more complicated to me.
Btw idk why but I can’t zap nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s from my Alby Hub connected node 😣