Evaluate whether steam-go should eventually support deeper Steam product metadata such as PICS, AppInfo, PackageInfo, depots, branches, builds, and manifest metadata.
This issue is for long-term architecture planning only. No PICS protocol implementation is planned directly inside steam-go at this stage.
Areas to Evaluate
- PICS product information
- AppInfo
- PackageInfo
- Depot metadata
- Branches
- Build IDs
- Manifest metadata
- Change numbers / product update tracking
- Steam CM / session requirements needed to access these capabilities
Preferred Direction
Keep Steam network protocol concerns outside the current steam-go HTTP-oriented core.
Evaluate creating a focused standalone low-level Go library responsible for:
- Steam CM connectivity
- Required protocol / protobuf handling
- PICS requests
- AppInfo / PackageInfo
- Depot / branch / build metadata
steam-go could later integrate that library through an optional addon or higher-level product-information layer.
Goals
-
Avoid turning steam-go into a full Steam client protocol implementation
-
Keep HTTP/Web API and Steam network protocol responsibilities separated
-
Create a reusable foundation for deeper Steam product metadata
-
Enable future use cases such as:
- game update detection
- build tracking
- depot inspection
- branch monitoring
- SteamDB-style data tooling
- dedicated server update tooling
Non-goals
- Implementing PICS directly as part of this issue
- Building a full SteamKit replacement
- Friends / chat
- Trading or Market automation
- Game Coordinator support
- Full depot downloading
Long-term Plan
- Research the minimum Steam network/PICS protocol surface required for product information.
- Define the boundary between
steam-go and a potential standalone low-level library.
- Prototype AppInfo / PackageInfo retrieval independently from
steam-go.
- Evaluate stability, maintenance cost, and API design.
- If the standalone layer proves viable, integrate it into
steam-go as an optional higher-level capability.
Evaluate whether
steam-goshould eventually support deeper Steam product metadata such as PICS, AppInfo, PackageInfo, depots, branches, builds, and manifest metadata.This issue is for long-term architecture planning only. No PICS protocol implementation is planned directly inside
steam-goat this stage.Areas to Evaluate
Preferred Direction
Keep Steam network protocol concerns outside the current
steam-goHTTP-oriented core.Evaluate creating a focused standalone low-level Go library responsible for:
steam-gocould later integrate that library through an optional addon or higher-level product-information layer.Goals
Avoid turning
steam-gointo a full Steam client protocol implementationKeep HTTP/Web API and Steam network protocol responsibilities separated
Create a reusable foundation for deeper Steam product metadata
Enable future use cases such as:
Non-goals
Long-term Plan
steam-goand a potential standalone low-level library.steam-go.steam-goas an optional higher-level capability.