I’m aware you can lie on the internet. I was asking why Primal asks for this information when neither Nostr or Bitcoin protocols use email or name.
Consider adding a brief explanation on that screen describing why you are asking for this information. Lightning and Nostr don’t require or use name and email in their protocols.
Why does nostr:npub12vkcxr0luzwp8e673v29eqjhrr7p9vqq8asav85swaepclllj09sylpugg require my name and email address to create a lightning wallet? 
Very unfortunate. I worry for nostr:npub1h2qfjpnxau9k7ja9qkf50043xfpfy8j5v60xsqryef64y44puwnq28w8ch
Honestly, I don't think there is much there to be argued. nostr:npub1hea99yd4xt5tjx8jmjvpfz2g5v7nurdqw7ydwst0ww6vw520prnq6fg9v2 provided his views on the repo as an issue. dochex who wrote the spec replied with some feedback.
The main points that can't be bridged are that emended security will favor low dependency and simplicity. On a more personal preference the hard typed parts and using QRs they way they were designed.
I don't want to speak for Craig, but I think his argument for it is more in terms of being pragmatic because it's already deployed. I also think desktop folks have more resource luxury.
There is no buy in from any major vendor aside from sparrow for that BC org, if they really wanted to be a big install base org those would be BIPs
I think the drama the cloners brought over this was more for attention than anything useful. After all these are just QRs, there is bigger fish to fry. A couple specs can even coexist.
The way I read nostr:npub1hea99yd4xt5tjx8jmjvpfz2g5v7nurdqw7ydwst0ww6vw520prnq6fg9v2’s feedback on Github is that the criticisms are more than pragmatic. He has a list of drawbacks. The lack of fountain encoding and well defined type structures (for example output descriptors) are the biggest gaps between UR and BBQr.
Many wallets like Blue Wallet, Nunchuck, and Green Wallet have adopted the BC UR standard. I don’t see what BBQr brings to the table for users of animated QRs. It doesn’t appear to solve anything for the end user over BC UR. What am I missing?
I’m not saying that BC UR is perfect. I could come up with a long list of things I wish were different about the BC UR standard.
I’d love to listen to nostr:npub1qny3tkh0acurzla8x3zy4nhrjz5zd8l9sy9jys09umwng00manysew95gx interview nostr:npub1az9xj85cmxv8e9j9y80lvqp97crsqdu2fpu3srwthd99qfu9qsgstam8y8 and nostr:npub1hea99yd4xt5tjx8jmjvpfz2g5v7nurdqw7ydwst0ww6vw520prnq6fg9v2 on Citadel Dispatch about BBQr (http://BBQr.org).
Craig has years of experience implementing BC UR 2.0 into Sparrow Wallet and has actively worked to improve this standard in that time. I can think of no one better to discuss trade offs of BBQr vs UR.
I’d also like to hear from NVK why he thinks a new animated QR standard is needed. I have experience using/implementing UR and when I read the BBQr spec I wish it had some of the simplicity proposed in the BBQr spec.
I honestly think it could be a great (and drama free) conversation. IMO the three of you have mad respect for each others work. There are dozens of us who care about animated QR standards and would find this conversation thrilling. 😂
I think it's undeniable at this point that the creation of Lightning Address has made the usage of custodial Lightning solutions increase -- or at least be more prominent. We see these stats everywhere of how many of Nostr Lightning Addresses are custodial, and how services like Nodeless and Geyser only work if you give them a Lightning Address, and that probably sounds like a lament to many people who thought Lightning would be this amazing network of self-hosted nodes that everybody runs, and is indeed sad.
Well, on the other hand the Lightning Address flow is clearly an improvement -- to most people -- over the cumbersome invoice flow. Since the early days of Lightning people had been complaining about the fact that there is no way to "just send money to an address". Even though I personally liked the invoice flow much more (especially if they had structured, signatures, clear descriptions and amounts, payment proofs and so on) the fact is that most people didn't and slowly invoices were losing their meaning entirely anyway.
This improvement in the payment flow, along with the open, easy and interoperable way that Lightning Addresses work, has opened space for new use cases that maybe wouldn't have existed otherwise -- like the services mentioned above, and others. So we can't really say this was all a bad thing.
We also shouldn't say it was a bad thing to have Lightning Addresses being invented at all, because if they hadn't been invented like they were, there is a high probably they would have been invented in other forms, probably much worse, that would involve private deals and proprietary integrations with ad-hoc APIs, SDKs and JavaScript widget buttons with iframes. I even remember some of these things starting to happen at the time Lightning Address was created, and we have more evidence of these things even after Lightning Address, like some "partnerships" here and there and the "UMA" protocol. So maybe Lightning Address was just the best possible protocol at the best time, and all its problems are not really its problems, but symptons of the problems of the Lightning Network (or maybe you wouldn't call these "problems", just natural properties, but doesn't matter).
The saddest realization of all this process, for me, was that Lightning payments are mostly used for tipping and not for commerce as I thought they would in the beginning (hence my love for the invoice flow). Specifically, LNURL-pay and its cool hidden features that went mostly unsupported, were all designed with the goal of enabling new use cases for commerce [in the real life](https://github.com/lnurl/awesome-lnurl), outside the web, and Lightning Addresses would have tied nicely into that vision too -- but that was all definitely an irredeemable failure.
I thought I had more things to say about this, but either I didn't or I forgot. The end.
Does BOLT 12 offers eventually solve/replace LNURLPay in your opinion?
Haha, no problem! I’m getting 404 now. So yea, GitHub is down.
Hey nostr:npub17tyke9lkgxd98ruyeul6wt3pj3s9uxzgp9hxu5tsenjmweue6sqq4y3mgl the github repo is going to 404 pages? Did you guys get nuked? Or is github just broken.
Working for me now. You had me worried.
Our first ever potato harvest 
My neighbor in his 80’s, a Vietnam veteran, was forced to leave his house last year and move into a memory care facility (the right choice, still sad). His house was sold and they ripped out all his wife’s favorite rose bushes and replaced them with empty beds of mulch. This fall, one rose survived and bloomed. This Queen Elizabeth rose was his wife’s favorite. 
Seems like a big acorn year. I’ve seen more fall this year than ever before.
I don’t know what makes growing a vegetable organic, but we used dirt, water and sun to make these 🥕 grow. Some mushroom compost last year maybe
Successfully grew 🥕 in the garden this year! 
High praise! Thank you for your contribution to this awesome FOSS project 🙏 nostr:note184zqe675d59tccja9nzmjf29gyh9zgfek53m0ac7m9r6dde5e4psp4z6dg
Our sister #node 21Cyber has just opened a 5m sat channel to nostr:npub1rfd0hxdzcze6pzj29thuz34vur57wm9quje7w3edxjgusq6m47csnl7wrt
Welcome to the family!
🤝⚡️
a380cb93eb852254863718a9c000be9ec30cee14a78fc0ec90708308c17c1b8a seedsigner_os.0.7.0.pi0.img
fe0601e6da97c7711093b67a7102f8108f2bfb8a2478fd94fa9d3edea5adfb64 seedsigner_os.0.7.0.pi02w.img
65be9209527ba03efe8093099dae8ec65725c90a758bc98678b9da31639637d7 seedsigner_os.0.7.0.pi2.img
d574c1326d07e18b550e2f65e36a4678b05db882adb5cb8f8732ff8d75d59809 seedsigner_os.0.7.0.pi4.img
Ticket purchased🔥 nostr:note1eyfky4gczfr4d3gwhkd92nr027yt4t3huh39mjygvgu9ye8gcddqynu5t8
The wife and I have been splitting this beer each night after the kids go to sleep. This 4 pack has been a most delicious summer dessert #beer! 