Using Nostr has some clear extra features that HTTP doesn't have (while at the same time being worse than HTTP for some use cases), so if you just make HTTP-over-Nostr you'll just get the worst of both worlds, while if you do something that relies on Nostr properly you can get much better things.
Also this poses an opportunity for us to merge lnurl-withdraw and lnurl-pay into the same thing.
For example, the entire "withdraw from a service" flow could be done differently by having the service notify the user that their balance has updated instead of waiting for the user to scan a thing.
Both lnurl-withdraw and lnurl-pay and also "zaps" could be condensed into a single "payment offer" kind:5000 event that is sent to the relays specified by the receiver. Then whenever the receiver is online and wants to actually receive that payment they can send an event back referencing the ids of the payment offers. The actual lightning invoice doesn't have to have a description hash since the Nostr event provides the necessary cryptographic commitments (although no one is interested in that).
For a service (or a person) that wants to sell stuff with lnurl or make lnurls that have stated purposes (i.e. they're not just donations or arbitrary payments, but they're actually tied to the delivery of some good or service) they can publish Nostr "sell offer" kind:30010 events with some metadata that can be edited but also have a static "address" and they can share the address of these events directly with the potential payers (via QR-Code and whatnot). The payer then just makes a payment offer (as in the previous paragraph) referencing this.
The entire flow can happen asynchronously over a long period of time if both parties are ok with that and the relay keeps messages around.
Lightning Address in this scheme can be just a NIP-05 address. For example, I want to pay hampus@blixtwallet.com, I find his public key and relays from that address and use that make a payment offer, as in the paragraphs above. Of course this same flow works with nprofile too and even npub (even though that disgracefully doesn't have relays specified in it).
We can also have services selling stuff with Lightning Address (or nprofile/npub) by just having them publish their sell offers as events with kind:30010. The payer will query all these and decide which one to offer a payment for. This enables both someone to sell a single thing or even make a single tip jar with metadata -- but also more complex flows, for example, a pizza shop that wants to have a different sell offer for each of their pizza flavors. Then wallets can show all these as a menu inside their UIs.