Food for thought: Using zfs-receive for updates?

Since (unless I missed something) there has not been any final decision on how hello is going to be updated in the future, here's another take at what might be a possible solution. Instead of theorizing first, I'm going to present what it could look like first so that it's easier to get an idea.

1. Create an ISO that does come with a live system and installer only (small image) or that + a **zfs-send stream as a file** (large image).
2. When installing, only prepare the pool, then `zfs-receive` the stream (after either downloading the current one from the net or using the one on the installation media) to install the OS.
3. Base system upgrade would not involve `freebsd-update(8)` but rather check free space, download a newer stream, zfs-receive it to make it available in the filesystem and then activate the new BE to be used after the next reboot.
4. If that were to work well, we could experiment with a service that zfs-sends on demand and clients receiving directly from the net instead of first downloading a stream file and then receiving locally.

Such an approach would obviously work poorly in vanilla FreeBSD as packages may depend on system libraries that could introduce ABI changes on a major version upgrade, so we need `/usr/local` as part of the BE (as it is by default). Which then means that applications would have to be always reinstalled after the receive (which is perfectly doable but not prett).

For hello however... As an AppImage-based approach to application packaging is likely to be implemented, we'll see self-contained applications in the end that are kind of separate from the base system (according to the _platform_ idea).

One downside would be that we lose delta diffs that `freebsd-update(8)` give us. But considering e.g. HardenedBSD's upgrade mechanism which also involves always distributing the whole base system (for the simple reason that providing deltas is somewhat involved and the small team decided to not put the required resources into that), it's not actually that bad. Especially since ZFS offers compressed send / receive and FreeBSD's base system is not terribly large by today's standards.

We might even go one step further and consider some traditional packages an "extended base". I'm especially thinking of Xorg + mesa + drm stuff here which could be included into the ZFS stream that's received for any update. This would create a unity between the actual FreeBSD base system and the "platform core" (or whatever to call it). We could run tests against it before releasing the stream as a new update to make sure that graphical logins _never ever_ break during an update.

A naming convention could be something like year, month, FreeBSD version, hello revision (e.g. 2021-05-13.0-p0h0).

Just sharing a somewhat raw idea here. While I didn't see any obvious (for me) problems that are not solvable, there might be some. If anybody is interested in this topic, let's have a discussion.