HeiKyu/Rendezvous
2
0
Fork 0
Code Issues 27 Pull Requests Actions Packages Projects Releases Wiki Activity

Ratify the v1 architecture, trust model, and privacy threat model #2

New Issue
Open
opened 2026-07-15 10:04:12 +02:00 by Kyuubi · 2 comments
Kyuubi commented 2026-07-15 10:04:12 +02:00
Owner
Copy Link
Copy Source

Parent: #1

Outcome

Record the load-bearing decisions for Rendezvous as a connection control plane before implementation fixes accidental protocol or security behavior.

Scope

  • Define HTTP, UDP, operator, client SDK, game host, secret provider, reverse proxy, and future shared-store trust boundaries.
  • Ratify the domain glossary: SessionListing, Lease, HostPresence, JoinAttempt, PunchCapability, and ConnectionTicket.
  • Decide publisher trust modes for managed dedicated servers and player-hosted sessions. A reusable secret embedded in a public game binary is explicitly not authentication.
  • Define public versus unlisted browsing, final host admission authority, protocol compatibility, address-family support, and fallback scope.
  • Classify endpoint, metadata, token, audit, and aggregate metric data; set retention/redaction rules.
  • Define the single-active v1 availability model, restart behavior, target SLOs, initial supported/capacity profiles, and the condition that justifies shared state or relay.
  • Establish amplification, queue, packet, metadata, token, and clock-skew budgets.
  • Document threat actors and misuse cases: spoofing, reflection, private-network probing, replay, listing spam, scraping, cross-tenant access, metadata injection, credential theft, and denial of service.

Acceptance criteria

  • ADRs and a threat model are committed with data-flow/state diagrams.
  • Every security promise in README maps to an enforceable control and planned test.
  • “Join authorization” is defined as permission to attempt a connection; authoritative game admission remains game-owned.
  • Player-host, dedicated-host, endpoint retention, IPv4/IPv6, fallback, storage, and telemetry decisions are explicit.
  • Non-goals remain gameplay authority/traffic, accounts/social/chat, skill matchmaking, and relay in v1.
  • Remaining owner decisions are named rather than silently defaulted.
Parent: #1 ## Outcome Record the load-bearing decisions for Rendezvous as a connection control plane before implementation fixes accidental protocol or security behavior. ## Scope - Define HTTP, UDP, operator, client SDK, game host, secret provider, reverse proxy, and future shared-store trust boundaries. - Ratify the domain glossary: `SessionListing`, `Lease`, `HostPresence`, `JoinAttempt`, `PunchCapability`, and `ConnectionTicket`. - Decide publisher trust modes for managed dedicated servers and player-hosted sessions. A reusable secret embedded in a public game binary is explicitly not authentication. - Define public versus unlisted browsing, final host admission authority, protocol compatibility, address-family support, and fallback scope. - Classify endpoint, metadata, token, audit, and aggregate metric data; set retention/redaction rules. - Define the single-active v1 availability model, restart behavior, target SLOs, initial supported/capacity profiles, and the condition that justifies shared state or relay. - Establish amplification, queue, packet, metadata, token, and clock-skew budgets. - Document threat actors and misuse cases: spoofing, reflection, private-network probing, replay, listing spam, scraping, cross-tenant access, metadata injection, credential theft, and denial of service. ## Acceptance criteria - ADRs and a threat model are committed with data-flow/state diagrams. - Every security promise in README maps to an enforceable control and planned test. - “Join authorization” is defined as permission to attempt a connection; authoritative game admission remains game-owned. - Player-host, dedicated-host, endpoint retention, IPv4/IPv6, fallback, storage, and telemetry decisions are explicit. - Non-goals remain gameplay authority/traffic, accounts/social/chat, skill matchmaking, and relay in v1. - Remaining owner decisions are named rather than silently defaulted.
Kyuubi self-assigned this 2026-07-16 04:02:48 +02:00
Kyuubi commented 2026-07-16 04:02:49 +02:00
Author
Owner
Copy Link
Copy Source

Starting the v1 architecture and threat-model foundation. I’ll ratify the roadmap’s recommended v1 choices, map README security promises to concrete controls/tests, and explicitly record any remaining owner decisions.

Starting the v1 architecture and threat-model foundation. I’ll ratify the roadmap’s recommended v1 choices, map README security promises to concrete controls/tests, and explicitly record any remaining owner decisions.
Kyuubi commented 2026-07-16 04:11:55 +02:00
Author
Owner
Copy Link
Copy Source

Architecture checkpoint completed and pushed on codex/issue-2-v1-architecture (commit 286fbfe). It adds accepted ADRs, trust/data-flow/state diagrams, privacy/availability/safety budgets, the v1 threat model, and a README security-control/test matrix. Static diff, Markdown links, and an adversarial branch audit pass; build/tests are not available until #3. The issue will close when the commit lands on main.

Architecture checkpoint completed and pushed on `codex/issue-2-v1-architecture` (commit `286fbfe`). It adds accepted ADRs, trust/data-flow/state diagrams, privacy/availability/safety budgets, the v1 threat model, and a README security-control/test matrix. Static diff, Markdown links, and an adversarial branch audit pass; build/tests are not available until #3. The issue will close when the commit lands on `main`.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
Kyuubi schmidt.florian (Florian Schmidt)
No Assignees Kyuubi
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: HeiKyu/Rendezvous#2
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?