16 ms·

Vapor – Decentralized Web over Bitcoinized HTTP

183 points by vapormache 6y ago

johnhenry 6y ago
@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? (Love the name, btw).
adkadskhj 6y ago
> 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!)
vapormache 6y ago
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.
- gbasin 6y ago
  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!
- vmception 6y ago
  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.
  - adkadskhj 6y ago
    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?
zydeco 6y ago
Not to be confused with Vapor (https://vapor.codes https://vapor.codes), the server-side Swift framework
- george_perez 6y ago
  Yeah, could've chosen a better name. I thought it was a fork of this or something.
- colecut 6y ago
  or Vapor (https://vapor.laravel.com https://vapor.laravel.com), the serverless PHP platform
freakynit 6y ago
The requests still go to vapor server first, for authentication, right? I'm sorry if that's not the case. I didn't get the chance to read full.
- vapormache 6y ago
  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 https://vapor.network/#52afterbitcoinizedhttp
deleted 6y ago
[deleted]
dane-pgp 6y ago
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.
- vapormache 6y ago
  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) More on this here: https://vapor.network/#62solution https://vapor.network/#62solution
  - duskwuff 6y ago
    But what's the upside of specifically using the format of a Bitcoin transaction here, as opposed to (for example) using a signed HTTP message (a la https://datatracker.ietf.org/doc/draft-ietf-httpbis-message-signatures/ https://datatracker.ietf.org/doc/draft-ietf-httpbis-message-...)? 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.
nicholas-cc 6y ago
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.
- miked85 6y ago
  The first sentence of the introduction paragraph states that transactions are offchain: "Vapor is an OFFCHAIN Bitcoin protocol for building a decentralized web by "Bitcoinizing" HTTP requests"
  - mrschwabe 6y ago
    further down however, it indicates you may also optionally post onchain ie- to take advantage of a blockchain backed timestamp.
monokh 6y ago
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.
Lambdanaut 6y ago
I'm confused about how I can translate an existing webapp to vapor. Let's say I have an existing Python webapp with a database backend. Can I take that and make it speak Vapor? Is it better to design an app from scratch to speak vapor?
- vapormache 6y ago
  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.
cacho2020 6y ago
In this system, will all user data be public? 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 6y ago
  You can end-to-end encrypt user data to implement privacy. Actually that’s the only right way to do things if you care about privacy.
  - cacho2020 6y ago
    but how can the applications use that data in any meaningful way then? what;s the purpose of sending transactions to applications otherwise?
    - judge2020 6y ago
      I suppose the poster you're reply to is floating the idea of something like TLS on top of this protocol...
    - cocktailpeanuts 6y ago
      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.
rsmets 6y ago
Encapsulating HTTP request in Bitcoin transactions? Sounds like the throughput limitations of Bitcoin would make this a super slow decentralized web protocol?
- dboreham 6y ago
  Bitcoin transaction packet format and signature scheme is used, but the transactions aren't actually sent to the Bitcoin blockchain.
- microtherion 6y ago
  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.
tomowl 6y ago
I like the whole idea but im curious on how it would actually work in real life and dealing with the slowness of bitcoin network
- cocktailpeanuts 6y ago
  It says “Vapor is an OFFCHAIN Bitcoin protocol for building a decentralized web by "Bitcoinizing" HTTP requests.”
joosters 6y ago
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.
- synctext 6y ago
  > "trustlessly replicated to other Vapor nodes" 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.
  - volaski 6y ago
    Maybe wallets can implement an identity system (either as a standard or through federation among vapor nodes)?
  - larrysalibra 6y ago
    It’s called “Vapor” as in “vaporware” and makes absolutely no sense. I’m going to go out on a limb here and say we’re being trolled. The emperor is naked.
    - m463 6y ago
      The buzzwords are strong in this one.
- this_user 6y ago
  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.
volaski 6y ago
> 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. <= Now this sounds WAY cool.
- beders 6y ago
  It just runs counter to why you want an authentication scheme in the first place as a service provider. It is about control.
sthnblllII 6y ago
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.
- vapormache 6y ago
  > 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.
  - deleted 6y ago
    [deleted]
  - sthnblllII 6y ago
    Can you stop with the marketing speak? Goals aren't features.
    - for_i_in_range 6y ago
      Steve Jobs disagrees.
      - TylerE 6y ago
        If Steve Jobs ever used "benefit decentralization" as a noun, he would have cut his own tongue out rather than risk uttering it a second time.
pscsbs 6y ago
Shouldn’t IPFS + Filecoin be well-suited for this exact use-case?
- chrisco255 6y ago
  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.
- volaski 6y ago
  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
companyhen 6y ago
Reminds me of https://arweave.org https://arweave.org
dboreham 6y ago
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.
X6S1x6Okd1st 6y ago
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.
- jdonaldson 6y ago
  SSL certificates have their own issues, typically rooted in a centralized authorities dropping the ball or intentionally issuing fraudulent certificates https://www.eff.org/deeplinks/2011/04/unqualified-names-ssl-observatory https://www.eff.org/deeplinks/2011/04/unqualified-names-ssl-... https://security.googleblog.com/2013/12/further-improving-digital-certificate.html https://security.googleblog.com/2013/12/further-improving-di... Vapor also addresses decentralization in distribution of content as well. I'm extremely skeptical of Vapor for other reasons, but we ought to at least keep the value proposition clear here.
  - X6S1x6Okd1st 6y ago
    SSL certs can be self signed. Bitcoin addresses are not signed by any agency so they would work under a similar security model as a self signed cert. > Vapor also addresses decentralization in distribution of content as well. How? All I see some way of performing a replay or amplification attack using an unspecified gateway.
    - jdonaldson 6y ago
      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.
LAMike 6y ago
OP_RETURN for storing data isn't new, but I signed up anyways to see how to project continues to grow. Keep building!
bitxbitxbitcoin 6y ago
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.
masswerk 6y ago
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.
- biolurker1 6y ago
  Does offchain also include proof of work?
  - johnpaulkiser 6y ago
    That question doesn't make a whole lot of sense so I'll answer another one. Do off-chain transactions need to be mined using proof of work? No.
    - masswerk 6y ago
      Mind that as long as you are doing Bitcoin, it's all about proof of work (it's what creates the unique event the data is tied to).
