vapormache

Good question.

Short answer: Vapor will use Starfish as the default wallet, but not exclusively.

Long answer:

While working on Vapor I found that most existing Bitcoin wallets are focused only on onchain transactions and money transactions, and it's difficult to implement a frictionless UX when using them as they are today (Imagine having to redirect users to a wallet and manually sign every single API request).

Vapor on the other hand tackles a field that has not been explored much before--the "offchain" and "data" world--so I needed a wallet that would "just work" with everything offchain and everything data, while preserving privacy.

So I built one. And that's Starfish.

Basically, Starfish is a wallet that can work well with Vapor. You just keep it on, and everything will "just work" frictionlessly. That said, the reason why it's "Starfish" and not "Vapor Wallet" is because Vapor is wallet agnostic. Vapor is a protocol and will support signing with all types of Bitcoin wallets and all types of signature schemes, in a plug-and-play manner. The Starfish approach is one of the options, which provides a seamless UX and provides more privacy and convenience.

Vapor is coming soon, just wanted to release Starfish first in order to avoid confusion.

You can already build some super interesting stuff with Starfish alone. The Vapor layer will make them more "persistent" by providing ways to wrap everything in a Bitcoin transaction format.

I've been working on a new authentication system that does not use a third party.

The main properties:

Convenience: Uses Bitcoin Cryptography (Hierarchical Deterministic Wallet) to generate all identities from a single seed, no need to back up passwords for every site. No need to worry about passwords.

Decentralized: The identity system does not require a third party, all identities are generated from the embedded Bitcoin wallet.

Privacy: All identities are sandboxed to each app provider by default. Also, no reliance on 3rd party authentication provider provides privacy.

It's an early alpha, and I would appreciate any constructive feedback.

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.

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.

Just to clarify, I didn't use it as a noun. Here's what I meant:

> This difference in the interpretation of (what benefit) decentralization provides

> 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.

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.

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.

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.