> No Bitcoin needed: Vapor only uses Bitcoin transactions as data packets. You do not even need to own Bitcoins.
That's incredible, and my support for this technology has increased greatly after reading that.
Basically you can encode not just vanilla HTTP requests but also payment in a single Vapor request.
By default you can already build web apps with Vapor by simply using the base protocol. But by structuring everything as Bitcoin transaction, you can for example implement monetized APIs and money programmed routing (Implement routing and authorization based on Bitcoin script payments and/or resolution)
More on this here: https://vapor.network/#62solution
Addressing the points in your link:
> 1. Decentralized Authentication
First: Bitcoin wallet addresses are temporary keys, not identities. "Authenticating" against one isn't really appropriate, no more than it'd make sense to authenticate a user as the owner of a specific dollar bill.
Second: even if you wanted that, there's no reason you should need to encapsulate HTTP in a weird wrapper to accommodate it. A variety of schemes already exist for signing HTTP requests within the bounds of HTTP. Most of them even support ECDSA signatures.
> 2. Monetize through Bitcoin payment
Signing a message which isn't a valid Bitcoin transaction with a wallet private key doesn't turn that message into a transaction. Conversely, there's no way to make a Bitcoin transaction conditional on the completion of an off-chain operation.
> 3. Programmable HTTP requests
Do you have any examples of what a realistic use case for this would be? Keep in mind that the signed nature of a request doesn't guarantee that the request is processed in the requested manner.
> 4. Data portability
First: as noted previously, there are already plenty of non-proprietary schemes for signing HTTP requests.
Second: this entire point presumes that making HTTP requests publicly logged and visible is a benefit, which doesn't make any sense.