Brainstorming Proxy

This is a raw brainstorm dump by jer, just a place to keep notes :)

Given the distributed underpinnings of lockers, where they should be able to exist behind a nat/firewall and have equal network opportunity with their unbridled peers, there is a need for proxying traditional http requests to them.

Building on TeleHash, a trusted proxy can be pre-configured by the locker by exchanging public keys (the proxy and the locker) ahead of time. The proxy returns back a base url unique to the locker. Then the locker will listen to it's public key on the dht, and the proxy will accept http requests to that base url.

When the proxy receives a request, it will look up the target locker's key on the dht (and cache it) and send a signed request to it, including in that request the ip:port to connect to and a token. The locker upon receiving this and validating the signature, will connect to that ip:port and send a signed handshake, including the token, one json object with newline at the end. Upon validation, the socket will then become the original http request, with the proxy writing out the request to it, and pipe all bytes bidirectionally.

The locker will probably have to create a custom http server and additionally connect to it, and pipe the sockets together. (the built-in node http stuff doesn't appear to have a way to reverse a connection) Additional validation and safety should be applied to all of these external/foreign requests.

Helpful uses:

• way of reaching your own locker behind nat/fw from any browser/mobile (need browser based auth)
• /push/:id requests for connectors/apps that are running independently (need handshaking, private url token)
• enabling external/mobile apps (need oauth in the proxy)
• pushed events from services for connectors, http callbacks

Probably not-ideal uses:

• generic/public web server
• serving back blobs (photos) from locker to any browser