I think we’ve waited long enough on this one. I’ll be rolling this out shortly.

Please note this means 🍷 filter.nostr.wine will no longer work on Primal or any other client that does not support NIP-42. nostr:note1mfuywzsgeamkezufp4ys4sdv03zg8fge06ka9stwu6ne9fper5nqwrddx4

Reply to this note

Please Login to reply.

Discussion

Update: filter(.)nostr(.)wine will no longer work on Primal or any other client that does not support NIP-42

#cybersecgirl #nostrwine

nostr:nevent1qqs8fltwnvn9d6arz8vyyt7k6wy90sn75ysvkmt63le4sv3zlu5t8uspr3mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmqzyq7cg2h7e40zj0egke38jvmsfglm3ns4825367g2ky0k5afdgjjz6qcyqqqqqqg328u9p

What is NIP-42 AUTH?

If I understood what I read.

This is an authentication layer for the websocket subscription filter?

So for example, instead of giving everyone access to pull DMs, you only serve the DMs to their owners after they prove they are the owners.

That’s nice. Any downsides to this?

That’s exactly it! We already use this on nostr.wine to protect your DM metadata.

When you try to request a DM from nostr.wine, we send an AUTH challenge through the socket. Your client signs and returns the challenge so that we know who is making the request. We user this information to only allow the sender or receiver to request DMs.

There main downside is decreased privacy from the relay operator as it becomes easier to associate REQs with a pubkey (though it can be done without AUTH anyway).

Thanks for the transparent response.

We hate to break interoperability anywhere, but the abuse has simply gotten too bad to not enforce AUTH.

Private-to-read relays are an important part of the future nostr ecosystem and lack of/poor client authentication support is holding this back.

😥