yep
Discussion
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