That’s a primary component of cryptocurrency that my apps use: standardization of cryptography signing tools. You don't need cryptocurrencies for that, but its a big market with standardized utility and protocols even if you are never sending anything to the blockchain. And then all the user’s clients are also wallets so you can stay in that ecosystem for more.

GPG/PGP had 20 and 25 years, respectively, to proliferate but without a financial incentive it just petered along. The version for the OSX mail client is pretty bad in 2020 and just as niche as ever.

A lot of people undervalue this aspect of crypto-assets: Standardized signing protocols and tools, standardized large namespace with no collisions for account creation and state, the lower amount of programming needed because you aren't making your own account creation and state framework and database since you can just differentiate users by address or signature.

For anyone passing by: “But the low transactions per second are my final goto argument and I get to express my hate because of it”, again these aforementioned use cases don't send a transaction to the p2p network and are therefore not constrained by the bandwidth of the p2p network / blockchain. There is no way to tell how many projects use cryptocurrency infrastructure this way and how many users or how much activity they have.

That's an interesting take on this! I often work on small projects for mildly decentralized / storage stuff. Often i have the need to encrypt this stuff in various ways and i am disappointed by the tools available to me.

I feel like i have so many tools for amazing feats of engineering with minimal understanding required (which may not be a good thing lol), but Crypto tools and/or advice always seems to suggest you shouldn't use crypto at all if you don't know what you're doing.

Eg if i write some storage application that fits my needs, and i want to add encryption for the data at rest - i often find the environment (crypto tooling and communities) hostile. Hostile to encrypting something without knowing enough to be competent.

I get why crypto communities/tooling are afraid of informed-idiots (as i self describe), but i view it as a failing of the environment not the informed-idiot.

Do you see your angle on this as something that could lower the barrier to entry for informed idiots just wanting to _use_ crypto? Ie the fact that Crypto Wallets/Coins have standardized and simplified a lot Crypto-related UXs, do you see that impacting common software usecases for encryption / signing?

yes crypto wallets can help, although if you want to go deeper this direction, I would say it is important not to use crypto in "encryption" and "digital asset" contexts without further elaboration on which one you are talking about.

reason being that its not clear if you are confusing the contexts or if the reader is. to the delight of cryptography aficionados who may not like the newer asset-based context, it looks like you did it correctly, but people in the crypto-asset space have abstracted the cryptography aspect so well that they would be confused.

the downside is that you will likely be relegating yourself to just the crypto-asset market, which has its own nuances as well as being a general anathema to some of your potential supporters who just want to ramble incoherently against crypto-assets.

fortunately, in crypto-assets your small project with just a few hundred users will probably make orders of magnitude more money than your big project with hundreds of thousands of users.

could you have just used a database? maaaaybe

could you have just made a lot of money while lowering your overhead costs by offloading your entire backend to the wallet and blockchain? definitely

I appreciate the thrust of this argument. Reminds me a bit of keybase.io. Signatures as identity seems obvious in hindsight.

Cool project and helpful write up. One thing I wish is that the benefits were quickly summarized at the very beginning ⏤ don't assume all interested readers are already familiar with them!

You seem to be using HTTP but removing the "web" and TCP part of this. If this is meant as an API framework for making signed, replicable requests & responses, why involve HTTP at all?

