I’d like to provide someone a way to run a service on a computer of theirs that they could control from anywhere.
A quick option I thought to not have to deal with NAT is to make the service run a Delta Chat bot. Then the bot just needs to connect to a relay, no matter where the service is running.
Then I thought instead of providing a textual bot, the bot could interact with a webxdc app.
And then I thought, maybe there’d be a way to run a webxdc app that acts as a kind of reverse proxy, exposing a webapp running on the service?
In my head, this is a pretty cool way to provide web interfaces to control internal services for a few users- you don’t need to care about networking.
I’m thinking this could be quite generic- having a base bot and webxdc app that you can tweak to reverse proxy different applications. Maybe someone has already written this? Searching for “webxdc reverse proxy” and similar stuff didn’t seem to yield results.
The bot server could render the page in a headless browser and send in a snapshot of the DOM just like in the existing web preview bots, but enriched the clickable URLs with a bit of state information. In this case, it could also work without webxdc by sending in HTML email. Otherwise for webxdc use, you would generate ID/attributes for clickable elements, decorate the DOM upon loading with click handlers that would pass through the ID of clicked ones to the bot that would in turn return a diff of the DOM to render again. Kind of a web browser in webxdc.
As an alternative, the bot may be dumb and could just bridge each HTTP request wrapped in JSON payloads on the application network level instead and the webxdc could render the page based on the assets attached (not much different than how the existing multibots/downloaders work). If it tunneled at the TCP level, the bot server could even forward traffic without MITM intercepting what the user is viewing! It is more involved than the other case with greatly increased latency and higher number of messages sent, though.
Related:
Just to clarify my categorization choice: I find bot more fundamental because the web service might still be accessed without the webxdc through the bot (i.e., via slash commands or links), but the webxdc would be worthless without the bot connection.
Yes, I was thinking more along the lines of your second option. I thought more like your service could serve a web interface, but also start the bot process and tunnel requests to its web interface. I’m not sure of the needed design, but I don’t think you’d be able to use an existing web service as-is.
There are two choices. Either you are the developer of the web service and you can add email (DC) as a (bot) interface or maybe hook a separate bot up via its REST API, or you have to support tunneling generic web apps. The latter would also be possible as described in almost all cases (especially for most simple FOSS apps of interest).
I experimented with some like this some months ago, it worked but it was not very efficient (needed many emails), besides using DC for it was overkill (not need for all the writing to disk or extra layers of encryption):