9 ms·

Technologies of the Decentralized Web Summit

164 points by tripofmice 10y ago

woah 10y ago
Looks great! I believe that Matrix is actually not blockchain-related
- tripofmice 10y ago
  Thanks, I'll check that out Edit: I moved it to a separate category
  - yarvin9 10y ago
    Urbit too. Thanks!
    - tripofmice 10y ago
      Can you suggest a better general category for Urbit (and perhaps Ethereum as well?) Edit: I have them under "decentralized development platforms" barring a better suggestion
      - deleted 10y ago
        [deleted]
      - state 10y ago
        I think that category fits pretty well!
      - aakilfernandes 10y ago
        "Virtual Machines". Take the blockchain out of Etheruem, and you still have a pretty cool deterministic state-transition machine. My understanding of Urbit is very limited, but I believe it has a similar concept of Ethereum without a consensus protocol.
        natrius 10y ago
        They're probably worth distinguishing somehow for newcomers. They're both transaction logs. Ethereum is a transaction log with a consensus mechanism. Anyone can append to it. It's a scroll: any group or society can use apps that check the scroll to come to conclusions about the state of their interactions. Urbit is a transaction log that only the owner can append to. It's a journal: users can safely append to their journal with any app, and their apps can read the whole journal to display data from multiple apps in desirable ways.
        aakilfernandes 10y ago
        Which begs the question, why is Urbit necessary? It would be relatively simple to port Ethereum's consensus protocol to "only a user with key X can sign new blocks" and each block would contain exactly 1 transaction.
        yarvin9 10y ago
        Mainly because (as Vitalik says) "the whole Ethereum network has the power of a 1999 cell phone." Although Urbit (like Ethereum) is precisely defined without dependencies, Urbit is not a consensus computation platform. It's for processing your own data on your own (virtual or physical) machine. Consensus computing is incredibly inefficient and should be used only where absolutely required. Where consensus is not absolutely required, computing should be localized under the user's control. People often forget to include this component in their designs of the decentralized future. But in fact, Ethereum needs something like Urbit and vice versa. One way to think about the difference between Ethereum and Urbit: it's like the difference between a superconductor and a regular conductor. On the one hand, superconductors are qualitatively different and fundamentally more powerful. On the other hand, there are no superconductors in your iPhone.
        Natanael_L 10y ago
        Right now I have somewhat more faith in PHB's mathematical mesh: https://tools.ietf.org/html/draft-hallambaker-mesh-developer-00 https://tools.ietf.org/html/draft-hallambaker-mesh-developer...
      - muneeb 10y ago
        I'd actually put Blockstack in the same category as Ethereum. From a transactional log perspective, it uses the Bitcoin blockchain for consensus on the log and from an application development perspective, you can build apps using Blockstack (gives you naming, auth, and storage).
- mappum 10y ago
  Same as IPFS, which should probably be in the "Decentralized Web" category.
  - Natanael_L 10y ago
    Technically it uses hash chains which blockchains are based on, so it is tangentially related. But IPFS is basically just Git (also using hash chains) with networking addons, no concensus algorithm (none needed).
SnappGamez 10y ago
I love the idea of a decentralized internet. I mean we already have cryptocurrencies that are decentralized, why not have that as well?
pfraze 10y ago
Out of these, I thought Zeronet had the best demo. Dat and IPFS are both very promising. I also thought Matrix and Interledger show a lot of potential.
bobajeff 10y ago
Althea Mesh sounds like a great idea.
- woah 10y ago
  I'd love to get your input on the in progress whitepaper!
