3 ms·

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 arg

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.

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

vapormache 6y ago

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.

cookiengineer 6y ago

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.