NIP-67: "auth" hint

[fiatjaf]

A follow-up to #2317.
Also relevant to #2156.

[Semisol]

I think we should clarify if the AUTH challenge should be re-sent. Maybe?

I had the idea to extend AUTH with a "reason" parameter that could be shown to the user (cc @hzrd149) and I guess an AUTH just before the EOSE could provide a more request-aware message.

[pablof7z]

This would introduce a privacy leak where you're able to see the presence of events the attacker shouldn't have access to. I don't think this addition is worth the trouble.

[fiatjaf]

This would introduce a privacy leak where you're able to see the presence of events the attacker shouldn't have access to. I don't think this addition is worth the trouble.

How do you solve the problem of the client knowing when to AUTH then? The only alternative is performing AUTH to every relay, which is worse for privacy.

Relays aren't required to send this hint, by the way, and it doesn't mean that there will necessarily be any event hidden under auth. It is just a hint. In many cases the author/relay actually do want to signal the presence of secret content, like paywalled events.

[pablof7z]

I might be missing something but this sounds like a non-problem to me; if I have a relationship with a relay with premium content like premium.relay.com I'll auth when I connect and get all content that's available to me, if I refuse to auth I don't get the premium content. Even with the proposal in this PR the client would still hopefully ask the user if they want to auth with the relay and not follow blindly an EOSE with an auth marker

[fiatjaf]

The simplest situation I have in mind is: I'm following Bob and Bob publishes premium content to his outbox relay, but also non-premium content. If I am a Bob premium subscriber I get the premium content, otherwise I don't.

How will the relay discern between someone who pays for Bob's premium content and someone that doesn't?

The big magic happens when I get Bob's premium content automatically in my feed, without having to somehow ask some special relay for Bob's premium content specifically (which could work too, but would require a lot of special UI in order to work, while the flow above requires basically none).

[pablof7z]

The simplest situation I have in mind is: I'm following Bob and Bob publishes premium content to his outbox relay, but also non-premium content. If I am a Bob premium subscriber I get the premium content, otherwise I don't.

How will the relay discern between someone who pays for Bob's premium content and someone that doesn't?

The big magic happens when I get Bob's premium content automatically in my feed, without having to somehow ask some special relay for Bob's premium content specifically (which could work too, but would require a lot of special UI in order to work, while the flow above requires basically none).

Yeah, I understand, but the same thing stands right? Just because your client sees an EOSE with the auth marker it shouldn't auto auth because then you're just moving malicious relays attack vector to the EOSE.

If bob's relays has premium content it should offer the client an auth, the client asks the user if they want to identify themselves to the relay and that's it.

The only point where I would see the EOSE auth being useful is if bob publishes his kind:1s of shitposting in that relay and he never publishes a kind:1 that's premium and only publishes kind:30023 or whatever as premium, but I see it as so niche (and most likely bob would keep his premium posts on premium.bob.xyz and be able to also publish his premium kind:1s there.

[fiatjaf]

I don't know, some clients could just auth, others could prompt the user.

The big difference to me is that many relays will just always send an AUTH on connection init, but with this it's more fine-grained. You can ignore these initial AUTHs and only prompt/auth when you get an EOSE with an "auth" hint (or when you get a CLOSED/OK with an "auth-required:").

Also the initial AUTH is very unreliable in practice, because you never know if it will come or when, and you have to wait for it before firing all your REQs, and that is a very broken flow in the code logic. Because of that I always wrote code that waited for an "auth-required:" message on CLOSED/OK, that works great and is reliable, but the "I sent you some stuff but there may be more if you auth" flow is not supported currently, and this PR fixes that in a simple and effective way.

[pablof7z]

I don't know, some clients could just auth, others could prompt the user.

The big difference to me is that many relays will just always send an AUTH on connection init, but with this it's more fine-grained. You can ignore these initial AUTHs and only prompt/auth when you get an EOSE with an "auth" hint (or when you get a CLOSED/OK with an "auth-required:").

Also the initial AUTH is very unreliable in practice, because you never know if it will come or when, and you have to wait for it before firing all your REQs, and that is a very broken flow in the code logic. Because of that I always wrote code that waited for an "auth-required:" message on CLOSED/OK, that works great and is reliable, but the "I sent you some stuff but there may be more if you auth" flow is not supported currently, and this PR fixes that in a simple and effective way.

Yeah, the auth flow is always finicky, I also have a bunch of code that feels hacky to deal with it. Maybe we could have like a NIP-98 sent as a header when the client wants to auto-auth or something, but ok, I'm persuaded by this, perhaps would be worth flagging on the nip that relay operators should be aware that an auth required on EOSE could be used to enumerate existence of events, OTOH I wouldn't know as a relay operator what to do with that to curtail/prevent that either.

[Semisol]

Maybe we could have like a NIP-98 sent as a header when the client wants to auto-auth or something

Something like #571?

OTOH I wouldn't know as a relay operator what to do with that to curtail/prevent that either.

To prevent enumeration I am planning to send "auth" on any query that could match a protected event kind.

[fiatjaf]

To prevent enumeration I am planning to send "auth" on any query that could match a protected event kind.

If relays are going to do this then this change will be very damaging, it will basically make all clients do all queries twice all the time.

What is this "enumeration" you're talking about? Why is it so bad?

As I was saying, in the cases I have in mind the event authors want viewers to know there are hidden events.

Now I'm turning against this proposal. Would be better to have one in which the relay actually sends the event ids of the events that are hidden from the query, or something like that.

[Semisol]

If relays are going to do this then this change will be very damaging, it will basically make all clients do all queries twice all the time.

Well, it will be only sent on a very small subset of queries, such as specifying private event kinds, or the global filter {}, etc.

What is this "enumeration" you're talking about? Why is it so bad?

Someone can do binary search with {"#p": ["pubkey"]} and since / until ranges to find the timestamps of all events that tag them, for example, including private ones.

As I was saying, in the cases I have in mind the event authors want viewers to know there are hidden events.

Well, this would be different from what auth is. auth specifies that there may be events hidden from you.

On Nostr.land for example, I would have no way to 100% exactly specify this anyway, as the query router will not query the inbox relay for example if you are unauthed. So I would send such a message if you ask for content that could be hosted in the inbox.