31–40 of 48 posts
Can someone explain to someone less smart (i.e. me) why IPFS and HTTP are mutually exclusive, as the above description seems to suggest?
> 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?
> 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?
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.
Earlier quoted context omitted.
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".
Indeed, if you don't plan on writing distributed systems that work for more than a few people, you don't need to worry about Sybil attacks. However, the nice thing about the internet is that it connects billions of people, so here we are.
Today, people can, in theory, choose from among billions of peers to form these small groups. And the groups can if they so choose connect with each other, via a network of networks.
This internet "connects billions of people". True. But your company's LAN probably does not connect that many.
If a user started creating numerous fake identities on the LAN, then it's likely she would be detected.
Is it possible to create distributed "LANs" over the internet? (rhetorical question)
Another commenter questioned why a distributed Web needs "lack of trust".
People in small groups can and do trust each other. No computers are needed to make this happen.
Earlier quoted context omitted.
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.
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 whic…
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.
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.
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.
Earlier quoted context omitted.
Indeed, if you don't plan on writing distributed systems that work for more than a few people, you don't need to worry about Sybil attacks. However, the nice thing about the internet is that it connects billions of people, so here we are.
I think there's a lot of historical evidence over the last few thousand years that people naturally form small communities, or at least small groups within large communities. Today, people can, in theory, choose from among billions of peers to form these small groups. And the groups can if they so choose connect with each other, via a network of networks. This internet "connects billions of people". True. But your co…
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/ /no relation to ZeroNet, didn't know about that when I named it.
"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.
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/ /no relation to ZeroNet, didn't know about that when I named it.
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-inst…
- An endpoint can join the network in - Any endpoint can reach any other endpoint in the world in - 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_...
https://en.wikipedia.org/wiki/CAP_theorem
http://adamierymenko.com/decentralization-i-want-to-believe/
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.
Earlier quoted context omitted.
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.
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 whic…
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.