6 ms·

The internet is decentralized, the web has never been. HTTP protocol doesn't support it. But it's time to do that. What we need is the possibility of peer-to-pe

by nawitus 13y ago

The internet is decentralized, the web has never been. HTTP protocol doesn't support it. But it's time to do that. What we need is the possibility of peer-to-peer connections between browsers.

foobarqux 13y ago
That doesn't seem nearly as important as having a decentralized data store.
jimktrains2 13y ago
Sure HTTP does. You can cache things, sign things, &c. It's the current philosophy of "web apps" and not "hypertext" that isn't decentralization.
- icebraining 13y ago
  Web apps are not an issue: https://unhosted.org/ https://unhosted.org/ The problem is not technical, it's social, political and economical.
  - dllthomas 13y ago
    Web apps are a bit of an issue, but unhosted web apps are not more of an issue than applications (as opposed to utilities composable in the shell) in general - which is a tremendous improvement.
- nawitus 13y ago
  Well, technically a browser can listen to incoming connections, but in any case standards don't require it.
sushirain 13y ago
I'm curious, what will that enable?
- stingraycharles 13y ago
  The same thing as CDN will achieve, just a lot more complex.
icebraining 13y ago
Why do you say HTTP doesn't support it? If a browser doubled as a server, and each person hosted its own pages, how would that not be decentralized and P2P? Hell, it's been done: Opera Unite had just that model, with web pages and applications hosted by the browser itself: http://www.operasoftware.com/press/releases/general/opera-unite-reinvents-the-web http://www.operasoftware.com/press/releases/general/opera-un...
- dllthomas 13y ago
  The big problem with browser-as-server is that users typically want to power off their browsing devices, while they typically want servers to be always-on. Tying it through a cloud-hosted VPS or some local dedicated device (those wall-wart computers, or something else lightweight and low power but sufficiently capable), but then having the browser talk to it smartly (potentially from several devices simultaneously), would seem a better plan.
  - abvdasker 13y ago
    One possible solution is to distribute the hosted content to peers, so that when one person's browser is offline, hopefully someone else's is online to act as a server instead. That doesn't serve as a guarantee, but with a centralized fallback it could work. There are some very clever people already doing this with WebRTC.
    - dllthomas 13y ago
      Right, that works great assuming static content.
  - icebraining 13y ago
    People interested in privacy and Free Software are already working on it: https://freedomboxfoundation.org/learn/ https://freedomboxfoundation.org/learn/
    - dllthomas 13y ago
randall 13y ago
http://www.webrtc.org/chrome#TOC-Data-Channels- http://www.webrtc.org/chrome#TOC-Data-Channels-
Gonzih 13y ago
Don't be rude to HTTP, there is no limitations for decentralization in HTTP.
zackmorris 13y ago
While I agree that TCP/IP is decentralized, unfortunately due to NAT and corporate firewalls, vast swaths of users have been relegated to second class citizens who can only act as data consumers. Unfortunately this same misguided approach to security, or as I call it suckerity, has been carried forward into IPv6. There is some hope that WebRTC and other p2p technologies might alleviate the problem but then the task of punching through firewalls with techniques like STUN falls on developers. I'm not seeing an industry-led campaign to standardize a true p2p protocol based on something like UDP, because it would undermine the profits of data producers. I could go into how the proper layering of TCP should have been IP->UDP->TCP instead of IP->TCP and a whole host of technical mistakes such as inability to set the number of checksum bits, use alternatives to TCP header compression, or even use jumbo frames over broadband, but what it all comes down to is that what we think of as “the internet” (connection-oriented reliable streams and the client/server model) is not really compatible with a distributed content-addressable connectionless internet that can work with high latencies and packet loss. I think if this network existed, then extending HTTP to operate in a p2p fashion wouldn’t be all that complicated. Probably the way it would work is that you’d request data by hash instead of by address, and local caches would send you the pieces that match like BitTorrent. Most of the complexity will center around security, but I think Bitcoin and other networks of trust point the way to being able to both prove one’s identity and surf anonymously. Tim Berners-Lee may not be thinking about the problem at this level but we need more people with his clout to get the ball rolling. I wasted a lot of time attempting to write a low-level stream API over UDP for networked games before zeromq or WebRTC existed and ended up failing because there are just too many factors that made it nondeterministic. It’s going to have to be a group effort and will probably require funding or at least a donation of talent from people familiar with the pitfalls to get it right. Otherwise I just don’t think a new standard (one that makes recommendations instead of solving the heart of the problem) is going to catch on.
- jnbiche 13y ago
  This is exactly the problem. We need a better transport layer. You know, the speed at which SPDY has caught on has given me hope. Admittedly, that's at the application layer, but I think if Google were to get behind an initiative to create a better TCP, it would actually have a chance at working. Historically, Google's incentives were properly aligned with a decentralized Internet, but Google is more and more a content producer. So I'm not sure. Until then, we'll have to rely on servers to bootstrap peer-to-peer networks, even Bitcoin, Bittorrent, and yes, WebRTC.
jnbiche 13y ago
Peer-to-peer connections are possible right now with Chrome and Firefox using WebRTC peerconnection. The WebRTC connection is bootstrapped through a server (STUN and TURN), but that's the case with almost all peer-to-peer software (take a look into how Bitcoin or Bittorrent is bootstrapped if you don't believe me). But anyone can run a STUN and/or TURN server. Once the connection is bootstrapped, it's entirely peer-to-peer between browsers.

