> less well on android, still less well for android PWAs
We've done extensive testing of nsec.app in these couple days on Android web and PWAs and it works reliably with nostr-login apps and with Nostrudel. Looks like the only problem is iOS.
This is not a normal behavior, please let me know if it happens again. I tried it now and it worked fine, not sure what the issue could be - all variants of www/plain http/https redirect to https://www.joshbrown.photos - there shouldn't be infinite refresh anywhere.
Very good overview!
nostr:naddr1qqxnzdenxyenvdesxvmrvwp4qy88wumn8ghj7mn0wvhxcmmv9upzp978pfzrv6n9xhq5tvenl9e74pklmskh4xw6vxxyp3j8qkke3cezqvzqqqr4guxug4c0
> I've opted to go with the vanilla bunker/nostrconnect flow, which allows me to display a simple interface to users.
In flotilla, I see nostrconnect:// QR-code, but not a clickable nostrconnect:// link - on mobile Amber could handle it and I wouldn't need to click on the QR code to copy-paste it to Amber. Does it make sense?
> less well on android, still less well for android PWAs
We've done extensive testing of nsec.app in these couple days on Android web and PWAs and it works reliably with nostr-login apps and with Nostrudel. Looks like the only problem is iOS.
Trusted is when you have non-zero trust rank. Usually any interaction from another trusted user is enough. The above quote is no longer accurate, an even then it was about seed nodes that had trust at the start of the calculation.
Hi, apologies, Comment wasn't supposed to be a Main CTA - it is already under each post. I removed that option from settings now, please choose something else. Posts per page seems to work on your site, maybe refresh. The pagination is automatic on that theme, posts are loaded on scrolling.
Hi, apologies, Comment wasn't supposed to be a Main CTA - it is already under each post. I removed that option from settings now, please choose something else. Posts per page seems to work on your site, maybe refresh. The pagination is automatic on that theme, posts are loaded on scrolling.
Any npub that publishes on public nostr relays is counted. If there was a spike in some space that is bridged to nostr then it could be the source of the spike.
Hmm, let me check if there's a way to fix this. I'm required to show them otherwise web push might be disabled by the browser. Looks like there's a way to "replace" existing notification - not sure if it works and if webpush will be fine with it.
Small customizations are possible with code injections. Bigger changes would make sense using a custom theme. These are Ghost themes, so if you have one or can buy one we might publish it on nostr and make it available. Don't rush buying though, because it might not be fully functional (we only support a subset of Ghost features), and tools for publishing aren't good yet (I'd have to publish it myself probably), and the theme would be publicly available to anyone.
No new themes in the pipeline atm, I published all good generic open-source Ghost themes, if you find a promising one - let me know.
nostr-login widget is a drop-in nip07 provider - you can add 1 line of code and users can sign in with extension, nsecbunker, signup locally, etc. might be a great temporary solution until you dive deeper and maybe build something custom https://github.com/nostrband/nostr-login/
Check out the new chat app!
nostr:nevent1qqsv25qz88gdhu2c5a9ykhpltychv90726ngnllel2ka96g7xewn76spr9mhxue69uhhyetvv9ujuumwdae8gtnnda3kjctv9upzqla9dawkjc4trc7dgf88trpsq2uxvhmmpkxua607nc5g6a634sv5qvzqqqqqqyck08pk
DM login is way easier for people using native apps (Damus/Amethyst), and those are the majority. But with DM-login you don't really have access to keys and can't sign/encrypt anything, so this approach only works for a limited set of apps.
Actually both nsec.app and amber work according to master nip46, they just use the same remote-signer-pubkey and user-pubkey - nothing in the spec says this is forbidden, it's a valid behavior.
Yes that part was left completely unspecified and I think the first to implement it "somehow" were Amber and Nostrudel, and then I followed with nsec.app and nostr-login. The PR you mentioned should indeed clarify this part.
Yes it looks like latest iOS doesn't require "Experimental" setting, but you still need to add nsec.app to homescreen for push to work. The problem is that this new iOS seems to not deliver the pushes properly, and I haven't figured out why yet. So basically, right now you'll just have to keep an nsec.app tab open.
Yes I think this is iOS issue, when push api was experimental you could at least get it working after enabling in settings and adding to homescreen - push messages were received instantly as expected. Now they're only delivered when you manually open the pwa. I've spent some time looking for an issue on our end and I don't see any. I'm not sure this was a deliberate choice - why graduate this from experimental and then break it? Seems more like a bug, but who knows.
New iframe-based signing coming to nsec.app and nostr-login!
Many of you have tried nsec.app and had issues. It might be slow and unreliable, because it involves talking over relays and waking up the signer using web push. iOS users had to keep nsec.app tab open to make it work.
Now check out this demo:
https://v.nostr.build/sajUBBgYejAShlcr.mp4
Basically, client app (or a library like nostr-login) can embed signer (nsec.app) as an invisible iframe and talk to it using browser APIs. Talking to your keys no longer involves relays or web push - it's instantaneous! Works perfectly fine on iOS Safari.
We're releasing the updated nostr-login on https://npub.pro,https://nostr.band and on https://primal.nostrapps.org for you to try it. If all goes well and public scrutiny doesn't kill this, we'll publish the new nostr-login on unpkg and every app using it will get a boost with nsec.app.
The NIP proposal is here: https://github.com/nostr-protocol/nips/pull/1557
I encourage web client devs to check it out, maybe this is how we take safe key access to the next level of usability on the web!
Hi yes you're right, those instructions are outdated. New iOS graduated Push API from experimental and you no longer need that setting. But you still need to add the nsec.app to homescreen, and even then we're seeing issues with reliability. So I would say for now you'll have to just need use.nsec.app tab open while working with connected apps.
I am long time fascinated by mainline DHT, and it's cool you are experimenting with it. Can we talk about browser js not being able to access DHT directly? User needs to set a custom dns server, which is quite a barrier, and is the middleman that can censor or be censored, is that right?
We could have a custom relay that could query dht for user's outbox relays and fetch requested events from there, acting as dht bridge for web apps. But then it's no different from existing indexer relays that clients hardcode for discovery.
We could also have a custom dns server resolving npubs to their outbox relay. But again users won't change their dns settings.
I go back and forth on this and still don't see what is fundamentally solved by this use of dht, at least for the web. Am I missing something?
Thanks for the input. Native apps don't really have to rely on dns like web apps and are already much less restricted and harder to censor at transport level. Those are much better censored at app store level and hence my focus on the web apps. Pkarr being cache seems like a bug, not a feature - if resolving HAS to use cache middleware to be reliable then it's less decentralised, and 10m nodes turn to 1. It looks like unless this becomes a web standard browsers won't benefit fundamentally. I thought about this much less than you did so this isn't a criticism, just thinking out loud.
Oddbean new post about login | logout
Notes by brugeman | export