Proxy plans are underutilized, individuals can monitize their ip addresses, fine grained configuration, pay per request, ICO Proxy servers have a great variety of use cases. Each of these demands specific properties from the proxy setup. In some one just wants to have access to as many random global ip addresses. In some, one needs access to proxy servers located at a specific location and in others he/she wants to use it exclusively without anybody else using it. Unfortunately the way proxy servers are sold doesn’t map to its use cases, which leads to inefficient resource utilization. Let’s say somebody wants to make a couple of requests from a specific location. He/she has to find a vendor that specificily offers access to that location and order a proxy package for, a minimum of 10$, even tho he/she only want to send a couple of requests. Wouldn’t it be cool if the remaining quota could be sold on a marketplace? Another underutilized resource are the ip addresses of everybody that has an internet connection. Thanks to the reassignment of ip addresses and flatrate contracts, it’s possible to pump hundreds of GBs from a pool of ips throw the wire every month. Given that traditional proxy server providers charge between 0.5-1$ per GB bandwidth, this can generate an extra income of up to 100$/month for individuals. As they aren’t professional proxy providers tho, they need additional protection measures, like blocking certain protocols (e.g. torrent) and domains (e.g. payment services). Having access to a highly dynamic and incredible diverse pool of proxy servers allows fine grained configuration of individual pools that fully reflect the needs of the customer. He/she can configure it to route traffic throw the desired location and to have exclusive access to a specific domain (while the same proxy is still used by others for different domains). Another selling point would be to pay per request. This allows the customers simply have to top up their account and be able spend their credits over a longer period of time. Additionally, the whole idea can be turned into an ICO where the coins are used as a mean to pay for access to proxies. Individuals that provide access would then simply mine coins that can be traded. Honestly tho, there is no good reason to power it with a coin based payment solution other than being able to do an ICO. In the worst case, which isn’t that unlikely, it could even fuck up the whole marketplace.
Besides a normal web interfaces there are two critical components that need to be implemented.
The first one is an intermediate proxy server, users are connecting to, that proxies the requests throw the actual proxy servers. It knows the pools the customers configured and will identify the pool and thus the user by the username provided in the proxy connection string
pool:passwort@proxydomain. It also needs to capture some statistic that are required for billing and to power dashboards. The proxy should be deployed globally to reduce latency. In an initial evaluation vultr.com provided the best conditions to start with, as it offers many regions and comparatively cheap machines and traffic.
The implementation effort for the proxy functionality itself is relatively small, when customising an existing implementation. A proof of concept was already implemented by adapting armon/go-socks5. The complex part of the overall proxy is its state management. It needs to know about the configuration of the pool and the available proxy servers and their utilisation. These three things add up to a highly dynamic state that is hard to capture. And in order for the proxy to make routing decisions fast the state needs to be cached within the proxies memory which stands in contradiction to its dynamic nature. Thus in an initial setup it shouldn’t be tried to build a fully atomic system.
The second critical components is the pricing system. Having a markeplace that matches supply and demand of a resource that is sold in bulk, but may be billing in single units requires a lot of thought when modelling it. Inspiration can be found in match making systems, deployed in domains like ad bidding and stock exchanges.