| > We can generates HTTP sites at will (all you need is an IP address); That's not really so easy from a consumer device with a dynamic IP. > - When you talk about pubkeys with coordination, there are obvious problems like the last paragraph of my original comment, right? Again, I'm probably misinterpreting what you're saying. You do need to manage keys and pair devices, yeah. > My takeaway is it's simply a higher-level protocol than HTTP, so it's unfair to compare it to HTTP. Are there potential benefits from being decentralized? Yes. But most of what you listed comes from being designed as a higher-level protocol. The broader concept of Beaker is to improve on the Web, and we do that by making it possible to author sites without having to setup or manage a server. Decentralization is a second-order effect. Any apps that use dat for the user profile & data will be storing & publishing that data via the user's device. Those apps will also be able to move some/all of their business logic clientside, because theyre just using Web APIs to read & write. Add to that the forkability of sites, and you can see why this can be decentralizing: it moves more of the Web app stack into the client-side where hopefully it'll be easier for users to control. |
I see, I was looking at it backwards.