RelayUrl path and query issues #735

New issue

Closed

opened 2024-04-25 08:49:44 +12:00 by mikedilger · 3 comments

mikedilger commented

2024-04-25 08:49:44 +12:00

(Migrated from github.com)

Gossip currently treats every distinct RelayURL as a distinct relay. That means the following are seen as 3 different relays:

wss://filter.nostr.wine/npub1chakany8dcz93clv4xgcudcvhnfhdyqutprq2yh72daydevv8zasmuhf02?broadcast=true
wss://filter.nostr.wine/npub1t0nyg64g5vwprva52wlcmt7fkdr07v5dr7s35raq9g0xgc0k4xcsedjgqv?broadcast=true
wss://filter.nostr.wine/npub1t0nyg64g5vwprva52wlcmt7fkdr07v5dr7s35raq9g0xgc0k4xcsedjgqv

When gossip posts an event it may post it to all 3 of these relay urls (or in my case, 12, but I didn't want to clutter this issue).
When gossip fetches events it may connect to many of these relay urls.

Gossip cannot presume what the path or query mean. The meaning may be different across different relays.

Here are some problems with the current state of affairs:

Too many connections to the very same host/relay, giving "429 Too Many Requests"
Fetching many times from the same host/relay over multiple websocket connections
Posting the same event many times to the same host/relay
It is very difficult for users to manage hundreds of variations of the same relay in the relay pages. I want to set rank=0, but there are far too many pages I have to do this on, and if a new npub path comes up it won't apply to those.

ALTERNATIVE 1: Ignore path and query.

If we ignored path and query, then filter.nostr.wine would be seen as a single relay and the problems above would go away. However we would have new problems:

The relay's special behavior as defined by the path+query would no longer be engaged. That behavior might be critical for the relay to operate as somebody's nip-65 relay. After all, there must be a reason that a path and/or query were put there in the first place.

filter.nostr.wine is just an example.

I don't know what the right solution is, and I'm not working on fixing this until I've worked out what the right solution is.

Gossip currently treats every distinct RelayURL as a distinct relay. That means the following are seen as 3 different relays: ``` wss://filter.nostr.wine/npub1chakany8dcz93clv4xgcudcvhnfhdyqutprq2yh72daydevv8zasmuhf02?broadcast=true wss://filter.nostr.wine/npub1t0nyg64g5vwprva52wlcmt7fkdr07v5dr7s35raq9g0xgc0k4xcsedjgqv?broadcast=true wss://filter.nostr.wine/npub1t0nyg64g5vwprva52wlcmt7fkdr07v5dr7s35raq9g0xgc0k4xcsedjgqv ``` When gossip posts an event it may post it to all 3 of these relay urls (or in my case, 12, but I didn't want to clutter this issue). When gossip fetches events it may connect to many of these relay urls. Gossip cannot presume what the path or query *mean*. The meaning may be different across different relays. Here are some problems with the current state of affairs: - Too many connections to the very same host/relay, giving "429 Too Many Requests" - Fetching many times from the same host/relay over multiple websocket connections - Posting the same event many times to the same host/relay - It is very difficult for users to manage hundreds of variations of the same relay in the relay pages. I want to set rank=0, but there are far too many pages I have to do this on, and if a new npub path comes up it won't apply to those. ALTERNATIVE 1: Ignore path and query. If we ignored path and query, then filter.nostr.wine would be seen as a single relay and the problems above would go away. However we would have new problems: - The relay's special behavior as defined by the path+query would no longer be engaged. That behavior might be critical for the relay to operate as somebody's nip-65 relay. After all, there must be a reason that a path and/or query were put there in the first place. filter.nostr.wine is just an example. I don't know what the right solution is, and I'm not working on fixing this until I've worked out what the right solution is.

mikedilger commented

2024-04-25 09:09:28 +12:00

(Migrated from github.com)

https://github.com/nostr-protocol/nips/issues/1198