by nawitus 13y ago

The internet is decentralized, the web has never been. HTTP protocol doesn't support it. But it's time to do that. What we need is the possibility of peer-to-peer connections between browsers.

foobarqux 13y ago

That doesn't seem nearly as important as having a decentralized data store.

jimktrains2 13y ago

Sure HTTP does. You can cache things, sign things, &c. It's the current philosophy of "web apps" and not "hypertext" that isn't decentralization.

icebraining 13y ago
Web apps are not an issue: https://unhosted.org/ https://unhosted.org/ The problem is not technical, it's social, political and economical.
- dllthomas 13y ago
  Web apps are a bit of an issue, but unhosted web apps are not more of an issue than applications (as opposed to utilities composable in the shell) in general - which is a tremendous improvement.
nawitus 13y ago
Well, technically a browser can listen to incoming connections, but in any case standards don't require it.

sushirain 13y ago

I'm curious, what will that enable?

stingraycharles 13y ago
The same thing as CDN will achieve, just a lot more complex.

icebraining 13y ago

Why do you say HTTP doesn't support it? If a browser doubled as a server, and each person hosted its own pages, how would that not be decentralized and P2P? Hell, it's been done: Opera Unite had just that model, with web pages and applications hosted by the browser itself: http://www.operasoftware.com/press/releases/general/opera-unite-reinvents-the-web http://www.operasoftware.com/press/releases/general/opera-un...

dllthomas 13y ago
The big problem with browser-as-server is that users typically want to power off their browsing devices, while they typically want servers to be always-on. Tying it through a cloud-hosted VPS or some local dedicated device (those wall-wart computers, or something else lightweight and low power but sufficiently capable), but then having the browser talk to it smartly (potentially from several devices simultaneously), would seem a better plan.
- abvdasker 13y ago
  One possible solution is to distribute the hosted content to peers, so that when one person's browser is offline, hopefully someone else's is online to act as a server instead. That doesn't serve as a guarantee, but with a centralized fallback it could work. There are some very clever people already doing this with WebRTC.
  - dllthomas 13y ago
    Right, that works great assuming static content.
- icebraining 13y ago
  People interested in privacy and Free Software are already working on it: https://freedomboxfoundation.org/learn/ https://freedomboxfoundation.org/learn/
  - dllthomas 13y ago

randall 13y ago

http://www.webrtc.org/chrome#TOC-Data-Channels- http://www.webrtc.org/chrome#TOC-Data-Channels-

Gonzih 13y ago

Don't be rude to HTTP, there is no limitations for decentralization in HTTP.

zackmorris 13y ago

While I agree that TCP/IP is decentralized, unfortunately due to NAT and corporate firewalls, vast swaths of users have been relegated to second class citizens who can only act as data consumers. Unfortunately this same misguided approach to security, or as I call it suckerity, has been carried forward into IPv6. There is some hope that WebRTC and other p2p technologies might alleviate the problem but then the task of punching through firewalls with techniques like STUN falls on developers. I'm not seeing an industry-led campaign to standardize a true p2p protocol based on something like UDP, because it would undermine the profits of data producers. I could go into how the proper layering of TCP should have been IP->UDP->TCP instead of IP->TCP and a whole host of technical mistakes such as inability to set the number of checksum bits, use alternatives to TCP header compression, or even use jumbo frames over broadband, but what it all comes down to is that what we think of as “the internet” (connection-oriented reliable streams and the client/server model) is not really compatible with a distributed content-addressable connectionless internet that can work with high latencies and packet loss. I think if this network existed, then extending HTTP to operate in a p2p fashion wouldn’t be all that complicated. Probably the way it would work is that you’d request data by hash instead of by address, and local caches would send you the pieces that match like BitTorrent. Most of the complexity will center around security, but I think Bitcoin and other networks of trust point the way to being able to both prove one’s identity and surf anonymously. Tim Berners-Lee may not be thinking about the problem at this level but we need more people with his clout to get the ball rolling. I wasted a lot of time attempting to write a low-level stream API over UDP for networked games before zeromq or WebRTC existed and ended up failing because there are just too many factors that made it nondeterministic. It’s going to have to be a group effort and will probably require funding or at least a donation of talent from people familiar with the pitfalls to get it right. Otherwise I just don’t think a new standard (one that makes recommendations instead of solving the heart of the problem) is going to catch on.

jnbiche 13y ago
This is exactly the problem. We need a better transport layer. You know, the speed at which SPDY has caught on has given me hope. Admittedly, that's at the application layer, but I think if Google were to get behind an initiative to create a better TCP, it would actually have a chance at working. Historically, Google's incentives were properly aligned with a decentralized Internet, but Google is more and more a content producer. So I'm not sure. Until then, we'll have to rely on servers to bootstrap peer-to-peer networks, even Bitcoin, Bittorrent, and yes, WebRTC.

jnbiche 13y ago

Peer-to-peer connections are possible right now with Chrome and Firefox using WebRTC peerconnection. The WebRTC connection is bootstrapped through a server (STUN and TURN), but that's the case with almost all peer-to-peer software (take a look into how Bitcoin or Bittorrent is bootstrapped if you don't believe me). But anyone can run a STUN and/or TURN server. Once the connection is bootstrapped, it's entirely peer-to-peer between browsers.