Owner reconciliation, 8 October 2026: known official releases/regions/revisions form the guest prohibition catalogue. Do not catalogue ROM hacks/transformed images, classify all unknown files, or require per-file verified licence evidence for user-supplied content. Users undertake responsibility for rights to their files/transmissions under the proposed agreement; unknown is not automatic prohibition or legal clearance. Valid signed policy, consent, technical compatibility, integrity, session isolation and cleanup remain mandatory. Operator-curated OddCrate packages still require rights review. Policies arrive through ordinary TrainerOS Software S updates, not Linux image/host updates. See product vision. These are target decisions, not implemented transfer behaviour or effective legal terms.
Guest content clarification (see #136–#141): The earlier absolute statement that runtime multiplayer never transfers ROMs is superseded only for technically supported exact content with no applicable prohibition under a valid signed TrainerOS Software policy (#136–#143), with user responsibility for rights. Eligible content, including redistributable homebrew on modern platforms, may be temporarily supplied to an invited player after consent, inside an isolated, revocable game session; it is not a permanent ROM download or a public content service. Games with blocked guest transfer or unavailable technical/policy prerequisites still require the player's own compatible content. There is no manual per-homebrew Approved-list requirement. No video streaming is added. Existing exact-runtime, party, save and launch guarantees still apply.
DS Local Wireless workstream (#162–#166): Build a TrainerOS-owned native Linux melonDS deterministic mirrored-console adapter using only GPL-compatible reusable WatermelonDS/DetMP material with upstream attribution; rewrite Android-specific and unsafe snapshot exchange behavior. Ordinary virtual LAN does not provide DS internet local wireless. The same exact-game GameParty/invitation/save/transport protections in this issue apply. No WFC conflation, ROM redistribution side channel, unapproved BIOS/firmware transfer, video streaming, or default promotion of an untested mode. DS multiplayer is not delivered yet; enable only after the real paired-device gates in #166.
Part of #98. Depends on #104 and the selected/proven transport path from #106. Discovery and adapter design can start earlier using #89's audit rules.
Goal
Deliver the first complete invite → compatible setup → launch → actual multiplayer → clean return flow for one exact game/runtime combination across two different internet connections.
A successful socket connection, shared virtual subnet or TrainerOS battle demonstration is not proof that an arbitrary emulator game supports online play.
Keep three mechanisms distinct
| Mechanism |
What must already exist or be implemented |
| Runtime/emulator netplay |
Real supported synchronization/input/state behavior in that runtime |
| A game's actual LAN mode |
A network-capable game plus the specific discovery/routing behavior it needs |
| TrainerOS semantic Link activity |
Existing native battle/trade/activity protocol and its own safety contracts |
Local multiplayer, emulated link-cable/wireless play, deterministic netplay and LAN play are not interchangeable. Do not add a Play Together button merely because a game belongs to a supported platform.
Select one first vertical
Audit the currently configured runtimes and official upstream documentation. Pick one exact title/build and runtime/version with a viable supported multiplayer mode on the target devices. Record why it is the smallest useful proof, needed content/settings/BIOS compatibility and any known limitations.
Prefer using a runtime's working netplay machinery over reimplementing emulation synchronization. Reuse the selected #106 transport only where the runtime integration actually requires it; avoid gratuitous tunnel-inside-tunnel stacks.
Normally each player uses their own valid local content. A specifically eligible game may instead use the temporary, consented guest session content under the signed policy and user-responsibility contract defined by #136–#143. This issue does not implement arbitrary ROM distribution, BIOS/firmware sharing or transfers prohibited by the policy or user agreement.
Adapter contract
Extend the existing Adventure/runtime capability boundary rather than creating a second universal adapter framework. Keep launch/network orchestration in TrainerOS host services; portable semantic game knowledge must not gain Fluxer, socket, process or UI dependencies.
An adapter should be able to describe effective multiplayer mode, compatible build/runtime/options, player count/roles, preparation requirements, host/join actions, health/failure events and cleanup. Exact names and shapes should follow the actual code audit.
Revalidate installation, local Trainer, negotiated descriptor and capabilities immediately before launching. Remote data may select an allowlisted local capability, never supply a shell command, filesystem path or arbitrary command-line argument.
Compatibility should be checked automatically where possible, with a short useful failure reason instead of a large technical setup screen.
Save and lifecycle safety
Preserve #49's ordinary-save launch/return model. A runtime's transient synchronization/rollback state is a separate concern from TrainerOS persisting savestates as ResumePoints; do not silently reintroduce the latter.
Define host/guest save authority before enabling the adapter. Document what progress persists, where session-only state lives and how a guest avoids overwriting their own playthrough. Protocol-required state synchronization is not permission to import a peer's persistent save into the local profile.
Use existing backup/revision/protected-write policy for any intentional persistent mutation. Preserve #75's effective read-only integration policy and #76 ownership. Restore only this session's temporary configuration changes, including after a crash; never overwrite a newer user configuration blindly.
Starting a session must not silently kill a current Adventure. Returning to chat must not pause an online game or discard protected state. Record graceful departure, peer crash, desynchronization and reconnect behavior honestly.
Existing semantic Link
Reuse shared session/transport boundaries where appropriate and regression-test current local Link behavior. Enabling internet trades/sales/gifts is a separately gated capability: keep #42/#45 durable two-endpoint transaction and recovery guarantees; never call a one-sided commit success.
Do not hold the first emulator-game vertical hostage to implementing every internet Link activity. Equally, do not count native TrainerOS activities as proof of emulator multiplayer.
Virtual LAN is conditional, not the foundation
Only add a LAN tunnel when a chosen real game needs it. First determine whether routed L3 unicast is sufficient or whether discovery needs bounded broadcast/multicast/L2 support; a TUN subnet does not automatically reproduce an Ethernet LAN.
Any helper must expose narrow session operations, limit peers/routes/ports, avoid bridging the whole home network, preserve default routes/DNS and remove only its own resources. Avoid overlapping-address assumptions and stale interfaces after a crash. Split substantial LAN implementation into a follow-up once the real requirement is established.
Acceptance
Related: #42, #45, #49, #74, #75, #76, #89. Document the wire/capability contract for potential ELIGEN interoperability; do not make ELIGEN a mandatory dependency or share privileged host implementation by accident.
Goal
Deliver the first complete invite → compatible setup → launch → actual multiplayer → clean return flow for one exact game/runtime combination across two different internet connections.
A successful socket connection, shared virtual subnet or TrainerOS battle demonstration is not proof that an arbitrary emulator game supports online play.
Keep three mechanisms distinct
Local multiplayer, emulated link-cable/wireless play, deterministic netplay and LAN play are not interchangeable. Do not add a Play Together button merely because a game belongs to a supported platform.
Select one first vertical
Audit the currently configured runtimes and official upstream documentation. Pick one exact title/build and runtime/version with a viable supported multiplayer mode on the target devices. Record why it is the smallest useful proof, needed content/settings/BIOS compatibility and any known limitations.
Prefer using a runtime's working netplay machinery over reimplementing emulation synchronization. Reuse the selected #106 transport only where the runtime integration actually requires it; avoid gratuitous tunnel-inside-tunnel stacks.
Normally each player uses their own valid local content. A specifically eligible game may instead use the temporary, consented guest session content under the signed policy and user-responsibility contract defined by #136–#143. This issue does not implement arbitrary ROM distribution, BIOS/firmware sharing or transfers prohibited by the policy or user agreement.
Adapter contract
Extend the existing Adventure/runtime capability boundary rather than creating a second universal adapter framework. Keep launch/network orchestration in TrainerOS host services; portable semantic game knowledge must not gain Fluxer, socket, process or UI dependencies.
An adapter should be able to describe effective multiplayer mode, compatible build/runtime/options, player count/roles, preparation requirements, host/join actions, health/failure events and cleanup. Exact names and shapes should follow the actual code audit.
Revalidate installation, local Trainer, negotiated descriptor and capabilities immediately before launching. Remote data may select an allowlisted local capability, never supply a shell command, filesystem path or arbitrary command-line argument.
Compatibility should be checked automatically where possible, with a short useful failure reason instead of a large technical setup screen.
Save and lifecycle safety
Preserve #49's ordinary-save launch/return model. A runtime's transient synchronization/rollback state is a separate concern from TrainerOS persisting savestates as ResumePoints; do not silently reintroduce the latter.
Define host/guest save authority before enabling the adapter. Document what progress persists, where session-only state lives and how a guest avoids overwriting their own playthrough. Protocol-required state synchronization is not permission to import a peer's persistent save into the local profile.
Use existing backup/revision/protected-write policy for any intentional persistent mutation. Preserve #75's effective read-only integration policy and #76 ownership. Restore only this session's temporary configuration changes, including after a crash; never overwrite a newer user configuration blindly.
Starting a session must not silently kill a current Adventure. Returning to chat must not pause an online game or discard protected state. Record graceful departure, peer crash, desynchronization and reconnect behavior honestly.
Existing semantic Link
Reuse shared session/transport boundaries where appropriate and regression-test current local Link behavior. Enabling internet trades/sales/gifts is a separately gated capability: keep #42/#45 durable two-endpoint transaction and recovery guarantees; never call a one-sided commit success.
Do not hold the first emulator-game vertical hostage to implementing every internet Link activity. Equally, do not count native TrainerOS activities as proof of emulator multiplayer.
Virtual LAN is conditional, not the foundation
Only add a LAN tunnel when a chosen real game needs it. First determine whether routed L3 unicast is sufficient or whether discovery needs bounded broadcast/multicast/L2 support; a TUN subnet does not automatically reproduce an Ethernet LAN.
Any helper must expose narrow session operations, limit peers/routes/ports, avoid bridging the whole home network, preserve default routes/DNS and remove only its own resources. Avoid overlapping-address assumptions and stale interfaces after a crash. Split substantial LAN implementation into a follow-up once the real requirement is established.
Acceptance
Related: #42, #45, #49, #74, #75, #76, #89. Document the wire/capability contract for potential ELIGEN interoperability; do not make ELIGEN a mandatory dependency or share privileged host implementation by accident.