Maybe the creator of this should give a use case? I'm struggling to understand just what problem this is trying to solve here, and from the looks of the comments, so are many other people.
Instead of using central web servers, it is replaced with a network of Vapor nodes. I don't see this solving any problem. Just because HTTP requests have a Bitcoin signature, that does not solve any web-of-trust issues.
> record authenticated HTTP requests and replay them anywhere.
This is confusing, either identities cost real Bitcoin or you have a Sybil attack problem (numerous fake identities). If you need real Bitcoins, it requires lots of effort to use Vapor. As it is written, this is not going to work.
Which is pretty much the summary for > 99% of crypto projects. The try to solve an imaginary problem that doesn't actually exist in the real world in the least efficient, and most convoluted, way imaginable. Then they fail.
Hi, Vapor is a protocol for building a decentralized web, but takes a different approach from other existing "decentralized internet" projects.
Instead of decentralizing the networking stack, Vapor focuses on on decentralizing the data packet itself, which means Vapor can live on top of any other networking stack, most notably HTTP. Because it's just vanilla HTTP, 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.
Note that the HTTP requests are serialized and stored as OFFCHAIN Bitcoin transactions by default and never bloats up the blockchain. Optionally, the offchain transactions can be compressed into a transaction id bundle and timestamped on the blockchain as well as taking advantage of the programmability and payment ability of the Bitcoin script itself, but by default it's all offchain, yet still achieves decentralization and trustless replication of HTTP requests.
The reference client is almost ready and just wanted to get it out there to see who's interested. Thank you for taking a look.
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
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.
> 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.
While I understand that applications that receive user data could now "verify" the user data they have has not been changed, how would you do that for something other than raw transactions? Arguable just storing raw transactions will not be that useful - I'd expect these applications to do things with the user data - and that whole processing itself be verifiable (this could be possible if the logic to manipulate data is known). However, how can you do that while preserving user data privacy?
A lot of apps don’t need user data to be completely private. Take Twitter for example, all their stuff is public. But for DM they’re all private. For these cases you can encrypt the data inside the http requests so only the intended receiver can decrypt. Doesn’t need TLS.
The whole point of a decentralized web is to remove data hosting costs and eliminate central points of failure which are vulnerable to DDoS and censorship. PGP already lets you verify data is from a particular sender, and I don't want every website I visit to go on a public ledger.
> The whole point of a decentralized web is to remove data hosting costs and eliminate central points of failure which are vulnerable to DDoS and censorship
Vapor has nothing to do with data hosting costs and DDoS. It solves the problem of data ownership, incentive, monetization, etc.
This difference in the interpretation of what benefit decentralization provides is why many past "decentralized internet" projects have focused on the networking aspect (censorship resistance, DDoS avoidance, etc.) whereas Vapor is taking a different approach where it tries to solve a different problem. Its main focus is to decentralize the power structure, and to do that it needs to solve the data ownership (both philosophically and technologically), as well as frictionless monetization.
The goal is to change the power structure that drives the web, and I believe it has more to do with how the data itself is structured (so that it can be distributed trustlessly regardless of the network) than the network stack.
I still don't see how this has anything to do with decentralization, and frankly the way you're justifying it sounds like you wanted to use a clickbaity word that doesn't really apply here.
How does this help data ownership? How does this decentralize the 'power structure'? The ownership and power is still in the hands of the server. The benefits you highlight here are addressed by SSL. Is this trying to address the downsides of SSL? I can't see how it is/would.
It seems like 'frictionless monetization' is the only thing this really addresses, and even that I'm skeptical of.
I don't mean to be such a detractor, but you really need to reconsider what the purpose of this technology is and sell that purpose better. Because your current explanation makes no sense.
Sorry about the marketing speak, I read it again and it does sound cheesy and I updated to tone it down. It still sounds a bit cheesy but I had to explain it that way to make my point.
Because the goal is not to lower hosting costs and avoid DDoS, but to create a data structure that can be routed around in a trustless manner (by double signing the HTTP requests and encapsulating in an offchain Bitcoin transaction format with unique SHA256 hash ids for secure synchronization), it's solving a completely different problem. The features were derived from this goal.
You only know that the connection has not been MITM if you have actually identified that the public keys that you want to use or trust that they are correct due to a WoT (e.g. they are signed by a CA your OS trusts or GPG WoT).
2 identities knowing data came from each other due to the properties of public key encryption. Is this a good summary? For which use cases should this property come in handy?
I was going to ask why the architecture needs Bitcoin at all, when it could just use a simpler identity system (like PGP), but the excellent documentation says:
> 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.
One powerful feature for the "Bitcoin transaction as a packet" approach is that it can be extended to facilitate extra input and output scripts.
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)
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.
Encapsulating HTTP request in Bitcoin transactions? Sounds like the throughput limitations of Bitcoin would make this a super slow decentralized web protocol?
My understanding of their white paper is that they are using Bitcoin transactions (for whatever reason, and quite possibly not a technical one), but actually recording them on the Blockchain is optional.
Kudos for working hard to coin the term Bitcoinized in this way. I like it way better than previous uses of the word which either took the word to mean something along the lines of "make marginally more decentralized or distributed" or "replace existing fiat currency as reserve currency soon."
Best of luck with the project - looking forward to seeing the implementation.
Can you provide a high-level example of how Vapor could be used to facilitate censor-proof content ? (ie- permanent content address by making a transaction on the blockchain plus some other layer/tech you might suggest to ensure said content's immutability & availability)
Green Computing – Network traffic is already bad enough (about 45% of the total energy consumption of IT), but adding Bitcoin to this, which is effectively creating a unique event by a metric of presumably unsustainable energy consumption and related costs, may be just a bit(coin) too much.
> Because authentication is privately handled by each service provider's proprietary system, it is not easy for people to move their data around across multiple applications.
I'm struggling to understand the relation between owning your auth and owning your data here. So far as i can tell, the only way i "own my data" is that i could.. i guess, record every single HTTP request i ever make, and replay it against some other version of an identical app?
Eg, lets say Facebook added Vapor; How would i move my data away from Facebook in the future? How has Vapor helped me own my data?
(honest question, Vapor has some really cool properties!)
At first glance this is brilliant and I don't know why there are so many comments complaining. The documentation is more than an idea and there are plenty of benefits/use cases included. Maybe it's just the term "decentralized" in the title that is unclear, the rest is solid.
This seems like a fantastic platform for microtransactions, transactional streams, and value flowing between devices and browsers using existing networking infrastructure. The ability to do this all ON TOP of decentralized networks like IPFS makes it even better?
Yeah I don’t get the decentralized part... I feel like there is this logical leap from “self-signed HTTP requests” to “decentralized data” that skips a few steps that are obvious to someone who has been working on this for years but completely opaque to me.
No, the author is just BSing and people are afraid to point out the emperor has no clothes because they don't want to be revealed as fools. Either that or the author honestly doesnt have a clue what he's talking about.
So would a Content Service Provider (CSP) run a Vapor node and then have opportunity to monetise "immutable" user data talking HTTP?
HTTP, like Amazon S3 buckets seams to be appropriate enough being stateless, ubiquitous and anything can be encapsulated.
User data storage capacity relates to bitcoin via some magic? So Vapor is to be used as a CSP offering that links bitcoin directly to storage enabling pay per use type content? Content that is signed and sealed.
Speed of bitcoin transactions seems like an interesting challenge.
What centrally controlled components (by Vapor) are there, if any?
It seems like if you choose to record transactions to the blockchain you end up posting every transaction to the blockchain which is quite expensive; why not only store the hash of the HTTP request and use a Merkle Tree to store multiple requests in a single Bitcoin transaction? The only reason I see why not is that then the actual request data could be lost or not revealed, but since this protocol saves all requests to an internal database as well, I don't see why that would be a problem.
> Until now, it has been impossible to "record" and replay authenticated HTTP requests outside of a single service provider because authentication by nature has been centralized--Your identity belonged to the service provider.
>
> By "Bitcoinizing" HTTP requests and adopting the decentralized authentication scheme using Bitcoin wallet signatures, Vapor makes it possible to record authenticated HTTP requests and replay them anywhere.
I _think_ this is similar to many "self sovereign identity" projects, but using Bitcoin wallet keys for signature, and Bitcoin transaction format for encoding. It isn't clear to me how the whole "decentralized web" part of this is done though. You need quite a bit more than just signed http requests, I suspect.
@vapormache, I'm imagining a scenario where I would like to encrypt the request. Is this part of the protocol, or do you consider it orthogonal to the project?
Something to be aware of with regards to the "Blockchain Timestamp" feature: OP_RETURN data is limited to 80 bytes. I wonder if there are any such limits with the bitcoin software itself that you would need to reverse to construct the offchain transactions.
I'm not super familiar with which op codes are currently available; is the use of OP_RETURN in Vapor consistent across Bitcoin SV, Bitcoin and Bitcoin Cash?
E.g., could I timestamp something on Bitcoin, or will timestamping/monetizing only work for Bitcoin SV?
There are many ways to do this, but one way is to use Vapor as a proxy. Vapor server takes care of the authorization/authentication, and it routes the requests to an internal auth-less API endpoint not exposed to the outside world.
Basically you can build a CRUD app without authentication at all (only accessible by your own API clients). And then allow only Vapor to write to the API internally.
This would be the most basic approach. I think it will become more clear once I release the implementation, just wanted to get the protocol out there first.
This looks like the perfect example of I have a hammer so everything looks like a nail. Not needed, unnecessary, and most likely expensive (meaning will bloat up my server costs) :-)
IPFS is a decentralized network protocol, a content-based addressing system. Filecoin is decentralized file storage, incentivized by cryptoeconomics. On their own, neither IPFS nor Filecoin have the same goals as Vapor. It seems as though Vapor's intended purpose is to use off-chain Bitcoin transactions to transmit HTTP requests to normal APIs. The primary benefits being (optional) payments and identity.
The document says it’s network protocol agnostic because it only focuses on decentralizing the data layer, so it might be possible to use vapor on top of IPFS in addition to HTTP
Why use Bitcoin? Metamask is far more used than any Bitcoin wallets, so if all you want to do is have users sign transactions, Metamask/Ethereum is the way to go.
The requests are first signed on the client side by the user's Bitcoin wallet, and then sent to the Vapor server where the server signs with its own private key, and the resulting bitcoin transaction packet encapsulating HTTP is sent back to the user as receipt, which can be used as evidence. https://vapor.network/#52afterbitcoinizedhttp
It's probably optional for Vapor nodes to save transactions. Most useful for auditing requirements, I guess.
The more compelling use case is for clients to cache the receipts of particular transactions so they can replay them on other services. For example, if the user decides to migrate their data to a competing service.
Also, the receipts act as proof of tampering (or lack thereof), since they are signed by the Vapor node.
how open is this ? will a 3rd party be able to run the vapor servers. what's the business model ? I hope it's behind a non-profit. if you wish to replace the data layer
This is surprisingly well written, diagrammed and promoted for not seeming to solve a single problem other than what could be solved by an SSL client cert.
SSL certificates have their own issues, typically rooted in a centralized authorities dropping the ball or intentionally issuing fraudulent certificates
These are just the details I gleaned from the article. But, I have a similar understanding... that the blockchain functionality is similar to self-signing.
The article bills Vapor as helping to decentralize the "data layer" of an api. This naturally has some immediate caveats... like... this sort of framework would not be suitable for real time or streaming Apis.
Also, the article doesn't really touch on the cost of maintaining all of this. It's true that vapor api hosts can charge a small transaction fee to maintain/run their processing nodes. I have to wonder what that looks like, and if people are willing to pay a per-request fee for an http transaction.
I don't believe this is intended to replace standard authentication, and calling out how it's impractical for common scenarios is fair game. However, I think it's more interesting to think about scenarios where this might be useful.
Well, the scenario would involve distributing information where one couldn't/shouldn't rely on a central authority. Imagine using this to coordinate protests against a government, or in countries where there's too much corruption to trust any centralization at all.
By my reading wrapping an HTTP request inside a bitcoin transaction does not solve for that use case.
Something like IPFS pubsub could work, or you could use any of the on-chain social networks that have sprung up, or you could use E2E group chats like everyone from the Taliban to activists in the US use.
E2E group chats are closely related, but ephemeral. IPFS seems also closely related, but it's dealing more with the content of a file, and not really designed for handling the identity of who wrote or distributed the content.
