This page has a few projects I’d like to do someday.

These vary between “as soon as I finish my PhD” and “probably won’t ever make time, but it’s fun to think about.” (Most of the games are probably the latter.)

Federated IRC

As a protocol, IRC already enjoys relatively wide client and ecosystem support. Most of the features missing from IRC are able to be provided via IRCv3 extensions, with reasonable graceful fallbacks.

TODO, more explanation of why I want these things, but… It’d be nice to write the infra to let me drop other chat clients:

• Make extensions to support a namespace of “federated” channels, which are organized between bouncers without a single owning server.

• Use the IRCv3 soju.im/bouncer-networks extension to support other chat services.

• Support a variety of hypertext objects being sent and modified over chat; enough to support other chat services, but also enough to support things that aren’t supported by other chat services.

  For example, it would be genuinely useful to be able to share a gdb session with someone; this is obviously difficult to implement, but the goal is to enable an ecosystem in which these things can be shared, and a client that “supports all the extensions” can get arbitrarily complicated new interactive hypertext objects.

  Think Google/Apache Wave, I suppose.

rv2js

I think there’s room for faster RISC-V emulation in the browser.

Right now, WebAssembly doesn’t have great support for JIT. By binding back to the host, a WebAssembly module can compile a new module, but this is relatively heavy-weight, so it’s not a great fit for “one basic block at a time” translation. (Limitations on linear memory are also annoying.)

However, we still have another JIT that can lower to low-level operations — the ordinary JS JIT. An asm.js-like lowering is still useful here!

The idea behind rv2js is to write a fairly ordinary QEMU TCG-style dynamic binary translator, but translate to a fairly low-level subset of JavaScript. The browser JIT (via new Function()) can then be used to compile these basic blocks as functions.

This would be nice for a few other tools and experiments:

• How much of e.g. the Linux kernel, musl, and GNU coreutils could be ahead-of-time compiled and shipped in a translation cache? If translation and compilation time are a large fraction of runtime, could we ship a .js file of pre-translated snippets? The browser is already optimized for shipping “tons of JS that almost never gets run”…

• How good of a debugging experience (for teaching students) can we ship, given an emulator’s-eye view? Making it really easy to build a custom debugger could be useful for a bunch of classes, from the introductory machine architecture class to the compilers course.

• Could we just target the browser from ukoOS?

• Could a web-based playground for Sylvan ship a minimal Linux install, plus the Sylvan compiler as a WebAssembly program? There would be a hacked-up interface between the kernel and the compiler to let one call out to the other.

  The playground user is using Emacs or Neovim (or heck, the shell), and is compiling real RISC-V binaries that get run under a real Linux kernel, without requiring me to host anything that runs arbitrary user-provided code.

• Could most of userspace get statically translated to WebAssembly and shipped this way? Context switching becomes trickier, but a compiler could introduce safepoints on backedges.

  This probably involves tons of hackery on the kernel, since each WebAssembly program’s address space is discontiguous from the VM’s.

• If we drop page table support, can we be the fastest implementation of a CHERI userspace? This would depend on the CHERI RISC-V Linux ABI (including the interface to the kernel) getting sorted out, but would be very neat and faster emulation could help that ecosystem get more stuff ported faster.

This might be what I spend a good chunk of time doing once I graduate.

“Reverse SS13” Game

Another game idea: the game starts with a self-sufficient space station, you play controlling some alien monster faction trying to take it over without getting everyone killed. (So, for example, if you accidentally kill everyone responsible for fusion reactor maintenance too early, you will not be having a good time.)

There’s a bunch of different monsters that I think would be fun to do this as:

• Hive-mind virus — you infect people somehow (probably has to be fairly intentional; something respiratory would spread too fast), and after some symptomatic period, you can influence them.

  It probably makes sense for your influence to take a while to solidify; influence follows a sigmoid, intensity of symptoms follows its derivative?

• “The Thing”-style shapeshifter — you have to attack people while they’re alone to assimilate them, which takes some time.

  The play-style here is probably more tense than the others; infection is fast enough that you can be infecting new people while station personnel are actively trying to test others, and this one probably justifies an interpersonal paranoia matrix.

• Xenomorph-style monster — you abduct people uses them to reproduce. To make this one viable, you probably need the ability to make more advanced monsters to do things like aforementioned reactor maintenance.

  This one’s maybe a bit trickier, because people are going to notice how many people have gone missing pretty soon…

A lot of the challenge here is to understanding the supply chain of the station; every part of the station’s functioning requires some resources, and almost every person on the ship has some role in that supply chain.

If the supply chain is robust in some area (e.g., if there are three dozen people who can repair the CO₂ scrubbers), it might not matter if someone responsible for that area is unable to do their job. If not, though, you might have trouble sooner than later, whether it’s unwanted attention or the station falling to pieces.

To make sure the station doesn’t fall apart on its own, it probably makes sense to have some central agent (station AI?) governing the station’s economy and closing any feedback loops. As the player puts more and more stress on the station’s economy, at some point this’d stop working, too…

This is partly an excuse to do a deep dive on GOFAI; being able to simulate thousands or tens of thousands of the station’s residents, plus whatever station AI or other governance structure is an interesting performance problem, and finding a trade-off that maintains good simulation fidelity while not breaking immersion sounds like a fun challenge.

Of the games here, this is probably the one I’m most likely (still not very likely!) to make.