We’ve had enough of digital monopolies and surveillance capitalism. We want an alternative world that works for everyone, just like the original intention of the web and net.
We seek a world of open platforms and protocols with real choices of applications and services for people. We care about privacy, transparency and autonomy. Our tools and organisations should fundamentally be accountable and resilient.
It's a bit of a grey area, but I really don't think of it as a VPN. A VPN is typically used to connect two networks together, or to allow a disconnected client to incorporate itself into a network. ZT1's networks are first-order entities.Think of it as being like the difference between a VNC client and a virtual machine. Both allow you to use a different operating system on your local desktop. The first is a client that connects you to one running somewhere else, while the second actually runs one virtually.The closest thing out there to ZT1 is probably LogMeIn Hamachi, but it's closed-source and aimed at the "enterprise" market. (Which I view as something to be avoided.) I have intentionally never downloaded or tried Hamachi because I don't want to po llute my mind with other close-but-not-exactly-the-same ideas.On Jan 6, 2014, at 11:46 AM, Paul Frazee <email@example.com> wrote:So how does it differ from most VPNs?On Mon, Jan 6, 2014 at 1:40 PM, Adam Ierymenko <firstname.lastname@example.org> wrote:
I absolutely agree.As I've designed ZeroTier One I've had an eye toward further decentralization, designing the protocol so that it will be achievable with as little pain as possible. I have a mental image of what it might look like, and the protocol is designed to enable it with only the addition of new message types-- existing protocol messages should work fine and not need to be altered much (if at all).A bit about the ZT1 design:Supernodes in ZeroTier One are just regular nodes running the exact same code as the regular client that are running on fast cloud providers (Digital Ocean in this case) and designated as such. In Defaults.cpp there is a hard-coded list at the moment that designates three supernodes in three differ ent cities. More will probably be added in the future.Network IDs are 64-bit numbers composed of the 40-bit ZeroTier address of the "netconf master" for the network and a random 24-bit ID. The netconf master is a node resposible for doing things like distributing configuration, creating and signing authentication certificates for private network membership, and assigning IP addresses. This too runs the same code as regular clients plus a service located in netconf-service/ in the source tree. You're free to examine it. The netconf master can be made high-availability by setting up fail-over nodes in different data centers so that if it goes down another one will pop up. It only needs to be consulted periodically by peers so a few minutes of downtime doesn't affect anyone much.All the authentication is based around 256-bit ECC cryptography. All communications between peers are encrypted end-to-end, so while supernodes can see *that* you are communicating (unless you successfully NAT-traverse and connect directly) but cannot read your traffic. Relay nodes assist in NAT traversal by sending a RENDEZVOUS message to both peers periodically if they are being relayed that says "hey, you two, go talk to each other <here>." This enables reliable and very simple NAT-t. So far it seems to work well.The networks really are virtual Ethernets. Everything works, including multicast. If there are too many members for everyone to get every multicast, it degrades gracefully by propagating multicasts to multicast subscribers that are more frequent partners in communication. I chose to virtualize at layer 2 because this enables any protocol to work... you could even play IPX LAN games over this. :)On Jan 6, 2014, at 11:18 AM, Paul Frazee <email@example.com> wrote:I'm working on a WebRTC system, and I've basically made the same tradeoffs. You need a central coordinator for WebRTC's signalling, so I'm running a public one, and then the server can be downloaded and self-administered for the super hard-core. I agree physical decentralization isn't important enough for most Web users to prioritize this early in the game, but we can make our way toward it incrementally.On Mon, Jan 6, 2014 at 12:51 PM, Adam Ierymenko <firstname.lastname@example.org> wrote:
ZeroTier is a semi-decentralized system at the moment from a technical point of view. There's three reasons for that:(1) Sort of like the common optimization advice of "make it work, then make it fast," I'm pursuing a strategy of "make it work, then make it more decentralized." There seems to be an exponential difficulty curve re: *completely* decentralizing a protocol and that in turn comes from some fundamental constraints in information theory such as the CAP theorem. My goal is for ZeroTier One to be reliable, zero-configuration, and very fast, and doing that without any centralized POP is really hard. In the future it would be possible to further decentralize the protocol by introducing something like a fast Kad network, a trust system for selecting supernodes in a decentr alized manner, etc.(2) I do plan to have both an open source / free component and a commercial component. ZeroTier One supports the creation of arbitrary distributed LANs. There will be a few public wide-open ones that will be free for unlimited use, but you can also create private distributed LANs. I plan to charge users to create private distributed LANs that are administrated by ZeroTier's own servers... basically you're paying for a reliable infrastructure that I manage and a nice web GUI to admin them. Nothing prevents you from running your own netconf-master but you'd have to create your own mysql database and admin everything yourself and most commercial users don't want to do that.(3) I actually view operational decentralization as being more fundamental and more important than infrastructure decentralization.#3 is sort of a philosophical point. Basically I think it's more important to enable later al communication functionally than to physically decentralize the network. I'm not saying the latter isn't important... just that it's a lot harder to achieve and has little value without the former. If nobody is developing peer to peer apps that really leverage an operationally decentralized network, then if we did create a truly physically decentralized network there would be no "killer apps" for it. It wouldn't go anywhere.This is why one of my goals with this project is to make p2p lateral communication easy on public virtual LANs. The fact that peers use a set of centralized servers to find each other is IMHO secondary... making lateral communication easy enables people to easily develop killer apps that want to talk laterally. Once these exist, the tail will wag the dog.What do I mean by this distinction?Functional decentralization means I can run any app you can, I own my data, and we can make direct connections without a third party arbiter being able to control what we do or say. For example, if we were on a functionally decentralized network I could type:ping <your IP address>... and directly ping your box.Physical decentralization means that no central point of failure exists... that I can ping your box regardless of whether someone somewhere else turns off their system. Obviously this is technically a lot harder to achieve and without functional decentralization what's the point?On Jan 6, 2014, at 10:40 AM, Paul Frazee <email@example.com> wrote:Hey Adam,ZeroTier has been high on my watch-list. Very interesting project. I'm guessing because of the subscription model that it has some central coordinator?What I imagine doing with ZeroTier is running private web services and distributing the names ("http://couchdb.paul") among my virtual LAN. Is that feasible?PaulOn Mon, Jan 6, 2014 at 12:30 PM, Adam Ierymenko <firstname.lastname@example.org> wrote:
Hey redcentralize list... just introducing myself. I'm Adam Ierymenko, author of ZeroTier One and one of the redecentralize.org interviewees. You can view my work here:
I live in Lake Forest, California and have listed myself as the POC for anyone who wants to start a meetup in the Los Angeles / Orange County / Riverside metro area. Drop me an e-mail if you live anywhere around here. :)