pnathan 10y ago
Nearly all of these relate to blockchain tech. Which is interesting. I do ask: why blockchain? Are modern blockchains still cycling away on silicon to find hashes? Seems a terrifically ineffecient way to build a system. I can understand the distributed hash table / transaction tree idea, but I struggle to grasp the rationale for proof of work systems.
- wmf 10y ago
  Proof of work is the only known way to achieve consensus among entities that don't trust anyone. It also provides a way to "fairly" distribute new currency among entities who don't trust anyone. It's not clear to me that the decentralized Web needs consensus, its own currency, or total lack of trust.
  - jpetso 10y ago
    Which is why I like layered approaches like IPFS that separate the merkle-tree layer (hashed content) from the naming layer (IPNS, DNS, Namecoin, etc.). There are definitely valid uses of blockchain tech but requiring it as central part of the architecture is a recipe for (re)centralization because eventually it will always grow beyond home-computer scale.
  - pnathan 10y ago
    > It's not clear to me that the decentralized Web needs consensus, its own currency, or total lack of trust. I'm pretty sure I would say that the above is not how things work in human society. Limited trust, fiat currency, and regular disagreements is the norm.
- wyager 10y ago
  There is no other known effective defense against Sybil attacks in fully decentralized systems.
  - uudecode 10y ago
    Sybil attacks do not work in small communities that members may choose to form where the members already know each other. If a system forces all users to be part of some large, Borg-like, distributed hash table, or ledger, then by my definition it's not "fully decentralized".
asragab 10y ago
Watching the recorded feed from this summit is kind of nuts. You have Vint Cerf (co-inventor of TCP/IP) providing Q&A about a distributed digital archive of the internet and the first guy to ask a question is Carl Hewitt (developer of the Actor Model) and then the guy looking over his shoulder at Carl is Tim Berners-Lee (some web dude).
- NotUsingLinux 10y ago
  yes but apps? Apps are just a relict of the mobile 1.0 area, which should be dissolved by web 3.0. yes the monopolgies build their devices and used them to create more monopolies. It should be eventually by models of hardware/software symbioses which gets more benefits from collaborating (blockchain backends). Its very good to see a lot of blockchain related projects at the conference, the path to web 3.0 is open!
