3 ms·

The challenge with these schemes is always making them robust against intentional attacks. It’s hard enough to do that for centrally regulated systems. There a

• nine_k 1y ago
  Is there no way to blacklist nodes?
  • dexterdog 1y ago
    Or throttle new node cration
• Centigonal 1y ago
  Another related issue is that decentralized networks are often targeted by attackers more than centralized ones, since a common use case for these networks is sharing information that the central entity (or some power that can coerce the central entity) does not want shared, e.g. organizing in authoritarian regimes, illegal file sharing
• fsflover 1y ago
  Could you solve this by running something like I2P on top of the mesh network? I2P has implemented strong protections against typical attacks.
• jazzyjackson 1y ago
  I don't know how ygg handles nodes but there's no reason a mesh network has to just accept random new peers, you could do something like mTLS where peers have to present certificates distributed out of band.
• Animats 1y ago
  > The challenge with these schemes is always making them robust against intentional attacks. Right. You join the network by generating a random IPv6 address and telling someone about it. So anyone can generate vast numbers of dummy node addresses, which everybody has to track. Now you need spam filtering.
  • sunshine-o 1y ago
    Yes but from my understanding one should not tell anybody about their IP as it is directly derived from a public key [0]. So in practice if you have doubts that your private key might have been compromised you must change your IP ASAP. So I guess serious Yggdrasil users rely rather on a solid DNS system to manage identities and configure things. They actually need it more than the public internet ! This is the problem the blockchain & Ethereum people bumped into quickly: the 'key = identity' paradigm is elegant but in practice you need an abstraction on top to do anything serious. I see they do have a DNS infrastructure in place [1] but most of the network services point to IP addresses, what really doesn't make sense to me. - [0] https://yggdrasil-network.github.io/privacy.html#network-identity https://yggdrasil-network.github.io/privacy.html#network-ide... - [1] https://yggdrasil-network.github.io/services.html#dns https://yggdrasil-network.github.io/services.html#dns
• ogurechny 1y ago
  There seems to be a misunderstanding. Yggdrasil is not a single network, it's a tool to make such networks. So if you have some computers with some ability to connect them, you can set them to peer in Yggdrasil, and instantly get an auto-configured irtual IPv6 network. (You can even slap some IPv4-to-IPv6 NAT over it, but we shouldn't mention crimes against humanity.) It seems to me that the main goal of the project is automatic routing that promises that in any peer graph any peer can reach any other at least somehow, which is fine for many use cases. Only in case of moving big data or very different cost of links you might want to check the node hierarchy and set manual peering from X to Y and Y to Z to make traffic flow the way you want. Public network is a volunteer-run test ground for real life usage, and a way to connect systems that can't connect directly because of NAT. Internal speed test that is 8 hops away on the other side of the world gives me 30 Mbps, closer one, in 5 hops, reaches 90 Mbps (and the local interface is 100 Mbps), so it has some throughput for casual users. As far as I can understand, current latency-based routing selection is just the most simple way chosen to optimise the network across the whole world, and prevent random 200 ms hops back and forth to intermediate nodes. If traffic from nodes in one half of the tree not having direct connections to the other half goes through the central nodes, it seems that at the moment it's enough for owners of central nodes to peer with each other, and have enough bandwidth. In the future they might need to take the proportions of available channels into account.