Welcome🍷

Cool pubkey!

Reply to this note

Please Login to reply.

Discussion

🫶🙌

My first “followed check” with Damus after dropping all other relays came down below 1k.. so I might have lost 100 followers do you think that is possible?

This is what I had before

You can’t lose followers like you can with follows; followers are events others publish; you must not be seeing those events

I understand.. just wondering if dropping all those relays now will make about 100 people not seeing me anymore?

I see your posts but can you see mine?

Yes

🔥💜🤙

I hate that followers number because there’s so much variance in it because the client is just aggregating in real time.

With that being said, it’s theoretically possible depending on where your followers are. We don’t broadcast to nostr.band as it is an aggregator. No good way to quantify it though unfortunately. You can try adding back relays and trying it again till you find where they are “missing” from. I’m skeptical that even 100 of your followers aren’t on our broadcast relays though, usually just missing data.

I’m ok for now.. I’ll stick to these 2 relays and see what happens. I queried more than 250 relays last week and I found my notes being broadcasted as part of a pollination effect in Nostr so one way or the other I’ll be fine

There are certainly a lot of relays aggregating events from others.

I’ve found that once we get outside the top 3-5 relays it’s very high % duplicates.

#[3]​ has been rocking only nostr.wine/filter since we made it pretty successfully. Of course not what I’d recommend to everyone, but cool that it works.

I used to have a lot more paid relays but started slowly deleting them as they were slowing me down.

Please do let me know if you have any issues or suggestions. We have lots of ideas but are mostly waiting for NIP-42 (client auth).

Cool .. for now it feels good .. and I hope I can now use Nostr on mobile data :)… as before it was killing me

Yes! Big benefit to be had here. Lot less duplicates being downloaded and less event sending.

Client caching is of course another big step that’s coming eventually.

Hey one other thing… why do we need to add “another relay” for filter instead of being just Nostr.wine relay with eventually some commands in the end that can put “filter=true”, broadcast=true”?

We decided to keep them separate as they scale very differently.

Nostr.wine has regional mirror relays that stream events to each other so the databases are local and extremely fast.

Filter is at least 10x bigger than nostr.wine in terms of db size and uses considerably more resources. It’s harder for us to scale them in the same way so we kept them completely separate.