[This proposal comes from @jbradach, with credit to @SCBuergel and @Lastfor. To support this proposal, sign it by clicking the like (heart) button beneath this post.]
HOPR could be used as the backend of a lightweight web proxy. There are a number of ways this could be implemented, but at its most basic form it could be a parameterized URL.
[Protocol]://hopr.myproxyapp.example/[API Key]/[Method]/[Hops]/?url=[Address]
- The [API Key], perhaps coupled with an [API Secret], could be used to associate the request with a funder/user to track spending.
- [Method] would be the appropriate HTTP method (GET, POST, HEAD, etc.). I think this could be optional or dropped in favor of keeping the URLs simple.
- [Hops] would allow the user to specify how many relays should be used.
- [Address] would be the desired URL to be accessed.
I think this has a number of possible uses:
- It could be used to quickly and easily access a website restricted in your region without having to use a VPN.
- It could be used as a sort of drop in wrapper for RPC endpoints. ([Protocol]://hopr.myproxyapp.example/?url=[Protocol]://rpc.gnosischain.com)
- It could be used to easily test server availability outside of your own network ([Protocol]://hopr.myproxyapp.example/?url=[Protocol]://myprivatesite.public)
- It could return a version of a website that may potentially be unsafe by stripping out or escaping javascript or other code ([Protocol]://hopr.myproxyapp.example/suspicious/?url=[Protocol]://trollsonly.lol).
There are probably many other places where a light weight drop in proxy could be used. I think of this as something that could be used with any sort of address to avoid accessing the resource directly.
To actually send a request for external data, there would need to be some sort of exit node. For an exit node approach to work here, there would have to be some sort of incentive. The HOPR nodes relaying the data earn rewards for doing so correctly, so the exit nodes would need something similar. Without some sort of incentive, I don’t think most people would want the level of exposure that would come with running an exit node.
I’m thinking about two possible approaches so far, but would welcome others:
- This could be built into the HOPR incentive structure. Perhaps an exit node could act like a regular participating node, or with a separate reward that’s added on for this kind of request. Or maybe being an exit node would guarantee, or at least have a higher likelihood, of earning you a ticket.
- I don’t think the above really does much to ensure the exit node operates honestly. It also doesn’t punish nodes that provide the wrong data in return. There would need to be some sort of efficient validation taking place along the way. Maybe that means more than one exit node has to propose matching data in order for it to be relayed back to the requestor.
Given the risk involved with any returned data, it would make sense to have staking requirements. In order to run an exit node, one would need to stake a nontrivial amount. I’m agnostic as to which coin/token to use, but even HOPR could make sense. If an exit node attempts to return the wrong data, it would be penalized through both jailing (depending on the number/severity of the infractions) and slashing.
Regardless, I think there would need to be more than one way to validate the exit node’s responses. Perhaps the exit nodes randomly check returned data from one another or one of the HOPR nodes along the way performs some sort of validation.
Or maybe it’s just that before anything is sent back in response, two or more exit nodes must independently propose returning the same data.
Credit: I’d like to credit @SCBuergel and @Lastfor for their questions and comments that helped me further develop this idea.
[View the original discussion by clicking here]