Inbox doesn’t explicitly prohibit REQs for kind 1, but they have to supply a relevant tag. It blocks them on write though so they will always return empty.
I will fix this so those return blocked instead.
Discussion
Yes, I meant inbox, I confused myself. Your explanation makes sense too. On multi-user auth, I guess returning auth-required could makes sense if the alternative would be restricted. I'm just not sure what action the client would take in that case without being very coupled to an interpretation of the relay's policy.
I added a new message now for when you try to REQ a kind we do not store on inbox. It should used the “blocked” prefix. Thank you for pointing this out to me.
And yes - I think that is a challenge for sure. I think the main proposal is based on Vitor wanting to have 1 socket connection for multiple logged in accounts on Amethyst. He can AUTH with all of the logged in accounts when they prompt so that he can access privileged events for all those pubkeys. It’s a bit messy on the client side but it was easy to implement on our end so we went ahead and did it. I assume the proposal will change 10 more times in the next year and our implementation will break soon.
I think this stuff is pretty stable. It's the reply stuff that's a disaster area