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.
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.
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.
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.
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.
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?
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 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)
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.
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?
[+] [-] joosters|5 years ago|reply
[+] [-] synctext|5 years ago|reply
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.
[+] [-] this_user|5 years ago|reply
[+] [-] vapormache|5 years ago|reply
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.
[+] [-] vmception|5 years ago|reply
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.
[+] [-] gbasin|5 years ago|reply
[+] [-] remram|5 years ago|reply
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.
[+] [-] waynenilsen|5 years ago|reply
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.
[+] [-] jkhdigital|5 years ago|reply
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?
[+] [-] cayblood|5 years ago|reply
[+] [-] kordlessagain|5 years ago|reply
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.
[+] [-] cacho2020|5 years ago|reply
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?
[+] [-] cocktailpeanuts|5 years ago|reply
[+] [-] sthnblllII|5 years ago|reply
[+] [-] vapormache|5 years ago|reply
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.
[+] [-] 3np|5 years ago|reply
Don’t confuse the Bitcoin protocol with the public Bitcoin ledger!
[+] [-] dane-pgp|5 years ago|reply
> 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.
[+] [-] vapormache|5 years ago|reply
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
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] rsmets|5 years ago|reply
[+] [-] dboreham|5 years ago|reply
[+] [-] microtherion|5 years ago|reply
[+] [-] bitxbitxbitcoin|5 years ago|reply
Best of luck with the project - looking forward to seeing the implementation.
[+] [-] mrschwabe|5 years ago|reply
[+] [-] masswerk|5 years ago|reply
[+] [-] biolurker1|5 years ago|reply
[+] [-] ashtonkem|5 years ago|reply
[+] [-] JackFr|5 years ago|reply
[+] [-] heyoo|5 years ago|reply
[+] [-] adkadskhj|5 years ago|reply
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!)
[+] [-] fudged71|5 years ago|reply
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?
[+] [-] jkhdigital|5 years ago|reply
[+] [-] simmo9000|5 years ago|reply
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?
Business case seams legit.
[+] [-] nicholas-cc|5 years ago|reply
[+] [-] miked85|5 years ago|reply
"Vapor is an OFFCHAIN Bitcoin protocol for building a decentralized web by "Bitcoinizing" HTTP requests"
[+] [-] volaski|5 years ago|reply
<= Now this sounds WAY cool.
[+] [-] beders|5 years ago|reply
It is about control.
[+] [-] dboreham|5 years ago|reply
[+] [-] johnhenry|5 years ago|reply
(Love the name, btw).
[+] [-] monokh|5 years ago|reply
[+] [-] ccamrobertson|5 years ago|reply
E.g., could I timestamp something on Bitcoin, or will timestamping/monetizing only work for Bitcoin SV?
[+] [-] wyck|5 years ago|reply
You list the pro's but what about the cons? Surely having an immutable ledger has some negatives, as well as a signing server.