i did not even configured my bostr to connect nor even touch your relay. See https://bostr.lecturify.net

Reply to this note

Please Login to reply.

Discussion

They got there somehow. I don't know how but my original database had valid signed messages from your Pubkey. So, sorry to bug you. It wasn't my intention, for all I knew, you were using it.

as far as i could tell, there are some random blastr instance (it's a different project, not mine) running and bouncing notes from other relay to random relays.

they also reach to my end in nostr.lecturify.net and still was today.

as someone like you that just getting started, i could agree that this is annoying yet confusing as heck.

so please pardon my last messages.

Now that you've cooled off a bit, changing subject to your project (which I actually admire)

Have you seen NIP66? Or considered using nostr.watch to populate your blaster list? I want to add a configurable blaster to grain and I'm not sure which direction I want to go. I might could do something with bostr2. Grain is written in Go as well.

NIP-66 requires another relay to be able to retrieve informations regarding availability of an relays, or publishing your relay availability.

As it needs another relay to power it up, It was really out of my goal in bostr2.

The reason for that is because an unmanageable list of relays that just keeps adding in memory and never shrunk in memory gives an even bigger consequences on server side. Even it's possible to automatically shrunk it down, The reliability on obtaining information is completely unguaranteed.

This was similar to my thoughts on the nip...

It's useful when you connected to other relays.

So far i could tell this is only good for clients.