betterNAS/docs/references.md
2026-04-01 16:43:25 +00:00

146 lines
4.2 KiB
Markdown

# 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