4 ms·

It's similar to the original pre-Microsoft design in many ways, but ZT is actually less asymmetrical in that client and "server" run the same code. A supernode

by api 12y ago

It's similar to the original pre-Microsoft design in many ways, but ZT is actually less asymmetrical in that client and "server" run the same code. A supernode is just a regular node blessed as such. (And at a fixed address with a lot of bandwidth.) Supernodes are important because they permit instant on, rapid lookup, and almost instant nat traversal. They also bridge sparse multicast groups as described here. https://github.com/zerotier/ZeroTierOne/wiki/Multicast-Algorithm-Notes https://github.com/zerotier/ZeroTierOne/wiki/Multicast-Algor... Both Skype and Spotify have backed away from p2p. In Skype's case I suspect PRISM. I don't know why in the case of Spotify. That seems like an ideal application. Since a file is not a moving target, a lot of the problems in distributed databases disappear. That's why BitTorrent magnet links van work pretty well, though I bet a determined attacker could Sybil the Kad DHT to death.

walterbell 12y ago
Would there be any benefit in allowing users to optionally choose supernodes, e.g. providing ways for supernodes to disclose identify information or even to run a business the way VPN/proxies do today? In other words, if some nodes have to be centralized for technical reasons, apply a decentralized, Web-of-Trust, out of band, policy/reputation approach to governance and auditing the identity of the supernode operators. E.g. Supernode N is in City A, owned by Person B, regulated by Country C, packet-inspected by ISP D, and is vouched for by the following list of DevOps infrastructure auditors.
- api 12y ago
  It would fragment the network, almost like NAT. Instead of just being able to link up by address, I would have to know what trust choices you'd made. A federated model or some kind of expanded hierarchy is possible but it would still have a center or at least a certificate authority. Otherwise you get Sybil.
  - hamburglar 12y ago
    This is a new topic for me, so apologies if this is an obvious notion, but what if one of the properties of a super-peer is a certain level of transparency and auditability so that any peer can verify its operation? That is, the super-peer contributes bandwidth and reliability because those are the resources unique to it, but the decision-making aspects and operational state of being a super-peer could be out in the open.
    - PeterisP 12y ago
      You can't verify the 'decision-making aspects and operational state' of a human or remote server, they can fake anything that you can check. Crypto tech allows us to verify possession of some information or token, or a proof of work, but that's it. Either the supernode can't do anything bad even if it's malicious (such as bitcoin miners) and you don't need the transparency or it can do something bad and then you can't audit it remotely, you need trust. If "something bad" is altering data, then if you can detect if the data is 'proper' (such as bitcoin transactions), then a node simply can't fake data; but if you can't detect it then you need to trust the node. The same for reading data, if it's cryptographically impossible for the node to read your messages, then you don't need to audit that node; but if it's possible, then you can't be really sure unless (and probably even if) the node is under your full control. [edit] Ahh, and if by 'verify' we mean not 'automatic verification that the system can do' but 'human verification where I check that Bob seems to be a nice guy, and thus his node can't be evil', then we're back to the original post - either centralized certificate authority chain, or Sybil problems.
      - walterbell 12y ago
        > You can't verify the 'decision-making aspects and operational state' of a human or remote server If the node is running an operating system that supports a dynamic root of trust, it's theoretically possible to perform a remote attestation for binary hashes of all software & config running on the remote node. Not suggesting that is easy, but it can be done with the right hardware (TXT, TPM) and Linux software stack.
        12y ago

by api 12y ago

walterbell 12y ago

Would there be any benefit in allowing users to optionally choose supernodes, e.g. providing ways for supernodes to disclose identify information or even to run a business the way VPN/proxies do today? In other words, if some nodes have to be centralized for technical reasons, apply a decentralized, Web-of-Trust, out of band, policy/reputation approach to governance and auditing the identity of the supernode operators. E.g. Supernode N is in City A, owned by Person B, regulated by Country C, packet-inspected by ISP D, and is vouched for by the following list of DevOps infrastructure auditors.

api 12y ago
It would fragment the network, almost like NAT. Instead of just being able to link up by address, I would have to know what trust choices you'd made. A federated model or some kind of expanded hierarchy is possible but it would still have a center or at least a certificate authority. Otherwise you get Sybil.
- hamburglar 12y ago
  This is a new topic for me, so apologies if this is an obvious notion, but what if one of the properties of a super-peer is a certain level of transparency and auditability so that any peer can verify its operation? That is, the super-peer contributes bandwidth and reliability because those are the resources unique to it, but the decision-making aspects and operational state of being a super-peer could be out in the open.
  - PeterisP 12y ago
    You can't verify the 'decision-making aspects and operational state' of a human or remote server, they can fake anything that you can check. Crypto tech allows us to verify possession of some information or token, or a proof of work, but that's it. Either the supernode can't do anything bad even if it's malicious (such as bitcoin miners) and you don't need the transparency or it can do something bad and then you can't audit it remotely, you need trust. If "something bad" is altering data, then if you can detect if the data is 'proper' (such as bitcoin transactions), then a node simply can't fake data; but if you can't detect it then you need to trust the node. The same for reading data, if it's cryptographically impossible for the node to read your messages, then you don't need to audit that node; but if it's possible, then you can't be really sure unless (and probably even if) the node is under your full control. [edit] Ahh, and if by 'verify' we mean not 'automatic verification that the system can do' but 'human verification where I check that Bob seems to be a nice guy, and thus his node can't be evil', then we're back to the original post - either centralized certificate authority chain, or Sybil problems.
    - walterbell 12y ago
      > You can't verify the 'decision-making aspects and operational state' of a human or remote server If the node is running an operating system that supports a dynamic root of trust, it's theoretically possible to perform a remote attestation for binary hashes of all software & config running on the remote node. Not suggesting that is easy, but it can be done with the right hardware (TXT, TPM) and Linux software stack.
      - 12y ago