Complex UI

[nmlorg]

We're pretty well past the point where configuring the bot is awkward due to restrictions in Telegram clients' UI—#29 is a current example, but #31 will be a nightmare without some kind of WYSIWYG. Three alternatives:

1. Build a custom Telegram client. This could be a web app (either based on Webogram or a thin AJAXy wrapper over TDLib). It would go through the normal auth process to sign into the user's personal account, then either act as a full client with extra UI features (if based on Webogram) or only examine messages to metabot bots. This might technically violate section 1.3 of Telegram's API ToS.

2. Add a listening socket to metabot, letting admins pass messages to the bot from a custom client without going through Telegram. The actual web UI could be served over the socket or could be served from GitHub Pages and just set up CORS for the XHR endpoint. This shifts responsibility for authentication to us, but Telegram Login might be sufficient. (Revoking authentication might end up being impractical, but authorization could still be checked on every request.)

3. Build a web UI [on GH Pages] that just constructs a base64-encoded blob for the user to copy and paste into their Telegram client manually. This would be the easiest to implement, but would obviously be tedious (and error prone) to use (though less so—on both counts—than copying and pasting multiline strings, or trying to write Jinja2 templates by hand).

[nmlorg]

1. (a) Webogram
   (b) custom server based on TDLib
   (c) telegram-react
2. (b) Abstract BotConf a bit to allow it to be backed by Firebase Realtime Database (instead of just local YAML files), then build a web UI that only interacts with Firebase. Same issues with authentication, we'd just be converting the Telegram credential into a Firebase credential first.

[nmlorg]

As excited as I am about (2-b), I think the best way to move forward right now is to start with (3), and switch to (2-b) behind the scenes later (if the alternate configurator UI is functionally successful but just awkward to use).

That does still leave open a question of whether any part of the data should be pre-populated, either (3-a) just public data (like calendar list info) or (3-b) private bot data (and so still requiring auth), or if (3-c) users would have to ask the bot for a dump of the data through Telegram to pass to the configurator (in addition to the dump the configurator gives them to pass back to the bot). (3-c) could be just a URL (if we can guarantee it fits within all browsers' limits), or might need to be a JSON file (extra awkward).

The main benefit of (3-c) is that the configurator could be 100% client side, and so strictly live on GH Pages. It would also effortlessly handle privacy issues, as nothing that could be tied to any instance of metabot would be discoverable.

[nmlorg]

The main blocker for me has been worrying about testing. I've poked around but haven't found anything that seems remotely as nice to work with as pytest (which has a couple plugins to use external JS test runners as if they were Python tests, but nothing as powerful as itself). @joetyson recommended https://jestjs.io/, which he said can both integrate with pytest and run headless (which is obviously important for things like headless continuous builds, but seems to be bizarrely rare—I thought testing to specific browser implementations stopped being a thing a decade ago :/). Honestly I'm tempted to try to find some decent JS parsing library and build my own test runner (which syntactically captures straightforward == assertions and such), but, bleh.

Alternatively, just start building without tests (or only ones run manually), which is also bleh.

[nmlorg]

So, if I do go the route of building my own test runner, Js2Py looks really neat (though this would still be a pretty huge undertaking).

Another alternative would be to use something like pyjs to actually build the UI in Python (vaguely along the lines of—or perhaps even using [an extended]—MessageBuilder). All tests would remain 100% in Python, but the UI-building code would be "compiled" into HTML/JS (which would be assumed to be as correct as the tested Python source).

[nmlorg]

Just to get unblocked, I'm going to experiment using (2-a), and just initially not have it be accessible on the production instance. This will be developed lockstep with the new /set UI from #37.

[nmlorg]

Just to keep it dirt simple:

1. No realtime. GET returns current state, no notification if anything changes underneath you.
2. No auth. Might prompt you for a userid and store it in a cookie on first access, but trust whatever is provided.
3. Flag-controlled. Even though the production instance's host blocks all incoming TCP connections, this code will remain disabled unless a flag has been manually set in bots.yaml.
4. No attempt to support the now-legacy settings. If it hasn't been migrated to Data/settings layout reorganization #37, it's inaccessible.

Next steps:

• Build skeletal settings module. The whole module should probably be flag-controlled.
• Build skeletal web server.
• Hook web server into settings module (activated during modinit?).
• Figure out schema/flavor text form—for now it's okay if the actual logic and text remain duplicated in both the Python interface and the HTTP interface, but should think about/start documenting a long-term plan.

[nmlorg]

(See #93.)