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.
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.
Very cool idea with a lot of technical depth to it - thank you @jbradach. I think this also needs something on the other side of the HOPR network, right? Similar to a Tor exit node or Tor hidden service? See my comment on the two ways to build something like that which I left here.
Thinking through this, yes, I suppose it would require some sort of exit node. When I was initially picturing this it was more about accessing public services and not necessarily hidden/Onion ones. Focusing on public addresses would allow for more mainstream usage and provide a simpler use case more in line with being a drop in proxy/wrapper.
Without an exit node of some sort, the last HOPR node would somehow need to include that functionality – not sure how that might work. One approach might be to have an exit node application that can run alongside HOPR. Sort of like how a beacon chain node can run alongside Nethermind, etc.
Thanks! I feel like this idea is kind of just a starting place to have a quick and easy use for HOPR early on. I’m sure folks will come up with all sort of impressive ideas that blow us away with time!
Thanks for @jbradach this proposal. I like the idea and got some related questions.
What will happen if exit node or nodes will be compromised? How to secure the thing? Would love to hear if you have any thoughts.
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.
