Yeah, that's what I initially thought too. My counterargumen...

codonaft

npub1alptdev5srcw2hxg03567p4k6xs3lgj7f6545suc0rzp0xw98svse7rg94

hex

7dca3c1893a3a37516583cc77402400d8350769d156b67163d17bda2884329ca

nevent

nevent1qqs8mj3urzf68gm4zevre3m5qfqqmq6sw6w326m8zc7300dz3ppjnjsprpmhxue69uhhyetvv9ujuem4d36kwatvw5hx6mm9qgswls4kuk2gpu89tny8c6d0q6mdrggl5f0ya226gwv833qhn8zncxgskp2xv

Kind-1 (TextNote)

2026-02-27T01:38:39Z

↳ Reply to Event not found

43b65588c8c312ec98af60bb1c166eda239e3f7cc2841db1ae13253d7c666b72...

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.

Raw JSON

{
  "kind": 1,
  "id": "7dca3c1893a3a37516583cc77402400d8350769d156b67163d17bda2884329ca",
  "pubkey": "efc2b6e59480f0e55cc87c69af06b6d1a11fa25e4ea95a439878c41799c53c19",
  "created_at": 1772156319,
  "tags": [
    [
      "e",
      "910b731ac550c27974b614023213a2baffae45ca18eede890979c0b73d1e867f",
      "wss://nos.lol",
      "root",
      "b5127a08cf33616274800a4387881a9f98e04b9c37116e92de5250498635c422"
    ],
    [
      "e",
      "43b65588c8c312ec98af60bb1c166eda239e3f7cc2841db1ae13253d7c666b72",
      "wss://relay.primal.net",
      "reply",
      "b5127a08cf33616274800a4387881a9f98e04b9c37116e92de5250498635c422"
    ],
    [
      "p",
      "b5127a08cf33616274800a4387881a9f98e04b9c37116e92de5250498635c422",
      "wss://relay.primal.net"
    ],
    [
      "client",
      "nosotros",
      "31990:c6603b0f1ccfec625d9c08b753e4f774eaf7d1cf2769223125b5fd4da728019e:1728437063755"
    ]
  ],
  "content": "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.\n\nIt 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.\n\nTo 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.\n\nI 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.\n\nIt'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.\n\n\u003e based on the relay info document\n\nThat'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.",
  "sig": "af0905221332a35fcf822a920a91884e1cd097a18a111bd7d2ce879dfaf33350838fac3f7d9345e0dfdaa92ee5ba83a447bbc834ae70b1b295e560245f8d5613"
}