Damus
Gzuuus · 4d
Well, I’m still trying to wrap my head around the protocol, and my analysis also points to a relay specialization for running Concord groups. Concord introduces special features, such as the gift‑...
Alex Gleason profile picture
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 the protocol level (this is also true for NIP-17, hence the inversion).

v2 requires you to at least be a member of the group in order to have any possibility to disrupt it, which I think is the far better option. Now we harden for that case, which requires a great deal less centralization.

Hardening for the NIP-17 case requires exclusive relay centralization, in the sense that no "spammy relay" can be in the relay list at all. In the Concord case it's considered "safe" to have any relay in the list, and you want at least one or two to prevent giftwrap deletion by author - which by the way is already in the spirit of NIP-17.

tl;dr preventing spam in the NIP-17 route requires total relay centralization of supposed "spam-free relays" (does such a thing even exist?). Preventing mass deletions in the Concord route depends on having at least 1 special relay in the list.
2
Alex Gleason · 4d
Also, NIP-17 makes it clear that giftwraps are owned by the recipient, not the sender, which is why I think it's already in the spirit to prevent deletion by the sender. 1 person should own an event. For giftwraps the owner is the recipient, not the sender.
cloud fodder · 4d
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 b...