I saw this talk at DEFCON. It seems to combine ideas from IPFS, BitTorrent magnet links, Tor, and things like scuttlebutt. There was a very strong focus on privacy including for metadata.
The biggest weaknesses I saw were around DOS attack resistance, which I did not see addressed. There were good approaches for privacy and security but what if someone with resources (botnet or money) wants to just burn the network down?
Completely pure P2P systems are hard to protect against Sybil attacks whose goal is simply to degrade service. Just launch a ton of bots, have them act normal for a while, then have them start being tar pits or misbehaving in ways that are carefully designed to maximize errors and latency. Then have them randomly pretend to be normal for a while, toggling good/evil to blend in as much as possible.
Combined with strong privacy how do you identify and remove these? The alternative is to design a protocol so bulletproof that there is no viable DOS attack, or use tokenization to impose a high cost on such attacks. Of course the latter leads down the road to all the toxic craziness of the cryptocurrency ecosystem. Add a token and now you have a vector for pump and dump schemes even if you didn’t intend it as that.
I can think of many reasons someone might launch such an attack from troll wars all the way to nation states trying to kill comm vectors for espionage or uprisings.
All protocols really have to be designed as if your client is the defense department and they will be used in a war zone… because the Internet is a war zone.
I actually think going the tokenization route is a good idea. As a positive side effect of the cryptocurrency boom, a lot of good research on POW/POS secured distributed systems was done and it would be a waste to not at least consider using this research.
As long as you hide the details in the depths of documentation of the protocol, make up alternative terms to those that have been tainted by cryptobros and don't mention any relation to cryptocurrency-originated technology, you would probably successfully avoid having parallels drawn between your project and cryptocurrencies.
Sure, someone might cobble together an API and put your token on a cryptocurrency exchange against your best wishes, but I think the risk of that is low. It's easy enough to launch your own crypto and if I'm looking to run a pump and dump scheme, why attach myself to a project that openly distances itself from the crypto scene?
If it can be done, it will be done. Non-consenting projects have been hijacked for pump-and-dumps countless of times. Better design the economics of the token with that in mind rather than having them broken once the wrapped token inevitably hits DeFi markets and gets spammed across Discord and Telegram chats.
> Completely pure P2P systems are hard to protect against Sybil attacks
I’m happy to report that P2P systems resistant to all kinds of attacks are implemented already. There are many, many solutions in many OS projects. See the technicalities of I2P or Freenet 2023. Safe P2P is possible, although hella hard to get right.
Yes. The protection they have against attacks are not ad hoc. They are based on theory and are scalable. One protection strategy (often seen in web-of-trust arthitectures) is to put trust in the authenticity of the current present machine (idk how to better phrase it). This way it doesn't even matter how much of your network is comprised of bots. Your machine will reject them all.
No, let me describe Web-of-Trust. Think about a P2P communication network. You have a trust level for each peer. You add a few trusted peers as friends beforehand. Now beware, this is a recursive algorithm. Your trust level for your direct friends is %100. It’s %0 by default for non-friends, then you calculate it as: the average trust every friend of yours has in that non-friend. If a friend of yours has added that non-friend as his friend, then you happen to have a level of trust in that non-friend and if that level exceeds a threshold, you deem him trustworthy for your purpose (info exchange etc.).
This is simplified, for example to be able to trust a peer who is not a friend of yours or your friends, you can add the trust of your friends’ friends in the calculation for a non-friend, while dividing the friends’ friends trust by a number to diminish their effect on the result. E.g. multiply your 2-level friends’ trust levels with 0.9, 3-level with 0.8 and so on.
This way, real peers will live in their isolated bubble network. Bots can’t fabricate your trust in themselves even if a direct friend of yours has a botnet he added as friends to his node, because no one else added those bots as friends other than your malicious friend. That botnet all trusting each other will be another isolated bubble of trust, with no trust-access to the real-peers bubble.
You can use this exact architecture to share and distribute encryption keys to create secure channels with trusted peers. Though you’d have to exchange keys with your friends air-gapped for it to be secure, if all the wires are tapped (which is true for the internet).
The failure mode in this architecture is: If all/most your real-life friends are malicious agents, then your node can live in a botnet trust bubble without you knowing it.
Depends on your definition of secure. If you mean software security against things like buffer overflows and other software vulnerabilities then the size of the machine is completely irrelevant.
If you mean robustness against brute force volumetric and resource exhaustion attacks then yes large systems are going to be more resilient than small systems for the same reason a big boat is harder to swamp with waves than a small one. The whole business model of things like Cloudflare is to put your site behind a gigantic CDN that is just so damn big it can weather volumetric attacks. It's a brute force solution to a brute force problem.
In this case I was talking about more intelligent distributed attacks against distributed protocols. Those types of attacks are very hard to protect against in general.
Most systems deal with it by being closed and isolated or at least having fairly strict policies about who is allowed to participate (e.g. BGP). In an open P2P network you're going to have to figure out a way to permit resiliency in aggregate without a trust model, which is IMHO an unsolved open problem in protocol design. There's been some progress in countermeasures but no huge breakthroughs.
Visiting that link gives me a GitLab signup page. Not a good onboarding experience for someone who cares about security and privacy. Perplexed I return to the original page and spot the offhanded mention:
"If you want to try out this proof of concept, please stay tuned for details on how to gain access."
This doesn't bode well, if they're reluctant to release even their own proof of concept.
I'm curious how this will deal with carrier grade firewalls and NATs. I can't run torrent client on my phone for this reason and I have hard time seeing how anything P2P is going to work on user hostile ISPs
It is an interesting project, but I'm sceptical. Veilid appears to be focused on their implementation in Rust, not so much as reference implementation but as the thing itself. I was hoping for a W3C like definition of a standard, not "bound" to their implementation or Cap'n Proto.
Cap'n'proto is very well designed and actually has multiple implementations. It also helps writing bindings for all kinds of languages that may want to call Veilid APIs.
I don't think that defining yet another serialization format would buy anything.
To me, the choice of Cap’n Proto means the developer looked at a colossal number of RPC frameworks in order to understand why Cap’n Proto is the best of them. While these things are subjective and also I cannot predict the future (ie actual adoption), it makes sense that being really opinionated and seemingly unorthodox is side by side to innovating.
True. On the other hand, gnunet tried the standards-based approach with binary specifications, as of yet with basically no adoption. One main problem I see that is very hard to integrate any other language or framework. If veilid now goes for trivially generatable language bindings, maybe they have more luck and this is what's needed to get something like this off the ground?
DHT's are normally very vulnerable to DOS attack, and the known techniques to harden them tend to hurt other properties yet I don't see any details on how DOS is mitigated even to the level freenet does (and freenet's mitigations are expensive indeed).
Probably no anonymous file storage system can really go without a discussion regarding strict liability for the possession of some kinds of unlawful content. (E.g. Freenet makes an effort so that the operator of a node storing a piece of data won't have the ability to decode it themselves.) Probably any modern system of this type ought to consider the ability for attackers to intentionally store illegal data in order to defame the system and users of the system and force them to shut down as a relevant attack in their attack model.
Odd to see no (at least) ephemeral PQ crypto for a protocol being developed now or a rational for why its missing. Perhaps PQ for the data at rest is too costly but it doesn't seem likely that it would be too costly for the P2P communications.
Any API accessible easily from Javascript client side?
The trend seems going towards web-browser local-first applications.
So an application on the client side, once was loaded the site's domain delivering the code, can work offline without network access, and synchronize later with its "associated peers/nodes/servers" (if they decide to).
Though wasm exists, it would be nice to be able to have a "high level API" so any user (not just technical) can become part of the federated protocol, and contribute to its rich content.
Yep! The Python API is the first one released, but it’s a wrapper around Veilid’s own JSON API. You can talk to a Veilid node using any language that speaks JSON.
I haven't been able to. I attempted to yesterday also with no luck. Their site mentions availability after recovering from DEF CON or something to that affect.
It's shame it looks like web clients won't be able to connect to each other p2p. If it supported the use of ICE+DTLS+SCTP or even ICE+QUIC, then it web clients could join in.
It says on the linked page that it's a "mobile-first framework" but what is mobile-first about it? I'm having trouble finding Swift or Kotlin code. Or do they mean something else?
Not yet. It’s also slower today than it will be as the node count increases. I mean, today there’s a fair chance that 2 nodes in California may talk through a node in Australia.
We’d love to self-host on our own app! Some day. :)
Matrix would be another good option today, but DEF CON was already using Discord for official communications, so this is one less app for people to install.
I'm building a publicly-accessible matrix app [0] that might be of interest to you, and anyone else looking to self-host a discord + discussions alternative.
It's still early days, but I'll probably do a Show HN at some point.
My view of CDC is that it's a long dead hacker clique resurrected by industry grifters, but I'd love for that to be proven incorrect on that. My biggest question is how the shift from techno-libertarianism to techno-anarchism with techno-dictatorship-of-the-prolotariat characteristics in the general space the CDC occupies will affect development. If successful, all kinds of unsavory actors will be using it, from child predators to terrorists to actual nazis, and worst of all, annoying right wingers. Do they have the values and strength of their views to keep serving those people or do they start eroding the security and privacy guarantees to kick them off?
That’s goofy. I’m not a cDc member, but I was online and actively building networks and network apps on the early public Internet before most people. I’m not thrilled that RWNJs are using some of the things my friends and I helped make, but that’s better than a world where someone can dictate that they’re not allowed to.
Today I run a Mastodon server. Neo-Nazis can deploy their own, too. Again, I wish they wouldn’t, but it’s not as bad as a central authority with enough power to lock them out.
I hope neo-Nazis hate Veilid and want nothing to do with it. I’m also not interested in a network with central controls strong enough that any one group could keep another group out altogether.
I'd love it if they stayed out of Veilid too, but if Veilid succeeds they will not. The needs of pro-democracy, pro-human rights protesters are very similar to the needs of hate groups, it sucks but it's true.
It is, and that’s kind of my point. Vile people will use good things, too. I’m not willing to forego having nice things just because people I loathe might also like them.
That's a very reasonable position to have! I am not confident that CDC holds that position, and if they do I am not confident that they will indefinitely.
I clearly can’t speak for the cDc or anyone in it. However, I’d be absolutely gobsmacked if the gang believed it was possible to make “privacy for everyone, as long as we agree with them”. Inherent in privacy is that you can’t know what other people are saying unless they want you to.
A lot of people who identify as pro-democracy, pro-human rights protestors are indistinguishable from hate groups. Most, if not all, hate groups think of themselves as the voice of oppressed people, demanding their rights. That's why they're always linking "Harrison Bergeron" and quoting Orwell.
Maybe sadly true, the social network effect. But through distribution (packages etc.), that can be very untrue, and anyways people who really want to meaningfully contribute will find their ways (and probably understand the benefits of free/open-software).
The biggest weaknesses I saw were around DOS attack resistance, which I did not see addressed. There were good approaches for privacy and security but what if someone with resources (botnet or money) wants to just burn the network down?
Completely pure P2P systems are hard to protect against Sybil attacks whose goal is simply to degrade service. Just launch a ton of bots, have them act normal for a while, then have them start being tar pits or misbehaving in ways that are carefully designed to maximize errors and latency. Then have them randomly pretend to be normal for a while, toggling good/evil to blend in as much as possible.
Combined with strong privacy how do you identify and remove these? The alternative is to design a protocol so bulletproof that there is no viable DOS attack, or use tokenization to impose a high cost on such attacks. Of course the latter leads down the road to all the toxic craziness of the cryptocurrency ecosystem. Add a token and now you have a vector for pump and dump schemes even if you didn’t intend it as that.
I can think of many reasons someone might launch such an attack from troll wars all the way to nation states trying to kill comm vectors for espionage or uprisings.
All protocols really have to be designed as if your client is the defense department and they will be used in a war zone… because the Internet is a war zone.