A relay service with a separate relay at any path

[alexgleason]

For example, on jitsi you could do meet.jit.si/<any-string>

I want a relay where I can do myrelay.org/<any-string> to create a temporary relay session at that path.

All data is kept in-memory and not expected to be stored for more than a few minutes or hours.

The use-case would be for bunker sessions (see #1300), but could be also useful for exchanging DMs, and all sorts of other stuff.

[mikedilger]

I wasted a whole week trying to resolve this "issue" in gossip to no avail. There is no solution. Gossip continues to be plagued and fucked up due to other relays doing this. You can do that and ruin nostr. And you would be right and we couldn't stop you. And nostr will die painfully. Users will have thousands of pages of relays to manage which are the same relay. Each path will AUTH me separately and drive me nuts. I really did try to solve this 3 different ways: (1) strip all paths and refuse to recognize them (breaks relays that only work at a particular path), (2) strip all paths only for managing relay reputation, (3) leave all the paths in place. I can't recall why (2) didn't work and I'm drinking right now so I'll have to think about it later. Cheers!

[fiatjaf]

What you didn't try was to hardcode the special cases (relay.nostr.band, filter.nostr.wine) and filter them.

[mikedilger]

It is not sustainable. It will happen again and again.

The reason people make use of URL paths is because they want to send information from the client to the relay but the protocol doesn't offer a generic way to do that. So they are abusing the address of the relay to do it. I think the solution which maintains people's ability to be creative with nostr is to expand the set of protocol verbs. I don't know what the solution is.

[mikedilger]

I give in, I'm going to do this.

[fiatjaf]

I think this is not a bad solution. It probably will not happen as often as you think it will, so manually updating hardcoded lists should work better than nothing.

If we created a way for relays to advertise they're doing this kind of thing we still would have to deal with people not respecting that, so that's not a solution either.

Ultimately I think we can streamline the hardcoding process by reading it from events published by some trusted entities. NIP-66-like.

[mikedilger]

My proximate problem was trying to configure gossip to not AUTH to filter.nostr.wine. I had to do that over and over and over and I'm still not done because I have hundreds (thousands?) of different relay records in my database, one for each distinct URL.

So I thought maybe I create RelayOrigin which represents the host and the port. But that isn't necessarily hosting a relay at path "/" it might be some other path due to "/" being a website. But maybe I could force it to have just one path, even if it wasn't the root path.

But now with what you are suggesting I think even that fails to collapse these things and manage them together. Nostr defines a relay by a URL, so separate paths are separate relays, and proliferate, and any other consideration of what a relay url means violates the nostr protocol.

So in the end I live in the nightmare of thosuands of filter.nostr.wine relays that are unmanageable for me. And they keep prompting me for AUTH and my client can never remember my answer because they are all different. And I'm tired.

[vitorpamplona]

I would even say that these two new list event kinds should be encrypted in a similar way we do with Generic Drafts: #1124 No one needs to know your proxy and broadcasting services.

[staab]

Another few kinds would probably be worthwhile. Here's the list I came up with:

• Inbox/outbox
• Indexer - read relays used for kind 0/3/10002 (e.g. purplepag.es)
• Default - fallbacks when the outbox model fails to find a working connection for a pubkey's read relay (e.g. relay.damus.io)
• Local - read+write, for this device only (should be published somehow, but hard to scope to a single device)
• Read proxy - don't use my other selections, only use these "smart" relays
• Write proxy - ditto

[vitorpamplona]

Quick and dirty NIP #1303

[nostr-wine]

I know there was some back and forth on adding something to NIP-11 as well about virtual paths. I think some type of indicator that this is a proxy relay with virtual paths might be useful. I'm not sure if #1201 is sufficient but could an indicator here help you @mikedilger?

[mikedilger]

I have not investigated deeply how these filter.nostr.wine URLs came into my system and/or why gossip connects to them. Let's not assume someone put them into a NIP-65 (but let's assume that is possible). It is probable (just a guess) that gossip chose them as the apparent best relays for a person that never advertised a NIP-65 relay list.

Looking at NIP-11 to determine that a relay should not be used as an inbox/outbox for someone sounds like it works in theory, but would need significant coding on my part. Probably any solution would need significant coding on my part. So I want to make sure we have the right solution before I dive into that.

What I did recently (giving in) was to blacklist a few relay URL substrings, and whenever the storage engine tries to write such a record it lies and says it did (but it didn't). Then I wiped all such records. Interesting, even after that, gossip still asked me to authenticate to filter.nostr.wine (!) I'll find out eventually what is going on.