neilalexander
commented
3 years ago The main reason why Yggdrasil has never done anything regarding proxying like this is because, today, there's an expectation that most traffic carried over the Yggdrasil Network is indeed IPv6-encapsulated. If we add listeners for SOCKS proxying then we pretty much need to add the major workings of an IP stack into Yggdrasil to provide that encapsulation/decapsulation, otherwise the SOCKS node just won't be able to talk to anything else and that renders it largely useless.
This is far more complexity than we want to own and is quite far out-of-scope for the project.
cofob
ccaapton
pufferffish
EternityForest
The full mesh encryption is great, but unfortunately, it seems that browsers do not care at all, and won't be treating Yggdrasil IP addresses as trusted anytime soon.
Perhaps a browser extension could be written, assuming no further nerfing happens, but a proxy also has a few other advantages, like working in any browser, like chrome mobile which lacks extensions.
I propose a standard for encoding both the port and IP into base64, and packing this into a subdomain of a proxy server, giving every mesh host a corresponding equivalent on a trusted localhost(On a random IP that's unlikely to conflict, like 127.5.9.12) but isolated with it's own subdomain.
This way, no self-signed certificate hackery is required to use the advanced features, many of which(like WebRTC and service workers) may be very important for a p2p future whee nodes spend a lot of time offline.
Especially if such a proxy was built directly into the main process itself, and widely accepted, it would make linking and sharing sites a lot easier.
It would also create an alternative to DNS that doesn't include any blockchains, which cause problems on limited storage. "Namefiles" could be shared that map from human readable localhost subdomains, to IPFS mesh names, similar to exchanging PGP keys.
This seems like something you'd want user-level control over, rather than using a system level daemon, but desktops are almost all single user anyway, and perhaps adding a new trusted site should involve the moment's pause that typing your sudo password gives(Or maybe it would only make people take sudo less seriously? Human factors is hard!).
The management app could eventually serve other purposes as well, like discovering and "pairing with" sites with things like QR codes that have the name mapping.
But in any case, the core functionality of HTTP proxying via subdomains would enable a lot of new use cases.