betterNAS/docs/references.md

betterNAS References

This file tracks the upstream repos, tools, and docs we are likely to reuse, reference, fork from, or borrow ideas from as betterNAS evolves.

The ordering matters:

1. self-hosted WebDAV stack first
2. control-server and web control plane second
3. optional cloud adapter later

Primary now: self-hosted DAV stack

Node-service and WebDAV

• Go WebDAV package

  • docs: https://pkg.go.dev/golang.org/x/net/webdav
  • why: embeddable WebDAV implementation for the NAS runtime

• hacdias/webdav

  • repo: https://github.com/hacdias/webdav
  • why: small standalone WebDAV reference

• rclone serve webdav

  • repo: https://github.com/rclone/rclone
  • why: useful reference for standing up WebDAV over existing storage

Self-hosting and NAS configuration

• NixOS manual

  • docs: https://nixos.org/manual/nixos/stable/
  • why: host module design and declarative machine setup

• Nixpkgs

  • repo: https://github.com/NixOS/nixpkgs
  • why: service module and packaging reference

• Docker Compose docs

  • docs: https://docs.docker.com/compose/
  • why: current self-hosted runtime packaging baseline

Primary now: control-server

Backend and infra references

• Go routing enhancements

  • docs: https://go.dev/blog/routing-enhancements
  • why: low-dependency baseline for the API

• chi

  • repo: https://github.com/go-chi/chi
  • why: thin router if stdlib becomes too bare

• PostgreSQL

  • docs: https://www.postgresql.org/docs/
  • why: source of truth for product metadata

• pgx

  • repo: https://github.com/jackc/pgx
  • why: Postgres-first Go driver

• sqlc

  • repo: https://github.com/sqlc-dev/sqlc
  • why: typed query generation for Go

• Redis

  • docs: https://redis.io/docs/latest/
  • why: cache, jobs, and ephemeral coordination

• go-redis

  • repo: https://github.com/redis/go-redis
  • why: primary Redis client

• asynq

  • repo: https://github.com/hibiken/asynq
  • why: practical Redis-backed background jobs

• oapi-codegen

  • repo: https://github.com/oapi-codegen/oapi-codegen
  • why: generate Go and TS surfaces from OpenAPI with less drift

Primary now: web control plane and local device

Web control plane

• Next.js

  • repo: https://github.com/vercel/next.js
  • why: control-plane web UI

• Turborepo

  • docs: https://turborepo.dev/repo/docs/crafting-your-repository/structuring-a-repository
  • why: monorepo boundaries and task graph rules

macOS mount UX

• Apple Finder Connect to Server

  • docs: https://support.apple.com/en-lamr/guide/mac-help/mchlp3015/mac
  • why: baseline native mount UX on macOS

• Apple Finder WebDAV mounting

  • docs: https://support.apple.com/is-is/guide/mac-help/mchlp1546/mac
  • why: direct WebDAV mount behavior in Finder

• Apple developer docs

  • docs: https://developer.apple.com/documentation/
  • why: Keychain, helper apps, launch agents, and later native integration

• Keychain data protection

  • docs: https://support.apple.com/guide/security/keychain-data-protection-secb0694df1a/web
  • why: baseline secret-storage model for device credentials

• WebDAV RFC 4918

  • docs: https://www.rfc-editor.org/rfc/rfc4918
  • why: protocol semantics and caveats

Optional later: cloud adapter

Nextcloud server and app references

• Nextcloud server

  • repo: https://github.com/nextcloud/server
  • why: optional browser/share/mobile substrate

• Nextcloud app template

  • repo: https://github.com/nextcloud/app_template
  • why: official starting point for the thin adapter app

• Nextcloud AppAPI / ExApps

  • docs: https://docs.nextcloud.com/server/latest/admin_manual/exapps_management/AppAPIAndExternalApps.html
  • why: external app integration model

• Nextcloud WebDAV access

  • docs: https://docs.nextcloud.com/server/latest/user_manual/en/files/access_webdav.html
  • why: protocol and client behavior reference

• Nextcloud external storage

  • docs: https://docs.nextcloud.com/server/latest/user_manual/en/external_storage/external_storage.html
  • why: storage aggregation reference

Working rule

Use these references in this order:

1. steal primitives that solve the self-hosted DAV problem first
2. adapt them at the control-server boundary
3. only pull in optional cloud layers when the core mount product is solid