80 lines
2.4 KiB
Markdown
80 lines
2.4 KiB
Markdown
# 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.
|