Transport spike: evaluate Fluxer delivery separately for TrainerOS Link events and gameplay data #105

Part of #98. Uses #99's deployment/auth findings and #104/#109's session/activity contracts. Investigate the owner's preferred possibility of using Fluxer's own infrastructure, without assuming every interaction requires P2P or a separate Trainer relay.

Two independent questions

1. Native TrainerOS activities (TrainerOS Link: define adapter-driven system activities independently of in-game multiplayer #109/TrainerOS Link online: bring existing Emerald exchanges to remote friends without launching the game #110): can authorized clients exchange bounded semantic offers, approvals, transaction receipts and other adapter-defined events through Fluxer itself? The original game/emulator is not running.
2. In-game multiplayer (In-game multiplayer: prove one exact online game/runtime adapter, separate from TrainerOS Link #107): can a Fluxer-provisioned data route satisfy the actual packet rate, latency, loss and ordering needs of a supported game's/runtime's networking?

A route may be suitable for the first and unsuitable for the second. Return separate decisions, not one universal network supported verdict. OS-hosted interactive activities also need their own measured event profile; do not assume every native activity is infrequent or read-only.

Candidate matrix

Choose the smallest suitable path per consumer. A native exchange is not required to wait for low-latency UDP, virtual LAN or a complete generic P2P stack.

Message-envelope route: research, not an assumed backend feature

The official Messages reference documents text/attachment creation, history and realtime message events. This supplies a research lead for carrying a bounded application envelope inside supported content, not permission to invent hidden fields, custom Gateway commands or a private app-data channel.

Verify permitted service use, actual user-client permissions, payload/rate limits, notification/read-state effects and normal Fluxer-client behavior. No visible protocol flood; if the needed exchanges cannot fit a usable legitimate representation, reject this path. Notification suppression is not message invisibility. Avoid pointless status updates or attachment churn.

Use immutable activity/operation IDs and versioned bounded semantic payloads, authenticated against the actual author, intended participants and chosen device/session. Put application identifiers inside the verifiable payload, not only in transient transport metadata. A displayed card or chat reaction does not authorize a save mutation.

Prove behavior with edits/deletions, incomplete history, replay, duplicate delivery, delayed receipt, account reconnect, multiple devices and lost permissions. Preserve validated content digests/receipts locally; chat history is not the transaction journal or authoritative game state.

The current message reference documents a five-minute send-nonce deduplication window, after which a retry can create another message. Native operation idempotency and settlement recovery must outlive that window. Reverify this deployed behavior during implementation; do not equate an HTTP success or provider nonce with exactly-once save settlement.

Define confidentiality, retention and address exposure. Normal DMs are not automatically end-to-end encrypted. Private semantic object/transaction data requires the selected reviewed confidentiality/authentication design, or this route remains unavailable for that data. Do not expose complete saves, account tokens or signing secrets. No homemade cryptography.

Offline delivery of an invitation is not offline trading. Historical offers may be displayed as expired/pending, but must never silently execute a transaction when a device later logs in. Keep both-side consent, current-source verification and explicit recovery.

Media-data route

Check the Fluxer voice reference and LiveKit data packet documentation as implementation leads. A library's data capability does not prove the actual Fluxer grants, server configuration, service permission or a stable app-data contract.

On a permitted test deployment, verify native participant-addressed data, audience isolation, identity/session binding, grant expiry and reconnect. Determine whether data-only operation can avoid microphone capture, ringing unrelated group members or misleading call state. Preserve #103's private-call audience constraints.

Record the actual deployed server/SDK/protocol revision. Do not depend on an announced future media stack. The media-proxy upload relay is not an arbitrary UDP forwarding service.

Safety, measurements and operations

For native transactions, prioritize correctness under loss, duplicate/reordered events, durable recovery and bounded message volume. For interactive native activities and runtime gameplay, additionally measure their actual latency/jitter, packet size/MTU, queues, CPU/RAM and bandwidth. A one-packet demo is not proof of either safe exchange or playable multiplayer.

A timeout cannot establish that the other device did not commit. Application journals, receipts and recovery from #109/#110 remain necessary under every route. Do not promise non-blocking bilateral atomicity during a partition.

Use consenting accounts and conservative permitted tests. Sustained load belongs on controlled infrastructure or needs operator authorization; review current terms. Record operator, authentication, quotas, allocation lifetime, bandwidth/cost and abuse controls for any operated relay. Do not presume public capacity is unlimited.

A server-carried route is a relay, not direct P2P. State who can observe payloads/metadata and what extra privacy properties are actually proven.

Deliverables and acceptance

• A sanitized harness and ADR distinguish documented library primitives, reproduced deployment behavior and permitted use.
• Native system-event delivery and runtime gameplay receive separate supported/conditional/rejected decisions.
• The bounded message-envelope candidate is actually evaluated rather than rejected solely by a realtime-gameplay argument.
• A two-client native-event proof or a precise blocker is recorded, including ordinary-client UX and durable-replay tests.
• Media-data/no-microphone behavior and audience isolation are settled where that path is considered.
• Relevant resource, delivery and latency measurements support each recommendation.
• Transaction delivery is never represented as successful save settlement.
• TrainerOS Link online: bring existing Emerald exchanges to remote friends without launching the game #110 may proceed using a proven native-event route even while In-game multiplayer: prove one exact online game/runtime adapter, separate from TrainerOS Link #107 or generic P2P remains unfinished.
• Versions, limitations, fallback/removal plan and operational responsibilities are documented.

This research does not authorize building a full Fluxer fork or production relay, and does not block the basic messenger.