I don’t think anyone has said this yet, so I’ll just put it out there. Adopting this as an additional layer would likely break the Safe Networks ability to function and even if it did at some level, it would prevent many people from being able to use it - or wanting to use it (as it would be too slow). It’s a matter of speed and maintaining connections and these hops and layers IMO would radically slow down the network - likely to the point of breaking.
I think it would be very interesting to see this added to a fork of libp2p and then those that wanted to use it (many projects use libp2p), could try it out. But I can’t see it being added to Safe for a long while.
Safe has many other avenues for privacy and security though and I believe that for now at least it’s more than enough. Those who want to work to enhance it for their client or node can adopt other 3rd party solutions as another layer in their networks.
I don’t mean to be a bummer on an interesting idea - just trying to keep it real.
Hopefully a safenetwork dev can spend a free day or two to just see how easy/hard it might be. I would love to see someone with technical knowledge put together a brief cost/beenfit analysis on it.
I’m sure there are likely issues, but my fear is not looking into it because of perceived assumptions etc. Veilid has no token and is open-source so I wouldn’t even consider it competition.
I just think it could be risky to be super inwardly focused and do something one way due to a sunk cost fallacy, without spending a day or two to try other technologies that have developed in the meantime.
Again, i’m not a dev and don’t have contacts within the libp2p team, but I do think it might be worthwhile to spend a day looking into these solutions that have popped up.
The cost /risk benefit might be worthwhile and being able to say “anonymous” along with “private” would be great for marketing. Now it’s just private in the same way that VPNs claim to be private.
There are indeed technical issues. The network is nimble as it is now in the testnets, but if every node is running through differing hops, then each client has to go through each of those to get a chunk for each node … this add huge delays onto data retrieval - making us a very slow to useless network. Worse than that, uploading for those with slow connections (like myself) is already tricky - having to lower the batch-size to minimum and even then sometimes having to repeat the upload. Hopefully that will improve in time, but adding hops in for each node would render it useless for slow connections and make it much harder for even fast connections to upload.
IMO, the best way forward here is to keep Veilid as a discrete stand-alone entity that is optional for people to use. This is also I believe a general principle of FOSS - keep it simple and don’t customize for a specific crowd.
Ahh, yes. Just a toy example I suppose. That being said, Veilid does look like a promising library. I don’t see performance and multiple hops being a major detractor. This is supposed to be the Safe Network, not the Speed Network. If they have nat working, why not investigate?
Hi just wondering if I could be given access to the beta program, I filled out the typeform and submitted it, but don’t think it went through, perhaps a VPN issue?
I’ve been building a veiled wrapper around autonomi and want to test the speed difference in a real world environment setting. There has been a lot of updates on the veiled software side, so i’d like to test it sooner than later before even more changes are added! Thanks
It will all be revealed in time Everyone can participate in the beta in any case. I don’t myself know the names of all who got in, but it’s all part of the roll out. I would not worry about it, it’s a bonus to be “in” but everyone is an active beta tester and valuable to the project.
So don’t panic at all, everything will be fine and the program will expand quickly we hope so future waves are even more anticipated and so on.
According to the existing provision in Network Fundamentals, the IP of the nodes should be scrubbed after the first connection to Safe:
Scrub all client IP addresses from Hop 1 of the overlay network (i.e. on Safe) > > After a user has started to communicate directly with anyone else after the first Safe network node to which it connects, the user’s IP address is scrubbed and untraceable. For clarity, we use the phrase ‘Hop 1’ to refer to the transmission immediately after that connection to the first Safe Network node (not the hop that might take place from your computer to your home WiFi router, for example).
Whereas in the current record there is only information:
Obfuscate IP addresses as far as the underlying technology allows
Does this mean that the original assumption is not possible, or is it only at this point that we cannot realize the original assumption? What is the key problem?
It’s a goal we must work towards. There was a hop mechanism, but it turned out to be less useful and more complex than we thought. So work to do as with some of the other fundamentals. The key is drive towards these.
Thanks, it’s a pity that it’s this element that doesn’t work, but I’m optimistic, I think Veilid is worth a try, or we’ll find another way of anonymity.
I think we have many opportunities to increase privacy, Saorsa, in line with its declared functionalities, will certainly improve privacy (by logging in with 4 words), but it still has a user ID. I also have my own potential solutions that will definitely improve security and privacy, but there is only one favourite… Without it, we will remain a niche project, one of many.
Well, the Chinese New Year of the Fire Horse is coming soon, and although it hasn’t started yet, we can already see what’s happening, and there will be even more happening if we don’t grab it by the mane, it may kick hard… If we waste this year instead of taking action, it will be a cardinal mistake.