One sentence in NIP-01 that helps resolves a huge issue with relay connection management.

[dskvr]

The one sentence:

Relays MUST only accept connections to a single endpoint when additional path segments do not influence its behavior.

---

Rationale

wss://relay.damus.io/<insert_any_random_string> is the exact same relay as wss://relay.damus.io/.

Facts:

• wss://relay.damus.io/<insert_any_random_string> establishes a relay connection and conforms to the protocol
• The additional path segment has no impact on relay behavior
• The path segment appears to be completely ignored.
• This same behavior is also true for the majority of relays online (1000+), not just damus.io.

Problem:
The ambiguity of relay URLs is a real problem that has always plagued clients. It’s difficult to track and even harder to mitigate. It also creates a tangible attack surface: clients may end up in situations where a large portion of their relay connections actually resolve to just a handful of relays.

---

String-based de-duplication

Clients all handle this differently, while most either ignore the issue or approach it naively. Of the solutions I’ve seen, I have yet to see one that is even remotely correct on a technical level.

1. De-duplicating by hostname is incorrect. There are valid cases for path-segmented relays (e.g. wss://lang.relays.land or relays with /outbox and /inbox path segments).
2. De-duplicating by NIP-11 alone is both insufficient and slow. Many relays don’t implement it since it’s voluntary.
3. Treating the raw string as the source of truth is flawed. There are 10k+ “maybe relay” strings in NIP-65 events alone, the vast majority of which are offline, typos, garbage or duplicates.

---

NIP-11 de-duplication

Right now, ensuring a client isn’t connecting to the same relay more times than it thinks requires building a full manifest of all intended relay connections, fetching each relay’s NIP-11 document, and attempting to de-duplicate based on that.

Problems with NIP-11 de-duplication

1. Not every relay implements NIP-11, it’s voluntary.
2. Operators often reuse the same NIP-11 across all path segments, even when different URLs or behaviors exist at those segments.
3. Some relays dynamically inject an id property that is just the request URL, leading to false positives during de-duplication.

---

What this ammendment does not restrict:

1. Relays that intentionally use path segments for dynamic functionality, such as /inbox, /outbox, /npub1...., /<hex_pubkey>

---

Important Note:

• This PR could be made more effective by suggesting that dynamic path segments produce unique NIP-11 documents. I’ve intentionally left that out, as referencing NIP-11 from NIP-01 feels awkward.
• This entire problem could be entirely erased with pubkey relays, but is a much larger discussion with breaking changes.

[fiatjaf]

I agree with you but I don't think anyone will read this. I don't think anyone ever intended to accept connections to multiple paths, they do it by ommission because libraries do that automatically.

My own relay, for example, I don't even know if it works like this or not.

I think we would gain more by having strfry reject any subpath connections by default.