We set out to make a guest book that anyone could sign without logging into to wiki. github 
# Progress
Our strategy is to supplement wiki with a second server that will append to the log.txt for each guest. We aligned unix permissions between the two servers.
This is a form that posts to our temporary guest book server: localhost:8080.
pages/guest-book
We borrowed the deno example code for handing a POST from Deno Deploy. page
This example showed how to handle many content types. We extended the example for form-data with a local write.
if(key == 'name') { await Deno.writeTextFile("./log.txt", value+"\n", {append: true}) }
We linked ./log.txt to the asset deep in the assets folder. This is how we connected our application to wiki. It also required that we fiddle with unix permissions before we could write.
We tested the service with curl.
curl -X POST -F 'name=Robert' localhost:8080
# Trouble
Without thinking we created a cross-site POST which must be approved by a CORS pre-flight validation. I've struggled with this from Frame html script but our situation here is simpler.
My intention was to cross-fork our localhost testbed with this public dojo site but found that dragging a localhost flag to the public site no longer works. Bummer. I transferred the page through an export.json file and then hacked the journal with a text editor to make it look like it had been forked. All's good now.
# Retrospective
Robert Best who proposed this as an interesting exercise mentioned that he expected a solution from within wiki. I resisted because I thought this would be a more versatile approach. Maybe not.
A plugin is allowed to include a server-side component. We have explored this as a public writing surface in the JSON Plugin but found there that rewriting page json has its own risks.
A server-side plugin that wrote only to a predefined asset file using the operating system's append logic seems a better choice now as it avoids both troubles mentioned above.
Such a plugin would have a client-side part that would include both the signing form and the signature viewing part. This would accumulate Journal history only when the plugin markup configuration was changed, not with each visitor's signature.