sechmachine/VerseVDI-Protocol
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat(protocol): negotiate registered gateway profiles
Verify Protocol / verify (push) Canceled after 0s
Details
Verify Protocol / module (push) Successful in 2m29s
Details

Browse Source
This commit is contained in:
sechmachine
2026-07-30 04:47:52 +07:00
parent d26f8b60f8
commit e58f1c7c48
17 changed files with 227 additions and 67 deletions
Download Patch File Download Diff File Expand all files Collapse all files
openspec/changes/phase3c-provider-stream-policy/design.md
+6 -1
View File
@@ -7,13 +7,15 @@ The Server resolves an immutable stream-policy version, but RC6 provider work ca
**Goals:**
- Carry only the effective launch settings required by the provider boundary.
- Express client decode support as an ordered set of existing registered profiles.
- Generate the same ordered registered-profile intersection for every consumer.
- Generate identical validation from the canonical schema for all bindings.
- Preserve the policy-version identifier for audit correlation.
**Non-Goals:**
- Publish or mutate RC6.
- Add provider-specific capability negotiation to Protocol.
- Add a provider-specific token grammar or generic capability framework.
- Expose provider work or policy internals to Verse clients.
## Decisions
@@ -22,11 +24,14 @@ The Server resolves an immutable stream-policy version, but RC6 provider work ca
- Carry the Server-selected target bitrate rather than all policy bounds because Apollo ANNOUNCE consumes one configured bitrate.
- Permit canonical `H264`, `HEVC`, and `AV1` values in the contract. A provider implementation must reject values it cannot honor rather than silently downgrade them.
- Carry `audio_enabled` even though the current Apollo path cannot truthfully disable audio; the Data Plane must fail closed for that combination.
- Change `client_decode` from one opaque string to a non-empty ordered unique array of registered profile identifiers. Preference belongs to the first peer's order.
- Generate `IntersectCapabilityProfiles` from the canonical schema so Protocol, Server, and Data Plane do not maintain separate interpretations.
## Risks / Trade-offs
- [New required field breaks RC6 consumers] → Publish only under a separately authorized new immutable version and pin both consumers after empty-cache resolution.
- [Provider capabilities differ] → Validate the effective policy against the selected provider before readiness.
- [Peers advertise no common registered profile] → Reject admission instead of inventing a combined token or silently downgrading.
## Migration Plan