Before Starting just wanna point out it's a overthinked process might interest you or might give you a feel it's trying to solve a problem that doesn't exist, feel free to put suggestion.

Context

I have a remote NixOS device accessed via SSH + Tailscale. I want full disk encryption where the disk does not decrypt without a passphrase - even if the whole device is stolen. Since it's remote, I also need to deliver that passphrase over the network.

What I've explored

TPM + PCR (Clevis + TPM2)

The LUKS key is sealed into the TPM against PCR values (a hash chain of the boot process). On normal boot, the boot chain is unmodified, PCRs match, TPM releases the key, disk auto-decrypts. If the boot chain is tampered, PCR values change and the TPM refuses.

Issue: If the whole device is stolen, the thief boots it normally - boot chain is unchanged, PCRs match, TPM releases the key. The disk decrypts for the thief. Your login password is there, but the disk-level data is already compromised.

Additionally, since /boot is unencrypted, an attacker with physical access could modify the initrd to install a keylogger and capture the passphrase on a subsequent remote unlock. Secure boot can mitigate this, but can be disabled by anyone with physical access to the machine.

Initrd SSH + network stack

Run SSH (and potentially Tailscale) in the initrd to remotely enter the LUKS passphrase.

Issue: This introduces multiple points of failure - NIC driver, DHCP, WiFi firmware, Tailscale state, coordination server reachability. Any link breaks and you're locked out remotely. WiFi in initrd is especially fragile (firmware blobs, WPA supplicant). The device should ideally come online whenever internet is available, but the initrd network stack is not designed for this kind of resilience.

Other approaches I've come across

Clevis + Tang (Network-Bound Disk Encryption)

A Tang server runs on another machine you control (e.g., a VPS). The LUKS key is sealed against the Tang server - the disk auto-decrypts only if it can prove it can reach the server. If the laptop is stolen, you take the Tang server offline (or revoke the device) and the disk can't decrypt. No passphrase needed for normal boots.

Downside: Depends on the Tang server being available. If your VPS is down, you need a passphrase fallback. Also, the thief could potentially run their own Tang server if they know the configuration (though Clevis pins the server's advertised keys, making this non-trivial).

Mandos

Similar concept to Tang - a Mandos server holds the decryption key and only releases it to proven clients (identified by PGP key). If the device is stolen, you revoke its access on the server. The initrd client is minimal compared to a full Tailscale stack.

Downside: Still depends on a server being reachable. Still a network dependency in initrd.

TPM + PIN (BitLocker-style)

TPM requires both PCR match and a PIN. A thief with the whole machine can't decrypt without the PIN. This solves the "whole device stolen" problem.

Downside: The PIN requires physical presence to enter. This defeats the remote unlock goal. (Could theoretically be delivered via initrd SSH, but then you're back to the fragile initrd network stack problem.)

USB key dongle

LUKS key on a physical USB. Insert to boot, remove after. Stolen without USB = data safe.

Downside: Requires physical presence. Not viable for a truly remote device.

In the end I am thinking to get the whole network stack in initrd and put passphrase via ssh, what do you guys think?

Os should not matter in this whole discussion as this is independent issue, but still m using Nix so will try to get things working on there first.

naste - a paste service with zero dependencies, no database, just files

I wanted a paste service that's trivial to self-host. No database, no accounts, no bloat. Just pipe text and get a URL.

GitHub: https://github.com/semi710/naste Docs: https://naste.semi.sh Live demo: https://paste.semi.sh

$ echo "hello world" | naste
https://paste.semi.sh/abc123

$ curl https://paste.semi.sh/abc123
hello world

# private paste (HTTP Basic Auth, password-protected URL)
$ cat secrets.env | naste --private
https://paste.semi.sh/private/abc123

One Go binary. Filesystem storage. Custom slugs, private pastes with Basic Auth, syntax highlighting in browser. That's it.

Easiest way to host:

docker run -d -p 8080:8080 -v naste-data:/data/paste \
  ghcr.io/semi710/naste-server:latest

Or NixOS:

services.naste-server.enable = true;

Full docs cover CLI usage, Docker, Nix, NixOS module, Home Manager module, API reference, and reverse proxy setup.

Feedback welcome.

Been exploring the “dendritic” style patterns people use in the Nix ecosystem recently and realized my setup evolved into something pretty similar over time.

A while back I built nix-wire, a small library/tool that wires directories/modules automatically so I can keep my Nix configs minimal and avoid repetitive boilerplate.

My actual config using it is here: ndots

The idea was heavily inspired by numtide/blueprint, though I eventually simplified things toward my own workflow and preferences.

I know there are multiple projects solving similar problems in different ways, but this approach has worked extremely well for me. I built it pretty early on and honestly haven’t had to touch much since because it has been stable and predictable.

Would love feedback from other Nix folks:

• things you think are designed well
• obvious mistakes or anti-patterns
• improvements worth making
• hacks/tricks you use for large Nix configs
• better ways to structure module discovery/wiring

Curious how others approach this problem space.

https://github.com/semi710/nvix/blob/265bd4cc125d1f621acfcc4a93cde3d89b4dfa62/plugins/common/default.nix#L156-L210

Above is what I am doing, it's instantaneous and works.

Anything else you guys do or nvim has natively that I am unaware of?