Btw I think is adding it in their next update along with some bug fixes. But the spec is early enough that it can probably be changed. And it's not mandatory to display it, only to be able to parse it.
After clarifying my understanding of it with nostr:nprofile1qqsgdp0taan9xwxadyc79nxl8svanu895yr8eyv0ytnss8p9tru047qpzemhxue69uhhyetvv9ujumn0wd68ytnzv9hxgqg0waehxw309ahx7um5wghx6mmdqyv8wumn8ghj7ur4vfkxjcewwfjkccted9hxwtnfdu4kpvp3, I agree.
If it isn't used when copying from client to client (it shouldn't be according to the spec, instead you should get a bitcoin:uri to share), then I don't see what purpose it has.
You won't say it over the phone, you won't type it on your limited keyboard, so it might as well not be there other than to signal that it is a BIP-353 address, and I'm sure designers will have their own ideas on how to express that more cleanly.
I'm not sold on it, but I like how it can indicate the purpose of an address in a context where that's not otherwise clear. 
Unfortunately one downside of bitcoin: URIs is that they open a single app. On iOs you can't change which one and it's always the wrong one.
* "that only supports LNURL and bolt12" should be "that only supports LNURL and NOT bolt12"
I think you should see indeed BIP-353 as a replacement for LNURL, at least for the this specific purpose of paying someone. It's backwards compatible if the sender types an email-like address, but not in all other scenarios.
It's not just about not needing https. The other difference is that once you've obtained payment info from BIP-353 you have everything you need. Once you have the bolt12 offer everything is lightning protocol native.
With LNURL there's another back and forth to request the actual invoice (IIUC). This is why you can't copy the bitcoin: URI and give it to a wallet that only supports LNURL and bolt12. But you *can* give it to a wallet that supports bolt12 and neither LNURL or BIP-353.
(2) I don't think there's any versioning. BIP21 style bitcoin: URIs are flexible enough to add new stuff later.
Reading the spec more carefully, here is what I see:
> However, wallets providing users the ability to copy their human-readable address information MUST include the â‚¿ prefix (i.e. copy it in the form â‚¿`user`@`domain`).
The spec dominates over LNURL rather than intending to be backward compatible. As soon as a
Imagine the scenario: Alice wishes to receive payment from Bob and his friend Carol. Alice sends payment information to Bob, who pays, and then passes payment info to Carol. Bob has a BIP-353 compatible wallet and the wallet prepends the â‚¿ prefix and Bob chose to copy payment info from his client. Carol has an older wallet and the payment fails because it doesn't understand how to interpret the prefix. Alice is confused because she set up both LNURL address and BIP-353 and gave a cross-compatible address to Bob.
LNURL addresses are not protected by DNSSEC, arguably making BIP-353 an upgrade and not an alternative. I think this is what the spec implies too in hindsight.
> This work is intended to extend and subsume the existing "Lightning Address" scheme ... Wallets implementing this scheme MAY fall back to existing "Lightning Address" logic if DNS resolution fails but SHOULD NOT do so after this scheme is sufficiently broadly deployed to avoid leaking sender IP address information.
The spec intends to "subsume" LNURL addresses. This is likely a good idea for security reasons, but then there is this weird migration period with teething issues as illustrated above.
Also, when it comes to copying the address, the client is expected to determine the user's intent:
> Wallets providing users the ability to "copy" their address information generally SHOULD copy the underlying URI directly in order to avoid the DNS indirection. However, wallets providing users the ability to copy their human-readable address information MUST include the â‚¿ prefix (i.e. copy it in the form â‚¿`user`@`domain`).
I have some closing thoughts about this:
1. As nostr:nprofile1qqs9pk20ctv9srrg9vr354p03v0rrgsqkpggh2u45va77zz4mu5p6ccpremhxue69uhkummnw3ez6ur4vgh8wetvd3hhyer9wghxuet59uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcppemhxue69uhkummn9ekx7mp069f2j4 mentioned, the â‚¿ symbol is hardly human typable, does this really qualify as human readable?
2. This almost appears to be a versioning flag. Parts of the spec may need to change, such as the URI format in the future. Is it worth acknowledging that this is effectively versioning and then adding more flexibility to that versioning scheme?
3. I am very curious how wallets will obey or disobey the copy/paste parts of the spec.
> Bob has a BIP-353 compatible wallet and the wallet prepends the â‚¿ prefix and Bob chose to copy payment info from his client.
Bobs wallet should copy the bitcoin: URI according to the spec, not the human readable address. Only when Alice and Bob communicate via voice should they use the human readable address. As long as she doesn't type the B symbol then Bobs LNURL fallback will work.
That's why I'm pasting it all over the place.
Our new Prime Minister - who previously headed an intelligence agency- has an excellent ability to look like a Bond villain in every shot. 
Yeah I'm not convinced either. You don't have to type it because wallets have to parse with or without it.
â‚¿calle@bolt13.org
I don't make the BIPs...
To keep it backwards compatible with LNURL. My email works with both and the B prefix is optional.
â‚¿sjors@sprovoost.nl
Coming soon to a compatible wallet near you. But there's still some confusion and incompatibilities to worked out in #bip353.
Recommend to subscribe to the HRF FF newsletter!
https://hrf.org/introducing-hrfs-financial-freedom-newsletter/
Would be nice to have an RSS feed for it as well.
nostr:note1jsyqv3zryg38n6u5k5fgddtmgljcw93ucrg5gd6l8syhdlkp92dqddlqk8
In a way this is bullish. As requested by regulators the Wasabi app no longer bundles its own coordinator, so they now have a strong incentive to make the app really paranoid about the coordinator (and vice versa). This is how your tax payer money improves Bitcoin! nostr:note1kj6vcfz2lsnw8z5hpytnzac9kjuau7ux2zg625zxsa5ym7k3gtfqd2uqv8
Stark contrast to the (barbaric) Dutch pre-trial arrest system: Alexy Pertsev was locked up for nine months because the prosecutor pretended he was a flight risk, while TDevD can await his US trial in freedom ... in Portugal! nostr:note1y68um5n30f2vu3kkuufjt4gn20h9gnfwer8nwye49fcwtgp85gxqvnwtm9