In particular, you probably do NOT want to be serving GET requests over this slow, inefficient transport at all, it would be much more appropriate for the state to be published to the chain (that's what blockchains are for...) and have clients read from there rather than issue duplicate idempotent requests.

Yes, there will be very powerful (yet not so obvious at the moment) use cases of GET requests, but at least in the beginning Vapor will be focused on state mutating requests such as POST/DELETE/PUT.

GET requests can be dealt with using regular web request methods.

Interested to see the code, I still don't totally understand how this works. Is there a generic vapor server that re-routes http requests to the hosts specified in the op-return? If so, what does that give you? If not, then the caller needs to submit this bitcoin transaction as a ... payload to some app-controled proxy that might inject some associated account information by querying a db then route the call to the right endpoint with that info in trusted headers or something?

I think I understand the concept as something like "login with your bitcoin identity" but I'm struggling to understand practically how what you're envisioning is meant to work.

I actually think this could be made far more generic as "login with public key identity" for any crypto scheme, Ethereum or just about anything that is not mimblewimble and/or hyper privacy focused should work similarly.

I found it

> The protocol serializes an HTTP request and wraps it inside a Bitcoin OP_RETURN output script. This is then signed with a Bitcoin wallet's identity private key and included as another output script in the transaction. The resulting Bitcoin transaction is sent to a destination Vapor API endpoint over HTTP.

> A Vapor endpoint only accepts HTTP POST requests with a raw bitcoin transaction as payload. The endpoint parses the transaction to extract out authentication information, validates the signature, and then forwards the extracted HTTP request to relevant API endpoints.

I actually think this is probably better suited as a library, then there is no need for any intermediary calls that will inevitably increase latency. Also, would the vapor server somehow send the information about the public key on to the destination server?

So... you wrap HTTP requests in a signed Bitcoin transaction. From what I can tell this adds two features: 1. The request has a GUID 2. The request is authenticated to the owner of the public key

My brain can’t seem to make the connection from those two things to “decentralized internet”. I suspect this might be because I don’t have a lot of experience with web app development. Can you ELI5 this?

Still confused about how micropayments for content would work practically. Either you have to wait at least until the next block is produced to verify that payment has received before responding to the HTTP request, or you respond before getting paid. Even if the block period is only 10 seconds (which would result in tremendous ledger bloat), the delay would still be too long.

I think it would be like any financial product and you’d need to accept some risk that payments would fail due to default. Eventually, we can hope that transactions will be faster, most likely through some trusted payment processor and/or some kind of contract.

Data packets are already "decentralized". In fact, saying data is not decentralized is a fallacy that can be used to irrationally represent the rest of this argument you are making for the use of this technology.

It's irrational because, by the way we see it, there is no instance of this software running that we can inspect. It's just you talking about it, which isn't anything at all if you've used tricky language (or GPT-3) to fool people into thinking you've done something when all you've done is write about it. On the other hand you could be almost done with it and see it working as magic, but we wouldn't because we can't see it or use it.

To support my argument, one only needs to look at the responses about "not understanding" what you are talking about.

> users don't need do things like connecting to P2P networks and the app looks just like a regular web app, except that every API is signed by the user Bitcoin wallet.

Word salad. Users would still need to sign their data packets with crypto and a regular web app is JavaScript, so what does that have to do with where the API endpoints are run and how?

I'll point out you are conflating the ideas of APIs and "apps" together. An app can use API endpoints, but an app can also just run in a browser and not talk to anything. How does vapor contribute anything to that scenario?

Most data packets are already copies of data stored somewhere. In fact, most data packets are decentralized copies of packets that are served from multiple locations already. Your story itself has multiple data packets representing it. They are all copies and they are all signed by a certificate. If I run a web app on AppEngine, the data comes from multiple servers running instances of my app somewhere. This is a thing, already, is what I'm saying. It works because of the standardized way the routers, servers and clients all talk to each other.

In this "vapor" software story you tell, it appears we can have "centralized" HTTP requests (like the POST that will happen when I click reply) which are packed up in a Bitcoin transaction, and then we have a place to store it where other things can pick it up later and make it "decentralized". That would be the place these "logs" go. Ok. Where is this storage router thing run? Who owns it? Does it use 402s when people need to pay or authenticate for content? Does it route things quickly, or does it take a little time to process each transaction? How does the router route packets that need to be secure end to end? Who is running the APIs that pick these packets up? How do they know they are ready for pickup? Does the router call them? If it does, how does it know how to call them?

More questions than answers means this is probably vaporware.

You, sir, have fully understood why a real p2p browser shouldn't have a gateway to offload state mutations.

What I do not like about all "decentralization" claims in the crypto space is that they are actually centralized due to their (money costing) gateway infrastructures that bloat the originating state mutation up with metadata it doesn't really need.

We've seen p2p before. It was based on seeders and leechers and worked fine. Granted, trackers were bad, but mostly due to underlying missing encryption for transport.

We just need to fix p2p transport encryption with keys that are not made for identification but rather just for the sake of transport of states - in order to guarantee privacy.

If keys - or wallets - can be uniquely identified, people could've just used google chrome instead, because they actually gained nothing.

It decentralizes not just "data", but requests themselves. Data is "already decentralized", but HTTP requests are not because their context is always dependent on the service provider's intent. Given an HTTP request like:

"PUT /posts/1/update <body>"

Vapor stores the entire serialized HTTP request instead of just the "<body>" part and double signs both on the user side and the service provider side. And this transaction can be trustlessly relayed to 3rd party nodes as well as returned back to the user as a receipt for evidence, because the raw transaction is self-validatable complete with the enclosed public key against which to check the signature, as well as the Bitcoin transaction ID acting as the checksum for raw transactions being synchronized.

You ask who owns the data, but it can be structured so that every user stores every single transaction on their wallet or local storage, not to mention 3rd party nodes that can act as insurance.