Add Nix flake, lockfile, and README documentation

[pmarreck]

Add flake.nix and flake.lock to provide a deterministic Nix development environment; document Nix usage and instructions in README.md

[braden-w]

Hey @pmarreck, thank you for this comprehensive PR! I really appreciate the work you've put into providing a deterministic development environment with Nix. This is a valuable contribution that will help developers get up and running more easily.

However, I'd love to suggest breaking this PR into smaller, focused changes to make the review process more manageable and ensure each change gets the proper attention it deserves (plus, you can get more contributions/PR merged)!

1. Nix Development Environment (Primary PR)

flake.nix, flake.lock, and README.md changes for Nix documentation and usage instructions.

This should be the main PR focusing purely on the Nix development environment setup.

2. Tauri Security Capabilities Refinement

apps/whispering/src-tauri/capabilities/default.json for FS permission scoping.

This is a significant security change that deserves its own focused review. The current change restricts all FS operations to $APPDATA only:

{
  "identifier": "fs:allow-read",
  "allow": [
    { "path": "$APPDATA" },
    { "path": "$APPDATA/**" }
  ]
}

We need to discuss this more because we want users to be able to store data outside the app data folder. This increases the security scope but provides better user flexibility. Should we allow user home directory access for exports/imports? Custom storage locations? Specific folder selection through dialogs?

3. Path Handling Improvements

apps/whispering/src/lib/components/settings/WhisperModelSelector.svelte to use join() instead of string concatenation.

This is a good improvement for cross-platform path handling and should be its own small PR.

4. Recording Backend Configuration Changes

Changes to apps/whispering/src/lib/settings/settings.ts (default backend change from 'browser' to 'native') and removing !window.__TAURI_INTERNALS__ checks in the device selectors.

These changes affect recording behavior and should be discussed separately as they change default user experience. Can you share the reasoning behind changing the default to 'native'? This affects new user experience, platform compatibility, and recording quality/performance. Also, what's the motivation for removing the Tauri internals checks? This could affect web vs desktop behavior detection.

Would you be willing to split this into separate PRs? I think it would help us get the Nix environment merged quickly (which is the main valuable contribution), properly discuss the security implications of the FS changes, review the recording backend changes with appropriate testing, and ensure each change is well-documented and justified. I'm happy to help split and merge them in so you get more contribution numbers if that helps.

Thanks again for this work! The Nix setup looks comprehensive and will be really helpful for the development community.

[pmarreck]

Good points. The second set of commits were not intended to be part of this PR and were just my attempts to get the app running properly on Linux/NixOS (so far still unsuccessful; latest issue has to do with microphone permissions and then recording permissions... Tauri apparently has a ridiculously comprehensive security model...)

Agree to separate them. Give me a few

[braden-w]

Thank you! In the process of giving an alternative for recording with ffmpeg, really hoping that fixes these Linux bugs 😅

[pmarreck]

@braden-w
I've removed the non-Nix-focused commits from the PR and moved those to another branch on my fork (resolve-app-issues-on-linux). My bad, I was getting rusty! Thanks for being cool about it.

(Honestly, now that I think about it, the nix stuff should also be on its own branch, sigh. Want me to do that too and just create a new PR from that branch?)

Even though I'm normally a Mac guy, I find I need/want Linux enough to be motivated to get the app side working with the correct permissions (I miss superwhisper mac when I'm on linux, lol). If I figure that out I'll make a new PR for that and we can discuss some of the stuff you brought up here, there (all good questions and correct concerns, btw!). Sound good?

[pmarreck]

Regarding Nix itself-

It took me ten years to join the Nix cult. I had all the usual complaints: it’s weird, the language is alien, “derivations” sound like a cult term, etc. And honestly, I still think that - but now I’m typing this from NixOS.

Why? Deterministic builds. They front-load pain like a strict type system, but once it compiles, you’re basically bug-proof and reproducible forever. As I’ve gotten older (and crankier about Python projects breaking themselves), reproducibility and preservation have become sacred.

Nix is complex because it’s solving an irreducibly complex problem: dependency management across everything. The Nix language is just JSON + pure lambdas + sugar. A “derivation” is the fully evaluated, explicit version of your flake - all dependencies resolved, env vars fixed, references expanded. Dependencies are derivations too, and their hashes form a content-addressed Merkle DAG.

Result: deterministic builds, near-eternal reproducibility. NixOS errors happen up front, then never again (though the logs can be spicy).

Elevator pitch: Nix kills “it-worked-yesterday” bugs and lets you reproduce any stack anywhere. One command, any machine. No dependency collisions. No silent rot. LLMs now make the rough edges manageable.

I’m no Nix guru, but once you grok enough to be productive, there’s no going back. I run nix-darwin on macOS and Nix under WSL. And NixOS? You can switch window managers like changing shirts, and if it breaks... just roll back in GRUB. Experimentation without consequences.

[pmarreck]

@braden-w
Jesus. Dude, did I accidentally force-push main (!!!!???!!!!) I just noticed that! OMG. (How did I even have the rights to do that?? Add protections to the main branch to prevent this!)

I AM SO SORRY. In the process of moving things to my own branch (which I used LLM assistance for), I don't know how that happened and I (and the LLM) should know better- it's possible that the LLM did this? I'm requiring it to ask for approval for all git commands from now on

[pmarreck]

I would actually still like something like this working on my nixos install, which is why I checked back here- had no idea about the errant force push (JFC)

That would have left a bad taste in my mouth if I were you; apologies, again. Argh!

[braden-w]

Hey @pmarreck, good news: no force-push to main happened! The main branch is completely intact.

I totally understand the panic though. Looking at the commit history, I think what happened is that your PR branch is named 'main' on your fork, which probably confused either you or the tooling you were used. The commit from your PR (bc78eba) is NOT in origin/main, and the PR is still open and has never been merged. Everything is safe!

I'm really sorry for the delay in getting this merged; I've been heads-down on other feature development.

Also, might be worth setting up branch protection rules on main to prevent any future accidents. GitHub can block force-pushes and require PRs for any changes, which helps avoid these scares.

Thanks for your patience, and sorry for the stress!