Define metaserver registration, discovery, and rendezvous v1

[zoeyrose]

Outcome

Define a minimal authenticated Game Protocol 1-adjacent contract between Go servers, the existing MIT metaserver, and Rust clients, with static discovery and publisher authentication versioned independently from gameplay messages.

The protocol repository owns schemas, canonical/signature inputs, state transitions, limits, shared fixtures, and compatibility rules. Deployment defaults bind those contracts to meta.atrinik.org, publish.meta.atrinik.org, and—only if justified—rendezvous.meta.atrinik.org.

Discovery contract

• Define one bounded typed public directory model and canonical versioned JSON representation for https://meta.atrinik.org/index.json.
• Define deterministic semantic projection rules/fixtures for the HTML/XML views without making HTML a protocol input.
• Cover server ID and QUIC certificate identity material, protocol/content compatibility, name/description/region, players/capacity/status, freshness/expiry, and an optional explicit direct DNS hostname/port.
• A public direct endpoint is optional and operator-supplied. Request-source addresses can never become directory data implicitly.
• Define exact field/list/body bounds, Unicode/normalization, ordering, nullability/absence, schema-version rejection, stale/empty behavior, cache generation/ETag metadata, and compatibility filtering.
• Preserve direct configured connection when discovery is unavailable.

Publisher contract

• Define one authenticated request per registration/update under the Game Protocol 1 publisher namespace; do not define an OTP/challenge round trip.
• Bind publisher ownership to the persistent QUIC server identity clients pin where practical.
• Specify a strict interoperable subset of RFC 9421 HTTP Message Signatures plus RFC 9530 Content-Digest, or a formally specified fixed canonical binary envelope if that is demonstrably smaller/safer for all implementations.
• Authenticate method, authority, path, content type/body digest, server ID, protocol/environment domain, unsigned 64-bit monotonic sequence, random nonce, and created/issued-at.
• Define registration/key rotation/revocation, atomic replay/order/presence semantics, sequence-recovery behavior, idempotency after ambiguous failure, bounded clock skew, and stable error codes.
• Separate classic and Game Protocol 1 route, schema, fixture, signature-domain, and key namespaces even when deployed by the same Worker.

Optional rendezvous contract

• Include rendezvous/NAT assistance only after a threat model shows it is needed; the metaserver never receives gameplay authority, account credentials, character state, or a reusable human-password verifier.
• Define ticket/socket/server/token-generation binding, single-use/expiry, exact message/state/count/byte/time limits, per-ticket routing, replay/downgrade behavior, and privacy/logging requirements.
• A protected server must authorize the exact ticket before either peer's transient candidate is disclosed. Use a vetted end-to-end PAKE or high-entropy invite capability rather than a custom hash challenge visible to the Worker.
• Direct peer-to-peer QUIC necessarily reveals an endpoint to an authorized peer; hiding it from connected players requires a relay and is a separate architecture.

Acceptance criteria

• Canonical discovery and publisher schemas/specifications have shared Go/Rust/Worker positive, negative, maximum-bound, and fuzz fixtures.
• Signature/canonicalization fixtures cover header/body/path/authority mutation, duplicate ambiguity, nonce/sequence replay, skew, wrong identity, and cross-protocol/environment use.
• Spoofed/stale/oversized/replayed registration and untrusted identity changes fail safely before mutation.
• No request-source address, implicit endpoint, secret, token, password/verifier, transient candidate, or private client data is permitted in static discovery.
• A no-hostname server remains discoverable; an explicit hostname is opt-in routing metadata and not identity proof.
• Optional rendezvous has an explicit threat model and shared state-machine/privacy fixtures, or is omitted without weakening direct configured/discovery connections.
• Operational metrics/log labels are bounded and redact authentication, request-source, and candidate data.
• Existing classic consumers remain isolated behind their own versioned schemas/routes during coexistence.
• The metaserver Worker issue links each server/client implementation owner and deployment migration.

Implementation owners

• atrinik/metaserver-worker#13
• atrinik/server#68
• atrinik/client#41

Licensing and scope boundary

Protocol schemas, specifications, fixtures, and generators are MIT. Verified original past work by an approved MIT provenance grantor may be migrated only with the recorded proof. The metaserver has no gameplay/content authority; compiled content artifacts remain owned by content-toolkit.