It sounds like what you want is "CaaS". Connectivity as a Service. Specifically, connectivity that allows unrestricted two-way communication between end users

It sounds like what you want is "CaaS". Connectivity as a Service. Specifically, connectivity that allows unrestricted two-way communication between end users. "Unrestricted" as used here refers to restrictions arising from firewalls and NAT. This sounds simple enough. So why isn't it a standard offering? Only the connection. Not the connection as part of an application that uses the connection. Only the connection on its own. IOW, what you see when you type ipconfig or ifconfig. A connection that can then be used by any application. A user might use have some applications use this connection (i.e. interface), but not others. Her ISP-provided connection to the Internet and her CaaS connection to a small user-created VLAN overlay network can be separated on the logical interface level. One way to envision this is the CaaS provider gives the user what she needs to make her own small overlay networks. App developers might provide LAN-based applications to run on top. Everyone reading this online has connectivity to "the Internet". But the vast majority of end users do not have connectivity that allows unrestricted two-way communication with each other. Instead they must communicate through a third party such as an email provider (e.g. Gmail) or a website (e.g. Facebook). Firewalls allow ingress traffic coming from such third parties. Those third parties generally monitor and often analyze all traffic that passes through them, usually for commercial benefit. Perhaps they store it as well. Regardless of the security or privacy implications of this model, communication via a third party is often inefficient. Why should two users in the same country who wish to send data to each other be required to send their data to a datacenter in a different country in order to communicate? To take but one very basic example, consider email. What if end users ran their own SMTP servers and these servers communicated directly? There would be no need for "email providers". This is not so far-fetched as it might sound. In the early days of the Internet, there were no commercial email providers acting as "gatekeepers" of email, as there are today. And if you go back far enough, there were also no domain names nor centralized pseudo-authorities (ICANN and its "authorized" registrars), who constitute an additional gatekeeper. As it stands today, you generally need both a preferred IP address and a registered domain name to reliably send email, not to mention the permission of your ISP. There was much less centralization and control in the early Internet and it was far more fun (and I would argue far more useful). Email users could communicate based on mailbox name and IP address, and without involving third party SMTP servers. Imagine the simplicity. Connectivity as a Service could make decentralized, user-controlled email again possible for subscribers of different ISP's. It could also make many other otherwise "impossible" Internet uses possible. I posit CaaS could increase the value of the Internet as a whole. Internet centralization and its incumbents may be ripe for disruption. We might innovate toward more decentralized uses of the Internet than centralized ones. Then again, CaaS may not be what you want. I may have misinterpreted what you were describing.