ashtonkem 6y ago
This sounds more like something to bilk a VC out of their money than an actual product that will be used by a non trivial number of consumers.
- heyoo 6y ago
  It sounds like vaporware.
- JackFr 6y ago
  A concrete use case would go a long way here.
simmo9000 6y ago
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? Business case seams legit.
nicexe 6y ago
some of the features overlap with https://zeronet.io/ https://zeronet.io/
wyck 6y ago
I guess some speed tests would be insightful since your effectively doing more hops, and also a comparison to why this beats SSL. You list the pro's but what about the cons? Surely having an immutable ledger has some negatives, as well as a signing server.
intotheabyss 6y ago
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.
dzonga 6y ago
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
gregjw 6y ago
Is this more compelling that IPFS?
ccamrobertson 6y ago
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?
mrschwabe 6y ago
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)
xmly 6y ago
Sounds like Https and BGP...
fudged71 6y ago
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?
- jkhdigital 6y ago
  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.
  - sthnblllII 6y ago
    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. https://andersen.sdu.dk/vaerk/hersholt/TheEmperorsNewClothes_e.html https://andersen.sdu.dk/vaerk/hersholt/TheEmperorsNewClothes...
Animus999 6y ago
Superb innovation and excellent proof of work.
longt1melurker 6y ago
in short: this is a strange wrapper over http using ecdsa as auth. why not use ECIES along with it to totally achieve privacy from requester to server? as i understand, the vapor nodes save requests and replies, so these can be replayed. this means heavy data bloat, when i look at nowadays apis we all run, saving all requests and answers fully... come on
- aleclarsoniv 6y ago
  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.
