Veilid is an open-source, P2P, mobile-first, networked application framework
veilid.com
veilid.com
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.
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.
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.
Think nation states, organized crime, or groups of black hats with huge botnets and a desire to take down a platform to silence someone on it.
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.
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?
Oh, my sweet summer child ;)
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.
"You can get the code for Veilid Chat at https://gitlab.com/veilid/veilidchat"
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 actually suggested Syncthing team to implement something like this few months back but they were not interested.
https://veilid.com/framework/rpc
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.
I don't think that defining yet another serialization format would buy anything.
Oh wait, cdc … mooh
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.
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.
Or am I missing something in the docs?
It also runs great on big servers with public IPs! But you can use it on your phone without turning your phone into a hand warmer.
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.
It's still early days, but I'll probably do a Show HN at some point.
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.
Some examples of successful project using gitlab.com: Wireshark, QEMU, Inkscape, F-Droid, Aurora, Commento, Kicad, Remmina, tortoise-git...