Emacs Sandwiches

I bought a book on rust and I'm starting to peer into that. Meanwhile, it seems to make sense to consider lifting ComicChat more or less "whole-cloth" into a simple meet-and-greet interface for players and dungeon-masters to connect, and make with the killing of each others characters, and whatnot.

Aside the obvious wins of starting from an amusing and fully working chat server (amusing, working), I see the immediate need for an Emacs interface to ComicChat to exist in the world. (In truth, I felt strongly, nearly immediately upon discovering ComicChat, that the inability of Emacs to draw comicbooks would become an important problem.) Clearly, to reject this obviously core feature from the critical path from dungeon-mode would be folly, if not doom.

Recapping some maybe old news.. We had previously settled on (after some modest testing), CRDT to keep "transient" but frequently changing Emacs buffers in semi-real-time sync for multiple Emacs users. UIs rendered as fairly static SVG images, which are updated or re-rendered on the fly and (re)displayed by Emacs via SVG.el. We can create maps and a battle-board tracking characters' vitals; clicking them "can edit files and so on". There are menus and such.

Transient is meaning "things we can recreate from our more guarded sources, if we really have to". In any case, we have always targeted a web-client for most functions, and have considered a full web-services style API a strong likelyhood. That appears to be taking shape.

The rest of this post turned into rather an info-dump, I'm afraid. The TL;DR here is:

Things bode well for a dungeon-mode that can reveal the maps to players just as DM chooses, automate multi-file edits across multiple systems with copies of the files (without disturbing unrelated content in the remote copies), and provide a basic web-interface for non-Emacs users.

Here's my four-point plan to fight scope-creep vs a Minimum Play-Testable Product:

art?

1. scripts to install (bootstrap)

   • proxmox, minio, etc. deps (hydra?, open-ldap?)

   • Public Render (VM): emacs, dungeon, minio-mc

   • Web Server (VM): nodejs, arcade, minio-mc

     • https wrapping an http wrapping a websocket

     • control socket (TLS/mutual-cert)

   • grab and install some trusted game sources, maybe

2. arcade api

   • flush out the babel execute stuff for orgvm (this works locally, might push soon!)

   • bolt on orgvm and make it call the Emacs inside the Public Renderer to send us HTML, SVG, etc. from org-files, using minio as a cache

   • POST: accept a full org file, "explodes" it as file-hierarchy per org-export output

   • PUT: accepts a change to a document "section"

   • enhance the rooms interface (bolt a "room list" onto ComicChat)

   • accept an identity token over https (tokens are stashed in a private git repo we massage by hand, for now)

   • restrict some messages/commands (e.g. create-room) to the control socket/token only (breaking change vs comicchat; pr or close ComicChat #9)

   • expose CI/CD to roll a "Game VM" (shell and some JS; same as Public Render but different org-mode files and a dynamically generated auth token list)

   • accept header to select target VM for rendering (token flows into the container for checking but probably we test it for specific access to the target VM also in JS? If so, add a stash of tokens per VMs if we don't have one already).

   • reuse the "rooms" interface allowing clients to "subscribe" to (successful) PUT requests to a given VM (or path within the minio bucket/disk folder shared with that VM)

   • if we really want to keep hacking arcade, consider whether the per-game VM should also contain a private instance of arcade (i.e. webserver/port) just for the players of that game; we might even want a second per-game VM to keep the web-tier isolated.. this is where we should be thinking about hydra, hopefully patting our backs for already having that (or some proxy/traffic mangler) sorted. Probably we should just get back to hacking Emacs. Remember Emacs? Dungeon is a game engine written in Emacs.

3. Back in Emacs (dungeon-mode, proper)

   • design local/network.org as an index of the files we control across arcades we can produce tokens for

   • interactive function to POST a full file to the arcade

   • interactive function to PUT a section on the arcade

   • publish updates to the key game files section by section to the POST interface

   • try using mc before using open-file

   • design remote/characters.org as an index of the characters we control and which VM is able to post updates to us that we must apply

   • subscribe for PUT requests to a given character mentioned in characters.org

   • function to apply changes successfully PUT at the VM controlling a given of our local characters

   • design {local,remote}/shared-buffers.org as an index of minio buckets/paths we should subscribe to/host, each associated to a dungeon component (e.g. "Map" or "BattleBoard")

   • function to "open" a given file from local/shared-buffers, share it via CRDT, and update the index with the CRDT connection detail

   • function to connect to a remote shared buffer mentioned in remote/shared-buffers via CRDT, put it in the proper mode, arrange for special click behaviors based on play mode (DM/player/authoring)

   • another 50 or so items on the main TODO list notwithstanding, the rest is mostly writing glue in the form of an API that updates the right files when various common things happen, organizing such code into babel blocks, and, oh yea

   • connect to "chat" rooms of arcade, draw the chat SVG comix, split that out nicely so it works with ERC

4. And, finally, make arcade into (or spin a new) web-ux for an Emacs Powered RPG Engine:

   • UI to join a game (supply a token)

   • UI to see what files we can access (actually accessing files is probably already there via orgvm hackery, up in step #1)

   • UI to render the stream of POST events to interesting files (e.g. ur characters) into comix (pull in images via web-search?)

Naturally, Emacs users can continue to ignore the arcade/minio/VMs/etc. We continue to expect multi-player is possible with "just emacs". That said, such setup will likely require making other arrangements to have "non-local" files appear in proper places on each person local disc as they change (e.g. shared NAS and cron-jobs? IDK, playing with minio rn).

Similarly, non-GUI Emacs users may lament: the offer of a simple way to crank out a web-interface means we'll remain focused on graphics rich UX in Emacs for some time to come. By the time we get to connecting Emacs to the arcade's chat channels/bridge I'd expect we'll have at least some alternative "event log"/repl UX breathing.