It’s been a month since my last Tempest status update, so it’s time for another. Since last month:
- Tempest now tracks per-grain permission bits, and gives the owner of the grain full access.
- It is now possible to create new grains via the user interface (instead of only being able to run grains imported from Sandstorm).
- Various improvements have been made to the UI.
- The size of the generated WASM executable has been cut in half.
A month ago, Tempest did not understand the permission bits in a a package definition, and would always connect to grains with minimal permissions. Now, permissions are tracked.
On its own this is a small thing, but while working on it I built out a bunch of the plumbing needed for sturdyRefs. I’m finding each feature I reach to build results in me filling out the codebase with things that will mean less and less yak shaving for future features; it’s a nice thing to watch.
Up until now, I’ve been developing and testing sandbox functionality using grains imported from Sandstorm, as there was no way to create new grains. This is no longer the case; Tempest can now create new grains from installed apps. At time of writing there are some limitations, which will be addressed soon:
- Some apps (e.g. Framadate) have more than one grain type that can be created. However, Tempest’s UI does not expose a way to create grains of different types. Instead, the first available type is always used.
- Furthermore, the server side parts of grain creation don’t actually
use the start commands specified in the package manifest; they just
create the grain and then let it start on first access, using
continueCommand. This works for most apps since this is typically the same as the start command for the first and only grain type, but it is technically incorrect and may break certain apps.
Tempest still doesn’t provide a way to install apps, so importing data from Sandstorm is still necessary.
There have been a few improvements to the UI. Specifically:
- The stylesheet now observes the browser-specified setting for dark vs. light mode, and adjusts UI colors accordingly.
- The list of open grains is now separate from the one for all grains.
- I fixed a known issue where, When switching between grains, the
grain’s iframe would be reloaded each time it was focused.
The way the DOM UI works, to avoid this you need to avoid moving or
otherwise detaching the iframe from its location, so instead of
only rendering the iframe for the visible/active grain, we now
unconditionally render iframes for all open grains, and hide the
inactive ones via CSS (
One of the drawbacks of using Go in the browser is that bundle size will not take care of itself; Go has a tendency to generate very large binaries, and while this isn’t a huge deal for the type of server-side code that Go is most typically used for, in the browser it’s a problem. I dismissed some other possible tools because of unacceptably large frontend payloads.
Before committing to use Go for the frontend at all, I did enough research to be sure I could at least keep bundle size under control, but knew going in that acceptable results would require some care.
Since very early on the build has been using TinyGo; the reference Go compiler generates an executable just shy of 4 MiB, which is a complete non-starter. Around the time of last month’s update, TinyGo was generating outputs close to 900 KiB, which is still not good, but close enough that I knew with some tuning the results could be acceptable.
Over the past month I’ve made some improvements go-capnp resulting in
smaller binaries: things like trying to avoid the large
and making dead code elimination work better. As a result the binary
is down to 440 KiB, which is starting to get competitive with
Sandstorm’s own bundle size (377 KiB).
There’s still more work to do on this front; 440 KiB is in the acceptable range, but I’d love it if Tempest could be even leaner, and there is still some low-hanging fruit that should have a big impact.