Yeah, that's what I initially thought too. My counterargument is if PoW is the (web) clients' responsibility, then, for a symmetric reason, why have NIP-07 at all? Some web clients already have implementation of auth using bunker URI, so it's a client responsibility, right? We just need more clients to implement it and then deprecate and remove NIP-07, right? Of course not. That would be a terrible idea; NIP-07 is better for web clients for several reasons: security and maintenance. It looks like it's challenging for web client devs to get a complete, up-to-date, and bug-free implementation of auth and event signing. There are just too many things to test every time. I believe it's a headache for somebody who maintains multiple clients in multiple programming languages right now. So it's great to have as simple API for web client developers as possible. To some degree this applies to NIP-13 too. Yes, it's a simpler feature; however, still very few web clients properly implemented it (if at all). Just as with the auth using bunker. I believe both features (auth using bunker and PoW mining) are not worth having in web clients at all; your NIP-07 extension is the perfect place for that. Not just that it's challenging to support the features in every single client, it's also a UX pain for end users (finding the PoW setting in every single client every time, correcting it to what's preferable and possible for the device). Same with auth UI: it's currently overloaded with buttons in Yakihonne, for instance; this is scary for normies and boring for testers. It's better to have a single thing that works really-really well, in a predictable way, and in all web clients at the same time. I believe both users and web client devs will be happy. > based on the relay info document That's what I thought too. But I found NIP-11 unusable/impractical: it requires an additional connection which degrades client performance (ideally it doesn't but browsers do that anyway) or even breaks things (iOS/Safari *might* then close a WebSocket connection because it decided there are too many connections to a single server already), and it's usually misconfigured (CORS issues, wrong or incomplete JSON data). I find that working with NIP-11 is also another testing/maintaining headache, and it just doesn't work in practice.