<isd>
I hadn't thought super far ahead re: what next steps were on the nix stuff. garrison showed up and got things moving, I don't know if he had specific motivation.
<isd>
In the long term, I'd like to use nix ot make sandstorm offical builds reproducible, to mostly-unbundle boringssl, libsodium, and clang without losing the current benefits we get from versioning them (known exact versions).
<isd>
In my fantasy universe where we switch away from mongo, it would make it easier to pull in postgres or something, if we're building the bundles from nix.
<Corbin>
Sure, this all makes sense. If Sandstorm's release cadence is slow enough (twice a year or less) then we could line up versions in nixpkgs so that NixOS releases have working Sandstorm.
<isd>
Sandstorm's releases are currently once a month.
<isd>
(In the good old days they were once a week)
<Corbin>
Mm. Then let's not worry about it, unless there's an LTS schedule.
<garrison>
Re motivation: I'd love to see Sandstorm support running in immutable (ideally, reproducible) environments, whether that is more idiomatic use of Docker, nix, or rpm-ostree (or all of the above). I figured it made sense to get nix on the same playing field as the others - plus, I have a fair amount of experience getting things to build with
<garrison>
nixpkgs, accumulated over the years.
koo6 has quit [Ping timeout: 252 seconds]
xet7 has quit [Remote host closed the connection]
xet7 has joined #sandstorm
<ill_logic>
Reproducible would be great. I'm curious what immutable means in this context.
<ill_logic>
Unless it was discussed somewhere above. I haven't followed this whole convo closely.
<Corbin>
ill_logic: The Nix store is generally immutable; /nix/store is read-only, even to root. The Nix daemon has privileges to change the store, but typical holders of package-capabilities (paths into the store) do not.
<ill_logic>
Ah okay. So yes I knew that part. So the point is to have Sandstorm apps having dependencies in the Nix store or something? Such that they wouldn't need to be part of the package anymore?
<Corbin>
I think that the pattern would be to copy the needed portion of the store (Nix calls them "closures") during the SPK; this is how Nix packages are put into Docker-compatible images too.
<ill_logic>
That's basically the same as usual Sandstorm packaging, right?
<Corbin>
Yeah. There's a lot of conceptual overlap. One could argue that Docker does the same stuff, too.
<Corbin>
https://grahamc.com/blog/nix-and-layered-docker-images explains the details in a way which might make it clearer how Nix can improve things; there's no edge where we suddenly cut from our packaging toolchain back to the "real world" of distro-provided binaries with questionable patches.
<ill_logic>
BTW on a sort of unrelated note - did anybody else notice that Framadate allows people to change other people's votes, despite the description of the the share link permissions? I feel like people would have noticed by now.
<ill_logic>
I'll report it on github at any rate.
<ill_logic>
Seems other Sandstorm issues there have gone unanswered.
<ocdtrekkie>
Our Framadate package is really old.
<ocdtrekkie>
Probably needs some love someday.
<ill_logic>
We might also have some low hanging fruit with a simple RSVP application. I'm about to maybe repurpose Framadate as a RSVP app.
<ocdtrekkie>
Yeah, Framadate is pretty flexible, but we have a 7 year old version of it at this point.
<garrison>
ill_logic: By desiring an "immutable" environment, I am really just referring to Sandstorm expecting to be able to write to the location it is installed and to perform automatic updates. I am not interested in having spk's interact with the nix store, but if people want to create spk's using tools from nix, that should be supported too.
<Corbin>
The ideal, at least in my imagination, would be an "spkTools" in nixpkgs, a collection of functions which take a derivation (a Nix package expression) and bake an SPK.
<Corbin>
...Wait, what's the "K" in "SPK" again? How should I pluralize it?
<Corbin>
garrison: I'm personally interested in running a Sandstorm instance for my homelab, so that I can freely give visitors access to certain capabilities around the house.
<isd>
I assume "Sandstorm PacKage" -- so not exactly an acronym
<Corbin>
So being able to *administer* Sandstorm on NixOS would be an important goal for me.
<isd>
app packaging with nix is basically independent of the ekam stuff; no app I know of (except the test app which is built in-tree) uses ekam as its build tool.
<garrison>
Corbin: Probably the easiest way to do that right now would be to use docker-spk and use nix as the base image. But if that were to work well, there is no fundamental reason that docker is necessary as an intermediate.
<isd>
But I do think an spkTools for app packaging would be great, and it has been vaguely on my wish-list.
<Corbin>
garrison: Right. As the poem goes, now is better than never, but never is preferable to *right now*. I am patient.
<garrison>
s/were to work well/were to be found to be a (broadly) useful method for packaging sandstorm apps/
<Corbin>
Is there maybe an SPK design document I could read? I'm not cool enough to be grahamc, but I could look at what ingredients are missing from nixpkgs.
<garrison>
there is the "raw spk packaging guide" in the docs. But the vagrant-spk notes are required reading, and I have learned a lot from working with docker-spk
<isd>
Corbin: the format is documented in package.capnp in the sandstorm repo. It's basically <magic number> || <signature> || <xz compressed file tree>
<isd>
with the format of the latter two defined via capnproto
<isd>
Most of the metadata for a package ends up at /sandstorm-manifest in the archive, itself a capnproto struct.
<Corbin>
Hm. The file tree's not a tarball? I guess that we'd need to write a little program that takes a Nix closure and packs it up using that Capn schema.
<Corbin>
Maybe you've already got something that can take/stream a tarball?
<isd>
spk pack can package a file tree into an spk
<isd>
The slightly thorny bit is that spks must be signed; I don't know how keyring management would mix with nix.
* Corbin
animatedly chats with shoulder demons
<isd>
https://github.com/zenhack/go.sandstorm also includes support for building spks; it is used by docker-spk, which directly converts docker images, which are tarballs, into spks.
<Corbin>
The cryptographer says that we need to ask whether the signatures are nonced. If so, then we need to give up at that stage and not check the SPKs into the Nix store, because we're not reproducible.
<isd>
I don't know off the top of my head.
<Corbin>
And also yeah, keyring/secrets management is a perennial difficulty. The general pattern is that secrets live in a regular user's homedir, and when that user incants Nix then those secrets are read by Nix but not checked into the store. So, again, only good for final artifacts which aren't checked in.
<Corbin>
These aren't serious obstacles FWIW. Like, some kernel builds have to be signed and that's not a problem. Nix itself has signature support so that people can trust binary caches based on who built each package.
<ocdtrekkie>
garrison: Presumably if Framadate is now feature complete, one last SPK update should cover our needs for Framadate updates in perpetuity!
<isd>
Lately housemates have been making heavy use of https://www.when2meet.com/, which I have to say is much more convienent than framadate (or doodle). I wish something with a similar UI ran on Sandstorm.
<isd>
(It lets everyone just click & drag regions on a calendar, rather than having to propose several discrete times).
cwebber has joined #sandstorm
koo6 has joined #sandstorm
<ocdtrekkie>
Davros 0.31.0 is really, really neat.
<ocdtrekkie>
I found bugs, but 0.31.0 really makes Davros a solid file manager, not just a file bucket.