api 10y ago
So wish we could have made it to this. In any case ZeroTier was conceived with Internet decentralization motives in mind specifically with the goal of making edge device connectivity easy. It can be and is used for other things but that was the original motive. https://www.zerotier.com/ https://www.zerotier.com/ /no relation to ZeroNet, didn't know about that when I named it.
- nickpsecurity 10y ago
  Nice work you people are doing. I have no opinion on features and stuff ATM except to say that VPN's plus high usability and open source is a category I like seeing expand. Far as this list, I think what keeps you off is this: "ZeroTier endpoint nodes form a peer to peer network and use a set of pre-configured nodes called root servers (currently run by us, federation is planned) as stable anchor points for near-instantaneous zero-configuration peer location and connection setup." Still centralized. Solve that then you might get on the list.
  - api 10y ago
    We wanted to build something useful in mainstream, casual, and commercial applications, not just for geeks. For that reason we took on the following non-negotiable design requirements: - An endpoint can join the network in <~10s. No bootstrapping time. - Any endpoint can reach any other endpoint in the world in <~10s (or less). - No configuration at all is required. It "just works." Any knob that must be tweaked or config that must be entered is a bug. - The endpoint must be small enough to fit in an embedded device like a thermostat, light bulb, etc. (Or at least be able to be made that small without inordinate levels of pain.) - Performance overhead must be on par with e.g. OpenVPN, GRE/IPSec, etc. - Must be mobile-friendly. (phones, tablets, etc.) - Must not conscript user devices into infrastructure roles without explicit opt-in. - Very strong resistance to sybil and DDOS attacks, at least comparable to current Internet BGP community. - It must be able to scale to Internet size (tens of billions of devices) without disproportionate levels of pain or discontinuities where the system suddenly "melts down." - The design must be simple enough to fully describe in a relatively concise RFC. - The design should be no more centralized than other common Internet systems like DNS and BGP. The current design satisfies all those goals. It's zero-config, runs on phones with minimal battery life impact, could be scaled down to embedded code and memory footprints without too terribly much effort, and is no more centralized than DNS or BGP. I'm not sure if I see the intrinsic advantage of trying to be less centralized than the Internet while still using the Internet for transport. A true decentralized new-Internet would have to use radio and user-provisioned DIY links. Centralization(X) = max(Centralization(all parts of(X))) Pretty much everything popular right now in the decentralized Internet community is conclusively "out" for mobile and embedded use outside of niche applications where the user doesn't mind their phone becoming a hand-warmer and their battery life dropping to 45 minutes. In particular we almost certainly rule out: - DHTs -- too much RAM, too slow, have a warmup/bootstrap time, hard to harden against sybil attacks, and solutions to these problems involve root-server-like centralization anyway so we're back where we started. - Block chain -- way too compute and storage intensive by many orders of magnitude. - Rumor mill and other noisy protocols -- way too bandwidth intensive for mobile and small devices, don't scale. - Aggressive data replication and "raft consensus" type stuff -- too much storage and network overhead for mobile and embedded devices. Right now our thinking revolves around making it possible to locally federate the root servers for on-site or in-personal-cloud use. But this has to be thought out very carefully so as not to negatively impact security or any of the other constraints above. We can't have people setting up sybil roots that can be used to DOS the network. Our other thought is to create a separate community-driven institution to hold the root infrastructure. This is fraught with non-technical political difficulties of making sure this institution is well governed and sustainable. See also: https://www.zerotier.com/misc/2011__A_Little_Centralization__Tsitsiklis_Xu.pdf https://www.zerotier.com/misc/2011__A_Little_Centralization_... https://en.wikipedia.org/wiki/CAP_theorem https://en.wikipedia.org/wiki/CAP_theorem http://adamierymenko.com/decentralization-i-want-to-believe/ http://adamierymenko.com/decentralization-i-want-to-believe/ https://whispersystems.org/blog/the-ecosystem-is-moving/ https://whispersystems.org/blog/the-ecosystem-is-moving/ The latter post makes excellent points and gives us significant pause about federation and delegation. We have to be able to keep improving things and to respond to threats (e.g. DDOS) rapidly. -- Edit: meta: I tend to disagree philosophically with the lack of pragmatism in the Internet decentralization community. It reminds me of OSI, which had some theoretically-superior ideas about networking but which never actually shipped anything that worked at scale. As a result we have IP, which works well but lacks some of the theoretical benefits of more throughly designed systems. Things that work always win over things that don't work. See also: semantic web vs. web+search, Project Xanadu vs. www. Right now the dominant paradigm online is highly centralized cloud silo networks where all traffic is MITMed by design. I think making it trivially easy to network endpoints with an end-to-end encrypted network that "just works" is a huge improvement and could enable a lot of other things. Also note that ZT carries standard protocols over standard virtualized networks: IPv4, IPv6, etc. This means that it doesn't impose lock-in on systems built with it. It's just neutral transport.
di4na 10y ago
While i love the idea of a Decentralised Internet, i would say that it does not solve the problems that well. An awful lot of these techs are completely block-chain and consensus dependant. Which makes sense (you are in a byzantine environment after all) but is far from being a solved, ready to be used idea. Really far. And that is awfully unefficeint in term of power. Additionally, except the wifi router project, none of them really solve anything. It just push the boundaries a bit. I still like the fact we have people working on it, and i will keep working toward it, but we are so so far from solutions. Still super nice to see some of the things here. Thanks for the hard work :)
- teddyh 10y ago
  Indeed it has been said that decentralization is the worst form of networking except all those other forms that have been tried from time to time. (With apologies to Winston Churchill.)
