3 ms·

I have a slight issue with the title, why not IPFS over HTTP? Why are all these entites (both corporate and not) trying to deprecate the main protocol used by h

by bullen 5y ago

I have a slight issue with the title, why not IPFS over HTTP? Why are all these entites (both corporate and not) trying to deprecate the main protocol used by humans? HTTP is simple and works, what ever you do build on top of HTTP instead of TCP/UDP.

detaro 5y ago
HTTP would be an odd choice for a dynamic peer-to-peer protocol like IPFS.
- bullen 5y ago
  It might seem like it at first, but P2P always needs a peer finder, and that should be HTTP. I predict that in a relatively short timespan everyone will host a HTTP server on their port 80 atleast those that can get an external IPv4 address before the cost starts surging. The point is: port 80 is and should be open. When you do other ports and protocols you never know what the IPS/router/firewall/OS is going to block. But if IPv6 ever reaches inertial mass you are right! Edit: As far as IPFS is concerned we allready have bittorrent and that uses HTTP so their point is moot, I'm driving another tangent though: Everything that can be HTTP, should be HTTP; and to proove it I made the most scalable multiplayer protocol: http://fuse.rupy.se/about.html http://fuse.rupy.se/about.html
  - detaro 5y ago
    Expecting a server on an external port is already quite limited, plenty users that can't do that for various reasons. Bittorrent also doesn't use HTTP for the P2P parts.
    - bullen 5y ago
      Sure, and that is the real battle, who can get an external IP! Yep, I'm ok with the P2P stuff to be over UDP, but if you ever made UDP hole-punching work you will realize it's not necessarily the most straight forward solution. P2P does not scale for all problems, while distributed client/server does! The bottleneck never was network bandwidth (binary vs. text), it's been atomic parallelism since multi-core processors peaked in concurrent RAM bandwidth 2014+ after DDR4 increased latency. Copying files is not a problem because you can always make files smaller by reducing quality!

by bullen 5y ago

detaro 5y ago

HTTP would be an odd choice for a dynamic peer-to-peer protocol like IPFS.

bullen 5y ago
It might seem like it at first, but P2P always needs a peer finder, and that should be HTTP. I predict that in a relatively short timespan everyone will host a HTTP server on their port 80 atleast those that can get an external IPv4 address before the cost starts surging. The point is: port 80 is and should be open. When you do other ports and protocols you never know what the IPS/router/firewall/OS is going to block. But if IPv6 ever reaches inertial mass you are right! Edit: As far as IPFS is concerned we allready have bittorrent and that uses HTTP so their point is moot, I'm driving another tangent though: Everything that can be HTTP, should be HTTP; and to proove it I made the most scalable multiplayer protocol: http://fuse.rupy.se/about.html http://fuse.rupy.se/about.html
- detaro 5y ago
  Expecting a server on an external port is already quite limited, plenty users that can't do that for various reasons. Bittorrent also doesn't use HTTP for the P2P parts.
  - bullen 5y ago
    Sure, and that is the real battle, who can get an external IP! Yep, I'm ok with the P2P stuff to be over UDP, but if you ever made UDP hole-punching work you will realize it's not necessarily the most straight forward solution. P2P does not scale for all problems, while distributed client/server does! The bottleneck never was network bandwidth (binary vs. text), it's been atomic parallelism since multi-core processors peaked in concurrent RAM bandwidth 2014+ after DDR4 increased latency. Copying files is not a problem because you can always make files smaller by reducing quality!