Nostr Web Client

Ahhh I see whats happening here. This was updated recently to support multi-auth per connection. If you try to make a REQ that another user could be authorized to make, it will tell you auth-required instead of restricted to give you the opportunity to AUTH again with an additional pubkey.

Does that make sense with what you saw?

hodlbod 7mo ago

Interesting. It does explain what I saw, but I'm not sure it's accurate in this case (because filter will never serve kind 1s). It's also not very helpful, since how can the user know which user they should auth as? It seems like it would be entirely up to the client to choose which keys to use. See this recent PR for how multi-user auth has been proposed: https://github.com/nostr-protocol/nips/pull/1881/files

> I’m not sure I understand the second part. What do you mean your recent messages coming from inbox? filter.nostr.wine is the aggregator/broadcaster, not inbox.

I assumed since I had access to filter I would have access to inbox and it would aggregate DMs? But only old messages are being returned from inbox. That seems potentially correct, I just wasn't sure.

Reply to this note

Please Login to reply.

Discussion

Mazin 7mo ago

Filter does return kind 1s. I assume you mean inbox in which case I’ll take another look at that response.

Inbox does not communicate with the aggregator in any way so it will only have messages from when you previously used it (I think I gave you access back in 2023).

I added multi user auth exclusively as a result of that PR. I don’t understand what is wrong though. The client always chooses which key to auth from, no?

Mazin 7mo ago

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.

hodlbod 7mo ago

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.

Mazin 7mo ago

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.

hodlbod 7mo ago

I think this stuff is pretty stable. It's the reply stuff that's a disaster area