initial commit

docs/data-and-integrations.md

@@ -0,0 +1,79 @@
+# Data And Integrations
+
+## Steam Web API
+
+The MVP should use the Steam Web API for reliable owned-game import. Users should be guided through supplying their own Steam Web API key.
+
+Relevant Steam API areas:
+
+- Resolve vanity URL to Steam ID.
+- Fetch owned games.
+- Fetch player summaries.
+- Fetch recently played games, if useful.
+
+Known limitation: Steam library data may not be available when the user's profile or game details are private. Private-profile fallback import is out of scope for the MVP.
+
+## SteamDB Consideration
+
+SteamDB can be investigated as an alternative metadata source only after confirming availability, terms, and suitability. It should not be assumed as a replacement for the Steam Web API until that validation is complete.
+
+## Steam Store Metadata
+
+Steam store endpoints may be useful for metadata such as:
+
+- Header images
+- Genres
+- Categories
+- Short descriptions
+- Release date
+
+These endpoints should be cached locally and refreshed conservatively.
+
+## Completion Time Data
+
+Estimated game length is required for the MVP recommendation flow.
+
+Preferred direction:
+
+- Use a HowLongToBeat-compatible API or library after validating terms, maintenance status, and package quality.
+- Cache estimates locally with source and confidence fields.
+- Do not allow manual metadata editing in the MVP.
+
+The project should avoid depending on an unofficial or license-unclear source without documenting the risk.
+
+## Local Storage
+
+Use SQLite for durable local data.
+
+The app should support:
+
+- Local-only operation after import.
+- Metadata caching.
+- Local settings.
+- Resetting cached metadata.
+
+Manual data import/export is out of scope for the MVP.
+
+## Privacy
+
+Default privacy posture:
+
+- Store user data locally.
+- Do not create a hosted account for MVP.
+- Do not transmit the user's library to third-party services beyond the configured metadata providers required for the recommendation flow.
+- Document which Steam API calls are made.
+- Do not collect telemetry in the MVP.
+
+## API Key Handling
+
+The MVP should use user-provided API keys where required.
+
+Credentials should not be stored as plain text if the platform provides a practical secure storage option.
+
+Preferred order:
+
+- Use OS-provided credential storage through a Tauri-compatible plugin or Rust crate.
+- Fall back to a clearly documented local settings file only during early development.
+- Never commit real API keys.
+
+No hosted proxy service is planned for the MVP.