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‑wrap inversion and edge cases like deletion, that cannot be solved in any way by real relays aside of your other points from your article. Alex left me a note saying "deletion by all" can be seen as a feature, not a bug. I think it is a huge source of instability/edge cases, especially in large, public groups where not everyone is trusted and can easily disrupt the group’s health.

As you noted, rate‑limiting and relays potentially dropping events can be harmful to Concord’s control plane. In a world with a diversity of relay implementations and cofigs, each with different settings for rate limiting, spam prevention, and so on, this could become very unreliable, assuming relays will behave homogeneously is too happy path protocol design. Put aside from the ability of relay operators to calculate heuristics over the stream provenance and users.

So, yea, I would say that Concord works over any relay for its fundamental operation, but it is probably not reliable in the long term because of all the possible relay quirks, weirdness, and edge cases that could exist. NIP‑17 is more straightforward yet still considered unreliable by many developers, so Concord could be even less reliable. Let’s see how it evolves