VeilId is a way to build web applications apps but keep them private.
It was created by the cult of the dead cow and was recently launched.
Could this be used on top of safe network nodes to ensure the entire network is private, not just the data?
Some info on their routing: Private Routing · Veilid
Their video: https://www.youtube.com/watch?v=Kb1lKscAMDQ
Any thoughts on this @dirvine @happybeing
I would really appreciate your guys input!
I can’t comment without knowing more. Busy thinking Safe thoughts right now so 
entire network is private, not just the data?
I thought entire network is private, isnt?
yes it is and the apps run on your own machine, so there is nothing routing wise to be more private. The data comes from nodes of course, but these nodes are all over the place, so already private.
My first thought was that this is a form of advertising, and I am waiting for the poster to explain what they were thinking as far as being more private was
Watched a bit of the video with enthusiasm, then hear hole punch will come and was a bit deflated. I think lbp2p2 is where effort should go for the network layer.
I found the rest a bit hard to follow in terms of the capabilities, but seems chat etc. is no problem. So that seems great. Well worth following, but we are so busy these days it’s hard to take the time out to evaluate other projects. If there were an easier way it would be great, but seems, like us, there’s a ton of stuff to wade through to get close to understanding.
Maybe this is something the libp2p people should be made aware of?
If it works and can be ported into libp2p, then Safe Network would get it automatically (most likely) down the track.
You mention the data comes from nodes all over the place, but is the location of these nodes anonymous? Or is it just decentralized?
It is decentralised and globally so. Each close group will have nodes in many jurisdictions. It’s not easy (and maybe not possible) for nodes to completely hide their IP addresses while we use IP at all. Tor does some, but onion routing still has it’s issues and each layer of the onion knows the next and previous.
Clients and route and proxy to the network, which may help there. Nodes can use VPN for some levels of obscurity too.
To be truly IP invisible is likely not possible, so a totally new foundational protocol would need to be created, no NAT, dynamic DNS or similar (real time registration to a name) and much more.
This is why I pointed out Veilid. It hides the IP for the nodes.
Would it be possible to add this on top of the safenetwork nodes to bring that functionality?
It says on their documentation:
Veilid Routes are a combination of source and destination private routing. Because no node can trust any other node to pick the whole route, both source and destination must participate.
IP Privacy means your location is safe too
Users don’t have to do anything to use it
No IP address means no tracking, collection, or correlation
I just think it would be ideal to add this feature to the safenetwork, and just want to know if it is possible to add this on top? Perhaps as a wrapper around the maidsafe node.
Safe uses libp2p for it’s connections. So if it were going to use Veilid, it would need to be in libp2p ideally IMO. So you are proposing this to the wrong people.
Also what’s the difference between Veilid and Tor? Tor also hides IP and nodes and clients on SAFE could presumeably use Tor already to hide their IP’s … or alternatively (and likely much faster, just use a VPN).
So here is a nice concise overview of veilid in relation to tor:
The issues with tor are:
Unlike Tor, Veilid doesn’t run exit nodes. Each node in the Veilid network is equal, and if the NSA wanted to snoop on Veilid users like it does on Tor users, the Feds would have to monitor the entire network, which hopefully won’t be feasible, even for the No Such Agency.
You mentioned just using VPNs, but then the VPN provider knows your IP address, so that defeats the purpose of true privacy.
It sounds a bit like our old recursive routing. Nodes still do connect via IP to start (they must) but then each message hops along the route. In between hops the address is only the pub_key or hash etc. So no IP info.
We had great difficulty there and I hope they have managed it and get decent speed and reliability.
Some of the problems were
I hope the above points help that project if they are ever presented to them. I Also hope they get hole punch too.
I’m not sure about the hole punch part, could you elaborate on that?
Here is their technical slideshow PDF:
Perhaps they already have this feature?
They already have a live network that is private, so I assume they must have solved these issues already?
This means that people can run it from home behind a NAT router without the user having to configure the router themselves – which requires a tech savvy user (grandma can’t). Hole-punch allows anyone to use it with ease.
I did see this in the PDF, but it seems a bit nebulous. Unclear to me if they have hole-punch or not.
I joined their Discord and asked “I hope you guys don’t mind me asking. How has hole-punching been solved for folks that are behind NAT? Does it just work so even grandma could make it happen?”
I’ll let you know what they say.
So the reply to Knosis question on the discord was:
Part of a node’s startup includes communication with a bootstrap node. Part of that process includes NAT type discovery. The node then includes information on how it can be reached in its route info, which is propagated among peers.
Hole punching exists as does using non-NAT nodes as relays.
All of this is included in Veilid core so app developers and end users don’t have to be overly concerned about it.
And another reply was:
NAT discovery works like how ‘STUN’ works, but without ‘STUN’ servers. Once the NAT type and public IP address is determined, UDP connections can be established using our in-network ‘signal’ relaying mechanism, using the standard UDP holepunch. TCP and WS connections are done with reverse-connections when possible, and in the event none of these connection types are available (both sides are behind symmetric NAT or whatever), then a fully relayed connection is established through an ‘inbound relay’ node that is selected by the destination.
So it’s like having STUN and TURN built in. Outbound relaying is not supported (which is where outgoing connections pick a relay), because of the potential for abuse there. There’s work being done on that part to enable it specifically for HTTPS PWAs where it would be necessary for outbound connections a lot of the time.
So assume they have that already working?
I think using it for the safenetwork to make it anonymous would be amazing.
nice work @knosis.
Ive not looked at it.
But why would they think it unfeasable to minotor their entire network, when thats exactly what is done with tor?
That capability is many years old.
