Part of #98. This is the first integration gate, not authorization to build the whole messenger at once.
Goal
Produce a small reproducible proof and decision record showing how a native TrainerOS client can legitimately access the required Fluxer features. Separate verified deployment behavior from documentation, assumptions and roadmap work.
Questions to settle
User authentication, not a bot workaround
Verify a supported third-party user-client login/session flow, including MFA/challenges, expiration, revocation and logout. Prefer a provider-supported browser/device handoff where it actually grants the needed access; otherwise document the supported native user-session flow and its security requirements.
Fluxer's authentication reference distinguishes user sessions, bots and scoped OAuth access. An OAuth identity login is not automatically authorization to read/send the user's private conversations. Check OAuth2 and the authentication-resource reference before selecting a flow.
Do not require users to scrape tokens from another client, paste a bot token, disable MFA or embed a confidential OAuth client secret in a distributed native application. If no acceptable flow is available, record that blocker rather than implementing token extraction.
Capability matrix
Record endpoints/events, permission requirements, deployment flags and evidence for:
- friends and pending requests; block/unblock;
- private channels and group membership;
- paginated text history and realtime create/edit/delete;
- unread/read-state behavior and presence;
- images/attachment upload and download;
- native recorded voice messages;
- DM/group voice join/leave and mute;
- small, user-authorized game invitation/signalling payloads.
Give every row a state such as documented, reproduced, unavailable, conditional or not investigated. Do not interpret a missing feature as an empty successful result.
Native feasibility
Use the current C++20/Qt6 stack. A throwaway test harness is acceptable; it must not make Chromium, a Node server or a full third-party web UI a product dependency.
Verify build/runtime viability on Linux ARM64, with a practical development-test route on x86-64/Windows where needed. Evaluate existing native components before writing protocol machinery.
The current voice reference describes LiveKit transport, while the September 2026 roadmap describes a replacement in development. Record the tested deployment, protocol and dependency revisions. Do not program against a hypothetical future Rust/QUIC API.
Service and licensing boundary
Review current official service terms and third-party-client guidance for the intended use. Review the exact upstream licenses of any reused source/SDK and how they fit TrainerOS's distribution decision. Distinguish implementing a documented network client from copying/linking upstream application code; do not select TrainerOS's license implicitly.
The public service is the preferred candidate, not a guaranteed unrestricted backend. A separate hosted instance is a possible documented alternative, not a silent account migration. Keep instance identity explicit; do not assume cross-instance federation.
Proof and deliverables
With consenting test accounts and conservative request rates, reproduce the smallest user-session → friend/DM → send/receive → reconnect loop. Probe the required media/voice paths only enough to identify their contracts and native blockers.
Commit a concise integration note, a sanitized capability matrix and reproducible tests/fixtures or harness instructions. Record source URLs, retrieval date, tested versions and unresolved decisions. No credentials, personal messages or media enter Git.
The separate game-data spike #105 owns whether Fluxer's media infrastructure can carry gameplay packets; a successful chat or voice connection does not answer that question. Its work may proceed alongside UI fixtures, while #100 consumes the verified account/API contract.
Acceptance
Sources
Official API · Private channels · Messages · Calls · Terms · Upstream source
Part of #98. This is the first integration gate, not authorization to build the whole messenger at once.
Goal
Produce a small reproducible proof and decision record showing how a native TrainerOS client can legitimately access the required Fluxer features. Separate verified deployment behavior from documentation, assumptions and roadmap work.
Questions to settle
User authentication, not a bot workaround
Verify a supported third-party user-client login/session flow, including MFA/challenges, expiration, revocation and logout. Prefer a provider-supported browser/device handoff where it actually grants the needed access; otherwise document the supported native user-session flow and its security requirements.
Fluxer's authentication reference distinguishes user sessions, bots and scoped OAuth access. An OAuth identity login is not automatically authorization to read/send the user's private conversations. Check OAuth2 and the authentication-resource reference before selecting a flow.
Do not require users to scrape tokens from another client, paste a bot token, disable MFA or embed a confidential OAuth client secret in a distributed native application. If no acceptable flow is available, record that blocker rather than implementing token extraction.
Capability matrix
Record endpoints/events, permission requirements, deployment flags and evidence for:
Give every row a state such as documented, reproduced, unavailable, conditional or not investigated. Do not interpret a missing feature as an empty successful result.
Native feasibility
Use the current C++20/Qt6 stack. A throwaway test harness is acceptable; it must not make Chromium, a Node server or a full third-party web UI a product dependency.
Verify build/runtime viability on Linux ARM64, with a practical development-test route on x86-64/Windows where needed. Evaluate existing native components before writing protocol machinery.
The current voice reference describes LiveKit transport, while the September 2026 roadmap describes a replacement in development. Record the tested deployment, protocol and dependency revisions. Do not program against a hypothetical future Rust/QUIC API.
Service and licensing boundary
Review current official service terms and third-party-client guidance for the intended use. Review the exact upstream licenses of any reused source/SDK and how they fit TrainerOS's distribution decision. Distinguish implementing a documented network client from copying/linking upstream application code; do not select TrainerOS's license implicitly.
The public service is the preferred candidate, not a guaranteed unrestricted backend. A separate hosted instance is a possible documented alternative, not a silent account migration. Keep instance identity explicit; do not assume cross-instance federation.
Proof and deliverables
With consenting test accounts and conservative request rates, reproduce the smallest user-session → friend/DM → send/receive → reconnect loop. Probe the required media/voice paths only enough to identify their contracts and native blockers.
Commit a concise integration note, a sanitized capability matrix and reproducible tests/fixtures or harness instructions. Record source URLs, retrieval date, tested versions and unresolved decisions. No credentials, personal messages or media enter Git.
The separate game-data spike #105 owns whether Fluxer's media infrastructure can carry gameplay packets; a successful chat or voice connection does not answer that question. Its work may proceed alongside UI fixtures, while #100 consumes the verified account/API contract.
Acceptance
Sources
Official API · Private channels · Messages · Calls · Terms · Upstream source