Alex Gleason
· 3d
Mostly fair assessment. We chose the better of 2 bad options. Concord v1 tagged the community instead of being authored by it, making it possible for any outsider to spam/DoS every Concord group on th...
NIP17 has basically no available methods for prevention of spam by relays.. Other than, expiry. It's all client side.. The interesting thing is that a full setup for protecting giftwraps, or offering deletes was in direct conflict with concord (eg, nobody can auth to receive their p-tagged events because they're ephemeral). Somewhere in concord it mentions that the traffic can "hide" alongside all other giftwraps, but relays that already protected DMs, have to turn that off or they can't serve concord groups.
I went and double/triple checked to make sure that was the case, correct me if I'm wrong but it does seem to be how this would work. (It's all described in the various nips). That's why I added three-way toggle option for newlay relay, to support concord vs. nip17 protection vs. wide open (previously it had just wide open which is probably a standard relay setup anyway).
I was a fan of protecting DMs for a long time with AUTH, but, there was a lot of pushback from the non-AUTHer crew and limited choices to run it so I can see why 'standard' relay does not likely include protecting DM downloading from 3rd parties. A 'standard' relay, could be taken to mean, relay as a free commodity basically, relay operator has to deal with spam or their disk and network will fill, but has no ability to do so other than drowning in events and expiring them. Unless you also start IP blocking, and I am somewhat against that method because it leads to all VPNs and TOR being choked out.