diff --git a/documentation/design.md b/documentation/design.md index 04797b8..77cde1e 100644 --- a/documentation/design.md +++ b/documentation/design.md @@ -1,8 +1,11 @@ # Design -- There will be two SQLite databases that complement each other. +- The integrated hardware + software solution will be called "Zoöbox". + The Linux application that can also be used separately will continue to be called "Zoödex". -- `$XDG_DATA_HOME/zoodex/shared.sqlite` will be downloaded over HTTP from `kernelmaft.com` and contain information about the films and series themselves, their bittorrent magnet links, and what files and tracks within each torrent to use. +- There will be two Zoödex SQLite databases that complement each other. + +- `$XDG_DATA_HOME/zoodex/shared.sqlite` will be downloaded over IPv6 + HTTPS from `kernelmaft.com` and contain information about the films and series themselves, their bittorrent magnet links, and what files and tracks within each torrent to use. - `$XDG_DATA_HOME/zoodex/local.sqlite` will be created locally and contain information about what films and series the user has watched. This can be extended to allow the user to create a personal collection, i.e. a subset of all media available of their own choosing. @@ -28,10 +31,49 @@ The bittorrent hash here is provided by `sources.bittorrent_hash` in the shared database. The file path here is provided by `sources.file_path` in the shared database. -- The video track that will be played for a piece of media will be within this file, but otherwise determined by LibMPV. +- The video track that will be played for a piece of media will be within this file, but otherwise determined by limpvv. - The audio track that will be played for a piece of media will be within this file, and its track number is given by `sources.audio_track` in the shared database. - The subtitle track that will be played for a piece of media can be within this file, or if present an additional subtitle file. Its track number is given by `sources.subtitle_track` in the shared database. - We rely on the assumption that when we provide LibMPV with a file and an additional subtitle file, all the combined subtitle tracks will always have the same track numbers. + We rely on the assumption that when we provide libmpv with a file and an additional subtitle file, all the combined subtitle tracks will always have the same track numbers. + +- We may need to store additional information about the progress of the bittorrent transfers depending on the library. + +- Should Zoödex manage the input of local system configuration such as for wifi and VPN, or should that be a separate application? + +- Similarly, should we manage the storing of local system configuration ourselves (read: in the local database), or leave it to systemd? + +- We need hardware that supports hardware-accelerated decoding of at least H264, H265, VP8 and VP9 under NixOS. + Depending on the window manager we end up using we may also require 2D OpenGL or Vulkan acceleration. + This will more likely hinge on the availability of drivers than on the hardware itself. + +- As a window manager we can consider Niri, Sway or even Cage. + +- Controlling the UI will be done via a remote-like smartphone app. + We can connect over wifi or bluetooth. + Wifi is probably easier for the user but we'll need to figure out a way for the two hosts to find each other on the network. + Bluetooth makes conceptually more sense here but is more work for the user to connect. + +- We can extend the functionality later by also providing built-in Youtube streaming and a web browser. + +- The system will run NixOS, and the system image expression will not have any configurable parameters. + All configuration will be local and considered mutable state by Nix, i.e. it doesn't concern itself with it. + +- We need to figure out the best way to remotely deploy updates to Zoöboxes in a reliable and non-obtrusive way. + We will most likely need to pre-build and provide binaries through a Nix binary cache, because noone wants their set-top box compiling its own update for hours. + If we end up going with ARM64 hardware this will mean cross-compilation which is an additional piece of complexity. + +- Downloading system updates should happen in the background. + +- If we can use an LTS kernel reboots should rarely be required, but whenever they are we probably should do it when the user turns the box "off". + Under normal circumstances this will suspend Linux, but if a reboot request is pending the box will reboot (thus fully applying the update) and then suspend. + +- We need some way for the user to be able to turn the box back on from the smartphone app. + Investigate what options we have in Linux when we're in the suspend state, maybe WoL? + +- For the other hardware of the Zoöbox we will need a big but cheap HDD and some set-top looking case. + Onto that case will of course go a snazzy "Zoöbox" decal. + +- For remote troubleshooting key auth only SSH should be fine.