mstade 10y ago
> IPFS, or InterPlanetary File System, is a distributed file storage system that aims to replace HTTP. Both the Internet Archive and Neocities serve web content with IPFS. Can someone explain to someone less smart (i.e. me) why IPFS and HTTP are mutually exclusive, as the above description seems to suggest?
- bergie 10y ago
  They're completely different protocols. But the IPFS daemon can serve as a IPFS-to-HTTP gateway to make IPFS content available to web browsers.
  - mstade 10y ago
    No sure, I understand they are different protocols, but unless IPFS turns into a protocol capable of describing application semantics (which is what HTTP is) then I don't see how it can possibly replace HTTP – file transfer is not its main purpose after all. What I'm saying, I guess, is that I don't understand why HTTP and IPFS can't coexist quite peacefully? I.e. IPFS being a lower level transport protocol upon which HTTP provides application semantics. Or is that the aim? I don't fully understand.
    - nickpsecurity 10y ago
      HTTP is a centralized protocol. IPFS is a decentralized protocol. It's considered a core requirement of the replacement protocol by these people. So, HTTP can't fit the bill.
    - db48x 10y ago
      They coexist already. IPFS just gives you a standardized way to store files in a global p2p content-addressable filesystem (or private content-addressable filesystems, if you don't connect your IPFS server to the global network). Imagine if you tried to visit news.ycombinator.com via HTTPS while visiting Mars; the timeouts would have to be quite large. If instead the static assets, like html, javascript, comments, and stories are stored in IPFS, then you can load them from your local IPFS server node instead. You would probably even access that node via HTTP(S), and in principle the URL in your urlbar would be exactly the same as it is now. The rendering would all have to be done in JS though, which is a bit of a change. You would configure your local IPFS node to periodically update it's local cache so that the site is as up to date as you desire. (There's some handwaving there, but I guess you could just use a cronjob to request the content, forcing it to be cached.) In practice, posting a story or a comment might have to look a rather different in that implementation. It would probably look like a throwback to UUCP or FidoNet, where distant nodes would contact each other regularly to upload messages. You would use PKI to discard messages from non-users, and linking the good ones into your branch of the filesystem so that viewers could see them. Things like this that require logins are where most of the handwaving is with IPFS; the actual filesystem parts seem to work pretty well.

164 points by tripofmice 10y ago

woah 10y ago

Looks great! I believe that Matrix is actually not blockchain-related

tripofmice 10y ago
Thanks, I'll check that out Edit: I moved it to a separate category
- yarvin9 10y ago
  Urbit too. Thanks!
  - tripofmice 10y ago
    Can you suggest a better general category for Urbit (and perhaps Ethereum as well?) Edit: I have them under "decentralized development platforms" barring a better suggestion
    - deleted 10y ago
      [deleted]
    - state 10y ago
      I think that category fits pretty well!
    - aakilfernandes 10y ago
      "Virtual Machines". Take the blockchain out of Etheruem, and you still have a pretty cool deterministic state-transition machine. My understanding of Urbit is very limited, but I believe it has a similar concept of Ethereum without a consensus protocol.
      - natrius 10y ago
        They're probably worth distinguishing somehow for newcomers. They're both transaction logs. Ethereum is a transaction log with a consensus mechanism. Anyone can append to it. It's a scroll: any group or society can use apps that check the scroll to come to conclusions about the state of their interactions. Urbit is a transaction log that only the owner can append to. It's a journal: users can safely append to their journal with any app, and their apps can read the whole journal to display data from multiple apps in desirable ways.
        aakilfernandes 10y ago
        Which begs the question, why is Urbit necessary? It would be relatively simple to port Ethereum's consensus protocol to "only a user with key X can sign new blocks" and each block would contain exactly 1 transaction.
        yarvin9 10y ago
        Mainly because (as Vitalik says) "the whole Ethereum network has the power of a 1999 cell phone." Although Urbit (like Ethereum) is precisely defined without dependencies, Urbit is not a consensus computation platform. It's for processing your own data on your own (virtual or physical) machine. Consensus computing is incredibly inefficient and should be used only where absolutely required. Where consensus is not absolutely required, computing should be localized under the user's control. People often forget to include this component in their designs of the decentralized future. But in fact, Ethereum needs something like Urbit and vice versa. One way to think about the difference between Ethereum and Urbit: it's like the difference between a superconductor and a regular conductor. On the one hand, superconductors are qualitatively different and fundamentally more powerful. On the other hand, there are no superconductors in your iPhone.
        Natanael_L 10y ago
        Right now I have somewhat more faith in PHB's mathematical mesh: https://tools.ietf.org/html/draft-hallambaker-mesh-developer-00 https://tools.ietf.org/html/draft-hallambaker-mesh-developer...
    - muneeb 10y ago
      I'd actually put Blockstack in the same category as Ethereum. From a transactional log perspective, it uses the Bitcoin blockchain for consensus on the log and from an application development perspective, you can build apps using Blockstack (gives you naming, auth, and storage).
mappum 10y ago
Same as IPFS, which should probably be in the "Decentralized Web" category.
- Natanael_L 10y ago
  Technically it uses hash chains which blockchains are based on, so it is tangentially related. But IPFS is basically just Git (also using hash chains) with networking addons, no concensus algorithm (none needed).

SnappGamez 10y ago

I love the idea of a decentralized internet. I mean we already have cryptocurrencies that are decentralized, why not have that as well?

pfraze 10y ago

Out of these, I thought Zeronet had the best demo. Dat and IPFS are both very promising. I also thought Matrix and Interledger show a lot of potential.

bobajeff 10y ago

Althea Mesh sounds like a great idea.

woah 10y ago
I'd love to get your input on the in progress whitepaper!

pnathan 10y ago

Nearly all of these relate to blockchain tech. Which is interesting. I do ask: why blockchain? Are modern blockchains still cycling away on silicon to find hashes? Seems a terrifically ineffecient way to build a system. I can understand the distributed hash table / transaction tree idea, but I struggle to grasp the rationale for proof of work systems.

wmf 10y ago
Proof of work is the only known way to achieve consensus among entities that don't trust anyone. It also provides a way to "fairly" distribute new currency among entities who don't trust anyone. It's not clear to me that the decentralized Web needs consensus, its own currency, or total lack of trust.
- jpetso 10y ago
  Which is why I like layered approaches like IPFS that separate the merkle-tree layer (hashed content) from the naming layer (IPNS, DNS, Namecoin, etc.). There are definitely valid uses of blockchain tech but requiring it as central part of the architecture is a recipe for (re)centralization because eventually it will always grow beyond home-computer scale.
- pnathan 10y ago
  > It's not clear to me that the decentralized Web needs consensus, its own currency, or total lack of trust. I'm pretty sure I would say that the above is not how things work in human society. Limited trust, fiat currency, and regular disagreements is the norm.
wyager 10y ago
There is no other known effective defense against Sybil attacks in fully decentralized systems.
- uudecode 10y ago
  Sybil attacks do not work in small communities that members may choose to form where the members already know each other. If a system forces all users to be part of some large, Borg-like, distributed hash table, or ledger, then by my definition it's not "fully decentralized".

asragab 10y ago

Watching the recorded feed from this summit is kind of nuts. You have Vint Cerf (co-inventor of TCP/IP) providing Q&A about a distributed digital archive of the internet and the first guy to ask a question is Carl Hewitt (developer of the Actor Model) and then the guy looking over his shoulder at Carl is Tim Berners-Lee (some web dude).

NotUsingLinux 10y ago
yes but apps? Apps are just a relict of the mobile 1.0 area, which should be dissolved by web 3.0. yes the monopolgies build their devices and used them to create more monopolies. It should be eventually by models of hardware/software symbioses which gets more benefits from collaborating (blockchain backends). Its very good to see a lot of blockchain related projects at the conference, the path to web 3.0 is open!

api 10y ago

So wish we could have made it to this. In any case ZeroTier was conceived with Internet decentralization motives in mind specifically with the goal of making edge device connectivity easy. It can be and is used for other things but that was the original motive. https://www.zerotier.com/ https://www.zerotier.com/ /no relation to ZeroNet, didn't know about that when I named it.

nickpsecurity 10y ago
Nice work you people are doing. I have no opinion on features and stuff ATM except to say that VPN's plus high usability and open source is a category I like seeing expand. Far as this list, I think what keeps you off is this: "ZeroTier endpoint nodes form a peer to peer network and use a set of pre-configured nodes called root servers (currently run by us, federation is planned) as stable anchor points for near-instantaneous zero-configuration peer location and connection setup." Still centralized. Solve that then you might get on the list.
- api 10y ago
  We wanted to build something useful in mainstream, casual, and commercial applications, not just for geeks. For that reason we took on the following non-negotiable design requirements: - An endpoint can join the network in <~10s. No bootstrapping time. - Any endpoint can reach any other endpoint in the world in <~10s (or less). - No configuration at all is required. It "just works." Any knob that must be tweaked or config that must be entered is a bug. - The endpoint must be small enough to fit in an embedded device like a thermostat, light bulb, etc. (Or at least be able to be made that small without inordinate levels of pain.) - Performance overhead must be on par with e.g. OpenVPN, GRE/IPSec, etc. - Must be mobile-friendly. (phones, tablets, etc.) - Must not conscript user devices into infrastructure roles without explicit opt-in. - Very strong resistance to sybil and DDOS attacks, at least comparable to current Internet BGP community. - It must be able to scale to Internet size (tens of billions of devices) without disproportionate levels of pain or discontinuities where the system suddenly "melts down." - The design must be simple enough to fully describe in a relatively concise RFC. - The design should be no more centralized than other common Internet systems like DNS and BGP. The current design satisfies all those goals. It's zero-config, runs on phones with minimal battery life impact, could be scaled down to embedded code and memory footprints without too terribly much effort, and is no more centralized than DNS or BGP. I'm not sure if I see the intrinsic advantage of trying to be less centralized than the Internet while still using the Internet for transport. A true decentralized new-Internet would have to use radio and user-provisioned DIY links. Centralization(X) = max(Centralization(all parts of(X))) Pretty much everything popular right now in the decentralized Internet community is conclusively "out" for mobile and embedded use outside of niche applications where the user doesn't mind their phone becoming a hand-warmer and their battery life dropping to 45 minutes. In particular we almost certainly rule out: - DHTs -- too much RAM, too slow, have a warmup/bootstrap time, hard to harden against sybil attacks, and solutions to these problems involve root-server-like centralization anyway so we're back where we started. - Block chain -- way too compute and storage intensive by many orders of magnitude. - Rumor mill and other noisy protocols -- way too bandwidth intensive for mobile and small devices, don't scale. - Aggressive data replication and "raft consensus" type stuff -- too much storage and network overhead for mobile and embedded devices. Right now our thinking revolves around making it possible to locally federate the root servers for on-site or in-personal-cloud use. But this has to be thought out very carefully so as not to negatively impact security or any of the other constraints above. We can't have people setting up sybil roots that can be used to DOS the network. Our other thought is to create a separate community-driven institution to hold the root infrastructure. This is fraught with non-technical political difficulties of making sure this institution is well governed and sustainable. See also: https://www.zerotier.com/misc/2011__A_Little_Centralization__Tsitsiklis_Xu.pdf https://www.zerotier.com/misc/2011__A_Little_Centralization_... https://en.wikipedia.org/wiki/CAP_theorem https://en.wikipedia.org/wiki/CAP_theorem http://adamierymenko.com/decentralization-i-want-to-believe/ http://adamierymenko.com/decentralization-i-want-to-believe/ https://whispersystems.org/blog/the-ecosystem-is-moving/ https://whispersystems.org/blog/the-ecosystem-is-moving/ The latter post makes excellent points and gives us significant pause about federation and delegation. We have to be able to keep improving things and to respond to threats (e.g. DDOS) rapidly. -- Edit: meta: I tend to disagree philosophically with the lack of pragmatism in the Internet decentralization community. It reminds me of OSI, which had some theoretically-superior ideas about networking but which never actually shipped anything that worked at scale. As a result we have IP, which works well but lacks some of the theoretical benefits of more throughly designed systems. Things that work always win over things that don't work. See also: semantic web vs. web+search, Project Xanadu vs. www. Right now the dominant paradigm online is highly centralized cloud silo networks where all traffic is MITMed by design. I think making it trivially easy to network endpoints with an end-to-end encrypted network that "just works" is a huge improvement and could enable a lot of other things. Also note that ZT carries standard protocols over standard virtualized networks: IPv4, IPv6, etc. This means that it doesn't impose lock-in on systems built with it. It's just neutral transport.

di4na 10y ago

While i love the idea of a Decentralised Internet, i would say that it does not solve the problems that well. An awful lot of these techs are completely block-chain and consensus dependant. Which makes sense (you are in a byzantine environment after all) but is far from being a solved, ready to be used idea. Really far. And that is awfully unefficeint in term of power. Additionally, except the wifi router project, none of them really solve anything. It just push the boundaries a bit. I still like the fact we have people working on it, and i will keep working toward it, but we are so so far from solutions. Still super nice to see some of the things here. Thanks for the hard work :)

teddyh 10y ago
Indeed it has been said that decentralization is the worst form of networking except all those other forms that have been tried from time to time. (With apologies to Winston Churchill.)

mstade 10y ago

> IPFS, or InterPlanetary File System, is a distributed file storage system that aims to replace HTTP. Both the Internet Archive and Neocities serve web content with IPFS. Can someone explain to someone less smart (i.e. me) why IPFS and HTTP are mutually exclusive, as the above description seems to suggest?

bergie 10y ago
They're completely different protocols. But the IPFS daemon can serve as a IPFS-to-HTTP gateway to make IPFS content available to web browsers.
- mstade 10y ago
  No sure, I understand they are different protocols, but unless IPFS turns into a protocol capable of describing application semantics (which is what HTTP is) then I don't see how it can possibly replace HTTP – file transfer is not its main purpose after all. What I'm saying, I guess, is that I don't understand why HTTP and IPFS can't coexist quite peacefully? I.e. IPFS being a lower level transport protocol upon which HTTP provides application semantics. Or is that the aim? I don't fully understand.
  - nickpsecurity 10y ago
    HTTP is a centralized protocol. IPFS is a decentralized protocol. It's considered a core requirement of the replacement protocol by these people. So, HTTP can't fit the bill.
  - db48x 10y ago
    They coexist already. IPFS just gives you a standardized way to store files in a global p2p content-addressable filesystem (or private content-addressable filesystems, if you don't connect your IPFS server to the global network). Imagine if you tried to visit news.ycombinator.com via HTTPS while visiting Mars; the timeouts would have to be quite large. If instead the static assets, like html, javascript, comments, and stories are stored in IPFS, then you can load them from your local IPFS server node instead. You would probably even access that node via HTTP(S), and in principle the URL in your urlbar would be exactly the same as it is now. The rendering would all have to be done in JS though, which is a bit of a change. You would configure your local IPFS node to periodically update it's local cache so that the site is as up to date as you desire. (There's some handwaving there, but I guess you could just use a cronjob to request the content, forcing it to be cached.) In practice, posting a story or a comment might have to look a rather different in that implementation. It would probably look like a throwback to UUCP or FidoNet, where distant nodes would contact each other regularly to upload messages. You would use PKI to discard messages from non-users, and linking the good ones into your branch of the filesystem so that viewers could see them. Things like this that require logins are where most of the handwaving is with IPFS; the actual filesystem parts seem to work pretty well.