4 ms·

Some things in p2p hypermedia (dat) that's not possible with http/s: * You can generate domains freely using pubkeys and without coordinating with other device

by pfraze 8y ago

Some things in p2p hypermedia (dat) that's not possible with http/s: * You can generate domains freely using pubkeys and without coordinating with other devices, therefore enabling the browser to generate new sites at-will and to fork existing sites * Integrity checks & signatures within the protocol which enables multiple untrusted peers to 'host'. This also means the protocol scales horizontally to meet demand. * Versioned URLs * Protocol methods to read site listings and the revision history * Offline writes which sync to the network asynchronously * Standard Web APIs for reading, writing, and watching the files on Websites from the browser. This means the dat network can be used as the primary data store for apps. It's a networked data store, so you can build multi-user applications with dat and client-size JS alone. I'm probably forgetting some. You do still need devices which provide uptime, but they can be abstracted into the background and effectively act as dumb/thin CDNs. And, if you don't want to do that, it is still possible to use your home device as the primary host, which isn't very easy with HTTP.

zmw 8y ago
Thanks for the list. > You can generate domains freely using pubkeys and without coordinating with other devices, therefore enabling the browser to generate new sites at-will and to fork existing sites. Not entirely sure what you mean, - We can generates HTTP sites at will (all you need is an IP address); - We have existing protocols for mirroring sites (not implemented universally, but nor is dat://); - 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. > Integrity checks & signatures within the protocol which enables multiple untrusted peers to 'host'. Basically subresource integrity? Granted, with this protocol you can in theory retrieve objects from any peers (provided that they actually want to cache/pin your objects), not just the ones behind a revproxy/load balancer, so that's a potential win from decentralization. > Versioned URLs We can have that over HTTP, but usually it's not economical to host old stuff. In this case, someone still needs to pin the old stuff, no? I can see that client side snapshots could be more standardized, but we do have WARC with HTTP. (EDIT: on second thought, it's much easier to implement on the "server"-side too.) > Protocol methods to read site listings and the revision history > Standard Web APIs for reading, writing, and watching the files on Websites from the browser. You can build that on top of HTTP too. 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.
- pfraze 8y ago
  > 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.
  - zmw 8y ago
    > Decentralization is a second-order effect. I see, I was looking at it backwards.
- dangerface 8y ago
  Its not a higher level of http, its more like lets use torrents instead of http because they are distributed and scale better. But the web is more than http, its dns and email and logins and all of that stuff, it all scales poorly, it can all be improved with distribution, lets not replace http with torrents lets replace it all with distributed stuff. As an example you talk about needing a special device to manage keys which presents problems. It centralises your identity to your yubi key (instead of email), lose your yubi key and you lose your identity, what if it gets wet, crushed, corrupted, your fucked. Instead we encrypt the key and distribute it across the net, if a copy is deleted or corrupted there are other copies and its available to you anywhere anytime. Currently your identity is centralised to your email, if your email goes down you lose your identity, if its distributed and a copy goes down you just use it like normal. Distribution solves pretty much all the problems centralisation creates, its just really complicated so we generally don't bother.
wila 8y ago
This is a very interesting topic, thanks for working on it and answering questions here. The first concern I had/have is about security. If everybody runs their own server, isn't this a security nightmare waiting to happen? I understand from the presentation that these websites won't run php or other server side scripts which at least take some concern away. Tara also showed how easy it was to copy a website, while pretty cool, that is also a nightmare scenario for most companies. If your competitors can clone your websites and pretend to be you, how do users know who's data they are looking at?
- anderber 8y ago
  Not OP, but I believe when it comes to website copies, you can identify which one you are actually using by the url. So if someone makes a copy of dat://mylocalbank.com, their url would be just the hash (Eg. dat://c6740...)

by pfraze 8y ago

zmw 8y ago

Thanks for the list. > You can generate domains freely using pubkeys and without coordinating with other devices, therefore enabling the browser to generate new sites at-will and to fork existing sites. Not entirely sure what you mean, - We can generates HTTP sites at will (all you need is an IP address); - We have existing protocols for mirroring sites (not implemented universally, but nor is dat://); - 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. > Integrity checks & signatures within the protocol which enables multiple untrusted peers to 'host'. Basically subresource integrity? Granted, with this protocol you can in theory retrieve objects from any peers (provided that they actually want to cache/pin your objects), not just the ones behind a revproxy/load balancer, so that's a potential win from decentralization. > Versioned URLs We can have that over HTTP, but usually it's not economical to host old stuff. In this case, someone still needs to pin the old stuff, no? I can see that client side snapshots could be more standardized, but we do have WARC with HTTP. (EDIT: on second thought, it's much easier to implement on the "server"-side too.) > Protocol methods to read site listings and the revision history > Standard Web APIs for reading, writing, and watching the files on Websites from the browser. You can build that on top of HTTP too. 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.

pfraze 8y ago
> 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.
- zmw 8y ago
  > Decentralization is a second-order effect. I see, I was looking at it backwards.
dangerface 8y ago
Its not a higher level of http, its more like lets use torrents instead of http because they are distributed and scale better. But the web is more than http, its dns and email and logins and all of that stuff, it all scales poorly, it can all be improved with distribution, lets not replace http with torrents lets replace it all with distributed stuff. As an example you talk about needing a special device to manage keys which presents problems. It centralises your identity to your yubi key (instead of email), lose your yubi key and you lose your identity, what if it gets wet, crushed, corrupted, your fucked. Instead we encrypt the key and distribute it across the net, if a copy is deleted or corrupted there are other copies and its available to you anywhere anytime. Currently your identity is centralised to your email, if your email goes down you lose your identity, if its distributed and a copy goes down you just use it like normal. Distribution solves pretty much all the problems centralisation creates, its just really complicated so we generally don't bother.

wila 8y ago

This is a very interesting topic, thanks for working on it and answering questions here. The first concern I had/have is about security. If everybody runs their own server, isn't this a security nightmare waiting to happen? I understand from the presentation that these websites won't run php or other server side scripts which at least take some concern away. Tara also showed how easy it was to copy a website, while pretty cool, that is also a nightmare scenario for most companies. If your competitors can clone your websites and pretend to be you, how do users know who's data they are looking at?

anderber 8y ago
Not OP, but I believe when it comes to website copies, you can identify which one you are actually using by the url. So if someone makes a copy of dat://mylocalbank.com, their url would be just the hash (Eg. dat://c6740...)