julius_set 6y ago
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) :-)

183 points by vapormache 6y ago

@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? (Love the name, btw).

adkadskhj 6y ago

> 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!)

vapormache 6y ago

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.

gbasin 6y ago
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!
vmception 6y ago
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.
- adkadskhj 6y ago
  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?

zydeco 6y ago

Not to be confused with Vapor (https://vapor.codes https://vapor.codes), the server-side Swift framework

george_perez 6y ago
Yeah, could've chosen a better name. I thought it was a fork of this or something.
colecut 6y ago
or Vapor (https://vapor.laravel.com https://vapor.laravel.com), the serverless PHP platform

freakynit 6y ago

The requests still go to vapor server first, for authentication, right? I'm sorry if that's not the case. I didn't get the chance to read full.

vapormache 6y ago
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 https://vapor.network/#52afterbitcoinizedhttp

deleted 6y ago

[deleted]

dane-pgp 6y ago

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.

vapormache 6y ago
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) More on this here: https://vapor.network/#62solution https://vapor.network/#62solution
- duskwuff 6y ago
  But what's the upside of specifically using the format of a Bitcoin transaction here, as opposed to (for example) using a signed HTTP message (a la https://datatracker.ietf.org/doc/draft-ietf-httpbis-message-signatures/ https://datatracker.ietf.org/doc/draft-ietf-httpbis-message-...)? 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.

nicholas-cc 6y ago

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.

miked85 6y ago
The first sentence of the introduction paragraph states that transactions are offchain: "Vapor is an OFFCHAIN Bitcoin protocol for building a decentralized web by "Bitcoinizing" HTTP requests"
- mrschwabe 6y ago
  further down however, it indicates you may also optionally post onchain ie- to take advantage of a blockchain backed timestamp.

monokh 6y ago

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.

Lambdanaut 6y ago

I'm confused about how I can translate an existing webapp to vapor. Let's say I have an existing Python webapp with a database backend. Can I take that and make it speak Vapor? Is it better to design an app from scratch to speak vapor?

vapormache 6y ago
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.

cacho2020 6y ago

In this system, will all user data be public? 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 6y ago
You can end-to-end encrypt user data to implement privacy. Actually that’s the only right way to do things if you care about privacy.
- cacho2020 6y ago
  but how can the applications use that data in any meaningful way then? what;s the purpose of sending transactions to applications otherwise?
  - judge2020 6y ago
    I suppose the poster you're reply to is floating the idea of something like TLS on top of this protocol...
  - cocktailpeanuts 6y ago
    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.

rsmets 6y ago

Encapsulating HTTP request in Bitcoin transactions? Sounds like the throughput limitations of Bitcoin would make this a super slow decentralized web protocol?

dboreham 6y ago
Bitcoin transaction packet format and signature scheme is used, but the transactions aren't actually sent to the Bitcoin blockchain.
microtherion 6y ago
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.

tomowl 6y ago

I like the whole idea but im curious on how it would actually work in real life and dealing with the slowness of bitcoin network

cocktailpeanuts 6y ago
It says “Vapor is an OFFCHAIN Bitcoin protocol for building a decentralized web by "Bitcoinizing" HTTP requests.”

joosters 6y ago

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.

synctext 6y ago
> "trustlessly replicated to other Vapor nodes" 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.
- volaski 6y ago
  Maybe wallets can implement an identity system (either as a standard or through federation among vapor nodes)?
- larrysalibra 6y ago
  It’s called “Vapor” as in “vaporware” and makes absolutely no sense. I’m going to go out on a limb here and say we’re being trolled. The emperor is naked.
  - m463 6y ago
    The buzzwords are strong in this one.
this_user 6y ago
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.

volaski 6y ago

> 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. <= Now this sounds WAY cool.

beders 6y ago
It just runs counter to why you want an authentication scheme in the first place as a service provider. It is about control.

sthnblllII 6y ago

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.

vapormache 6y ago
> 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.
- deleted 6y ago
  [deleted]
- sthnblllII 6y ago
  Can you stop with the marketing speak? Goals aren't features.
  - for_i_in_range 6y ago
    Steve Jobs disagrees.
    - TylerE 6y ago
      If Steve Jobs ever used "benefit decentralization" as a noun, he would have cut his own tongue out rather than risk uttering it a second time.

pscsbs 6y ago

Shouldn’t IPFS + Filecoin be well-suited for this exact use-case?

chrisco255 6y ago
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.
volaski 6y ago
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

companyhen 6y ago

Reminds me of https://arweave.org https://arweave.org

dboreham 6y ago

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.

X6S1x6Okd1st 6y ago

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.

jdonaldson 6y ago
SSL certificates have their own issues, typically rooted in a centralized authorities dropping the ball or intentionally issuing fraudulent certificates https://www.eff.org/deeplinks/2011/04/unqualified-names-ssl-observatory https://www.eff.org/deeplinks/2011/04/unqualified-names-ssl-... https://security.googleblog.com/2013/12/further-improving-digital-certificate.html https://security.googleblog.com/2013/12/further-improving-di... Vapor also addresses decentralization in distribution of content as well. I'm extremely skeptical of Vapor for other reasons, but we ought to at least keep the value proposition clear here.
- X6S1x6Okd1st 6y ago
  SSL certs can be self signed. Bitcoin addresses are not signed by any agency so they would work under a similar security model as a self signed cert. > Vapor also addresses decentralization in distribution of content as well. How? All I see some way of performing a replay or amplification attack using an unspecified gateway.
  - jdonaldson 6y ago
    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.

LAMike 6y ago

OP_RETURN for storing data isn't new, but I signed up anyways to see how to project continues to grow. Keep building!

bitxbitxbitcoin 6y ago

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.

masswerk 6y ago

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.

biolurker1 6y ago
Does offchain also include proof of work?
- johnpaulkiser 6y ago
  That question doesn't make a whole lot of sense so I'll answer another one. Do off-chain transactions need to be mined using proof of work? No.
  - masswerk 6y ago
    Mind that as long as you are doing Bitcoin, it's all about proof of work (it's what creates the unique event the data is tied to).

