Apparently, keytracker expects a toml file as config that may or may not be
an instance of an entirely different specification of the spec than the one
python understands.
This is a first attempt to package octycs' keytracker [1] application.
It's more a quick-and-dirty approach, so there are a couple things to note:
- the config file is just generated by Nix as whatever the module got in
its config option stuffed into a toml file. There are no default values,
so all values must be set by hand – or rather, we just write the default
values in the config.
- I couldn't figure out how to actually make this thing work. It looks like
it /should/ work, but gets hung up every time on loading key information
via the web interface. Then again, it appears our current config on
libocedrus also doesn't conform to what the readme says, so perhaps I just
missed something that's as-yet undocumented.
- The module just calls python instead of an actual server as backend. This
is recommended just for development/testing, not actual deploys [2], but
since the project is missing a setup.py which afaik are required to package
these things more sensibly [3], that's it for now.
- keys and corresponding tokens are currently baked into the nix store. This
seems a bad idea, and I'll fix it as soon as I find the time.
[1] https://gitlab.infra4future.de/octycs/keytracker
[2] https://gitlab.infra4future.de/octycs/keytracker/-/blob/master/server/Readme.md
[3] https://flask.palletsprojects.com/en/1.1.x/tutorial/deploy/
Intended for KontraIAA; requirements were that it should be a simple and
non-confusing as possible.
I tried both KiwiIRC and thelounge, and found both horrible to
package (a fact not helped by the somewhat opaque structure of
nixpkgs.nodePackages, which does contain a version of thelounge but
will apparently ignore overrides of the src attribute).
Instead, this now contains a very hacky version of thelounge, which
merely takes the already-built version from nixpkgs and glues some extra
css to it which hides potentially confusing fields.
Things hidden on the "connect" screen:
- the "name" field (since thelounge offers "nick" "name" and "realname"
by default, which seems too much for something embedded on a website)
- the "I have a password" checkbox
Things hidden on the general view:
- the button to open the side panel (the panel itself is not hidden,
and will appear by itself on wider layouts), so that users will only
see that one channel
- the "channel options" menu (which includes a "leave channel" option
which would effectively break the webchat)
Things not addressed:
- thelounge has autocompletion for /join /leave, etc. Do we want to
disable that as well?
- It would probably useful to suppress all the "x joined the channel"
messages. Thelounge supports this, but apparently doesn't support
setting it as default?
Misc:
- for now, users will be connected to #thelounge on libera.chat, which
appears to be okay with being used as an experimental channel
- I allowed prefetching link previews, but only on the server's side
(i.e. users' browsers won't fetch content from arbitrary sites)
- not yet tested on hainich, but should work (tested in a NixOS
container)
- currently assumes a "webchat.voc.hacc.space" domain (I think we had a
voc domain? but I forgot where it is …)
nixos and its concepts/service management/update mechanism don't play nice with minecraft
In general some things I wanted to do (e.g. a map) are to spikiely resource intensive to run on a server meant to provide other services consistently
A replacement will be provided soon™
this is a workaround to be able to use java 11 with the
minecraft-server module
minecraft calls for jre_headless, which is still java 8
newer java version don't ship jre, which now have to be custom built or
the jdk used
lots of fancy new stuff, but most importantly: we no longer import all
of my user config, just the very base.
none of that fancy stuff is active right now, this should mostly be a
no-op unless we do the same restructure that i have just done in my
nixfiles here as well.
