Also check out how the newer version of nostr-login works on nostr.band - there is a N banner on the right screen border.
If you support nip07 you could just drop this script to your html head and it should work: https://www.unpkg.com/nostr-login@latest/dist/unpkg.js 

 And with 'Sign in with extension' button if one is present. 

 Try nsec.app, it's a bunker in your browser. 

 Not yet 😟 
@Stuart Bowman any plans for nip46 support? 

 Nsec.app already has some baby-steps shared access features released in the last couple of weeks. More coming very soon. Coracle and Nostrudel work fine with nsec.app as far as I know. 

 As far as I understand from a quick investigation, your ln wallet publishes invalid zap events. Most clients don't really verify anything, but nostr.band does, because it tries to count real payments. 

> SHA256(description) MUST match the description hash in the bolt11 invoice.

This nip57 rule is broken in 9735 events published by your wallet (minibits I'm guessing): 

 I don't think there is anything more reliable, _especially_ when it comes to active user charts, but I'm happy to be proven wrong.  

 I don't remember about primal. Some numbers are more reliable, some less, our stats are the best estimate I have seen. 

 Also many numbers under npubs/events are probabilistic counters, they are never accurate, but reliably around the actual numbers. Overall stats are different and much more accurate. 

 Because of our broken code, or probabilistic counting, or decentralized nature of nostr where we can't be sure we have all the data 

 I am not aware of other stats 

 Outbox is already used to discover new relays to crawl. No there will never be accurate data, just like there can never be accurate data about the web - only good estimates. 

 Some extensions work on mobile on some browsers. You can also try nsec.app 

 Insane! My kid came up three times to tell how freaking good the music is! 

 Turns out he does! 

 Which browser and OS are you using? 

 There is a list of apps supporting nip46 on nsec.app homepage. 

 Does nsec.app usage break the satcom? 

 You could decrypt them once and re-encrypt with your local cache-key, and then only use that local key for cache data. That's a lot of work, but it's not impossible. 

 You can do batching right now, just send 100 nip46 requests without waiting for the replies and you've got the batch - you pay 1 RTT per batch. We discussed this once on github, IIRC nsec.app was able to do ~50 decrypts per second. Unlikely to get much faster, 90% of time is spent verifying signatures of nip46 requests etc.  

 Ok now that I'm thinking about it, the signature verification overhead could go away with batching, maybe it could make sense.  

 Could you please try again now, looks like Coracle listing was updated. I've just tried it, seems to work. 

 Awesome! That's not me, I guess @hodlbod updated the listing to fix it. 

 You can try nsec.app, it uses the same protocol as nsecbunker but you don't have to run it on your server - it stores keys in your browser. 

 Nsec.app homepage has a list of clients and short video-guides at the bottom of it. 

 As I said, it's fascinating. Our CEO should fire us all. 

 I understand the penalty of the initial load of all DMs, but you're probably writing them into the local cache so further operation shouldn't be costly?  

 How about generating a 'cache key', encrypting it using nip04, storing it locally, encrypting locally cached stuff with it, and then when you reload - decrypting only that key and then decrypting all the cached stuff?  

 The use case is that I won't paste nsec to blowater, that I can have restricted permissions, etc.  And the complexity is probably worth it in terms of performance bcs you can use native encryption instead of nip04 

 Oh sorry, I forgot nip04 uses browser-native aes 

 Try with nsec.app 

 Try embed.nostr.band 

 Is it? Please tell me more 

 Thanks for the numerous report, heh. Will look into the issue. 

 There is a list of clients on nsec.app homepage. 

 One day someone asks to export their keys from your app, giving them ncryptsec would be safer than exporting in plaintext. 

 I just use a strfry with custom write policy that only accepts 24133.  

 Note though that strfry may not delete ephemeral events (it's some known issue and I didn't investigate deeper), so use 'since' filter to cut the old events when requesting 24133 from there. 

 Let me know if you have any feedback if you try nsec.app 

 Awesome! 

 Exactly. Both are fake. 

 Most of these numbers are useless 

 Nip46 signer (which is what nsecbunker is) does not need a tunnel. it does not need a public IP, does not need a reverse proxy.

Nip46 client sends requests to some public relay, and signer reads those events from public relay, signs, and sends replies to the same relay, which client reads. Nsec.app runs this nip46 signer in your browser service worker.  

 Any relay that supports ephemeral events.  

 Yes that's simpler, but that's not what nsecbunker/nip46 are. 

 No, they don't have to do any special forwarding - peers just use REQ to subscribe to the requests/replies they need. Nip46 describes it pretty well. 

 You may or may not be right, my point is that nsecbunker doesn't need any tunnels and can work on your phone. 

 Since you have nip07 support you can just drop in the nostr-login library to add nip46 support. 

 Nsec.app now supports Nip44, and it works with Coracle, you can try it instead of the extension. 

 Our relay may hide the absence of gossip implementation in clients, so I wonder if I should turn the relay off to support this small relays movement. Although at this point with rebroadcasting etc it might not make much of a difference. 

 Could you please also propagate this to ngine and Badges, please? Btw when nip46 on Heya? 

 Awesome! Thanks a lot! 

 Ping me next time you wish to avoid something nip46-ish. 

 Thank you! 

 Tag me next time, I will check your sanity 😉  

 There is a guild on the nsec.app homepage. 

 Which phone and browser?