docs: add NixOS packaging plan for community review

[cboecking]

This PR proposes a comprehensive plan to package xs (cross-stream) for nixpkgs with full systemd service support.

Background

We recently successfully packaged http-nu for nixpkgs (PR #458947). During that process, we created a detailed NIXOS_PACKAGING_GUIDE.md documenting the entire workflow.

xs requires more than http-nu did - it needs a NixOS module for running as a system service with persistent state management.

What This PR Contains

1. NIXOS_PACKAGING_PLAN.md - Comprehensive plan covering:

   • Architecture differences from http-nu (daemon vs CLI tool)
   • Package definition structure
   • NixOS module design with systemd service
   • Example user configurations
   • Open questions for your feedback

2. package.nix.example - Skeleton showing the nixpkgs package structure

3. xs-module.nix.example - Skeleton showing the NixOS service module structure

Seeking Your Feedback

Before we invest time implementing this, we'd love your input on several design decisions:

• Default user name: xs vs cross-stream?
• Data directory location preferences
• Unix socket configuration options
• xs.nu integration approach
• Security hardening preferences
• Network exposure defaults

See the Open Questions section in NIXOS_PACKAGING_PLAN.md for details.

Next Steps

Once you've reviewed and provided feedback, we'll:

1. Implement the package in our nixpkgs fork
2. Implement the NixOS module
3. Test thoroughly in NixOS VMs
4. Submit to nixpkgs with both components
5. Maintain as nixpkgs maintainers

Benefits to xs Community

• Easy installation for NixOS users
• Declarative service configuration
• Guaranteed reproducible deployments
• Visibility on https://search.nixos.org/packages
• Automated CI testing across platforms
• Community contributions and updates

Looking forward to your thoughts!

[cablehead]

Default user name: xs vs cross-stream?

i think xs

Data directory location preferences, Unix socket configuration options

$"($env.XDG_DATA_HOME)/store"

xs.nu integration approach

just keep $env.XS_ADDR blank, it'll default to XDG_DATA_HOME. it'd be nice if use xs.nu * is called on nu start up.

Security hardening preferences, Network exposure defaults

maybe listen on local unix socket only, by default; could $"($env.XDG_DATA_HOME)/store" be owned by the nix user?

[cboecking]

The defaults you see referenced in the document relate to when xs is configured as a system-wide-service (not for an individual user).

There are effectively two modes:

• normal command mode - where all the defaults you built into the tool take effect.
• system-wide-service model - where you need to deliberately choose the setting that will be applied because things like $"($env.XDG_DATA_HOME)/store" are not really defined for system users. It is better to explicitly state them so that they are easily observed.

If you specify cross.stream as a package, it will always install the app/command. Any user can use it as they deem appropriate (using the logical user defaults as you have stated).

Additionally, you can set options to 'also' run it as a system-wide-service (in addition to still being able to run the command). In this context, thinks like $"($env.XDG_DATA_HOME)/store" do not make sense.

Confirmed on 'xs' as the service username.

Does this help? If I misunderstood your response, please address.

[cablehead]

Do we still want this one Chuck? @cboecking

[cboecking]

I think we should close this pull request. I think we should add xs to nix; however, my preference is to wait an see how the embedded xs into http-nu goes before we proceed. I feel like the http-nu capabilities might change some of our preferences. Acceptable?

[cablehead]

Acceptable?

yep.