well, thats what its doing.. i am still wondering what the concern is because i like the idea. its neat right? no dumb IPs, just pubkeys. i will not 'steel man' anti-auth for them because I'm still waiting to hear more reasons why. (hint: replyguy doesnt like auth either).
Discussion
replyguy could auth just that usually relays that require it do so because only a whitelist of npubs are allowed to publish events
as it is, he is already making hundreds of new keys and publishing profile metadata to go with it, on top of it all
it's quite funny though, only spams replies and profile events, that is all
i'm sure whoever is doing it has an axe to grind with the relays its selecting to spam at also
yep
i am encountering it in my work too, i see it on a firehose feeder i made that pulls events from multiple relays concurrently and processes the unique ones it sees in a window of 2048 events (uses a map to implement a uniqueness invariant)
it's very easy to detect them, you literally would just look for the e,
but it's quite funny, very often the reply events are showing up ahead of the replied to events in the feed
i'm sure that replyguy is just the tip of the iceberg of problems these free relays are having
i may have to write a filter like this at some point in the future, it won't be hard to do... hell, even just looking for the relay's own address at the end of the reply content field would flag them all
"but it's quite funny, very often the reply events are showing up ahead of the replied to events in the feed"
LOL how the heck?
subscriptions often come ahead of req results... usually a req starts a subscription first, and then does the search and then sends the results
in the meantime, the subscription is there and if someone publishes a matching event it sends that out, and the database could still be working at that point
makes sense, when you think about it... subscription results can come in without a search, but reqs always need a search