ashtonkem 6y ago

This sounds more like something to bilk a VC out of their money than an actual product that will be used by a non trivial number of consumers.

heyoo 6y ago
It sounds like vaporware.
JackFr 6y ago
A concrete use case would go a long way here.

simmo9000 6y ago

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? Business case seams legit.

nicexe 6y ago

some of the features overlap with https://zeronet.io/ https://zeronet.io/

wyck 6y ago

I guess some speed tests would be insightful since your effectively doing more hops, and also a comparison to why this beats SSL. You list the pro's but what about the cons? Surely having an immutable ledger has some negatives, as well as a signing server.

intotheabyss 6y ago

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.

dzonga 6y ago

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

gregjw 6y ago

Is this more compelling that IPFS?

ccamrobertson 6y ago

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?

mrschwabe 6y ago

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)

xmly 6y ago

Sounds like Https and BGP...

fudged71 6y ago

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?

jkhdigital 6y ago
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.
- sthnblllII 6y ago
  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. https://andersen.sdu.dk/vaerk/hersholt/TheEmperorsNewClothes_e.html https://andersen.sdu.dk/vaerk/hersholt/TheEmperorsNewClothes...

Animus999 6y ago

Superb innovation and excellent proof of work.

longt1melurker 6y ago

in short: this is a strange wrapper over http using ecdsa as auth. why not use ECIES along with it to totally achieve privacy from requester to server? as i understand, the vapor nodes save requests and replies, so these can be replayed. this means heavy data bloat, when i look at nowadays apis we all run, saving all requests and answers fully... come on

aleclarsoniv 6y ago
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.

julius_set 6y ago

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) :-)