Core direction — temporary capability access and collaboration fabric

Status

CANONICAL NORTH STAR — KEEP OPEN.

Current public execution is intentionally narrow:

#51  canonical product/core boundary
#375 one-time Room App control-plane decoupling seam

Room App portfolio selection, acquisition/SEO strategy, donor research, registration, promotion and retirement belong in i365dev/free4chat-extension-lab (canonical control-plane migration: free4chat-extension-lab#73).

Older compatibility, interoperability, media and polish ideas are closed when merely evidence-gated. Reopen only when real usage creates the corresponding gap. The public open-issue list should represent current core work, not serve as a permanent idea archive.

North star

Free4Chat provides the temporary boundary. Participants bring the capabilities.

Free4Chat is a low-cost, temporary collaboration Room where Humans and Agents can meet, bring independently owned capabilities, and use lightweight shared surfaces without joining a permanent workspace.

The Room is the core primitive:

Room
├─ Human participants
├─ Agent participants
├─ ephemeral shared context
├─ text / voice / files / screen
├─ Task / Live View
└─ bounded external shared surfaces (Room Apps)

These are activity/collaboration surfaces above one temporary boundary, not separate product architectures.

Room Apps are relevant to the core only as a hosted/sandboxed surface contract. Which Apps exist, how they acquire users, what SEO pages they have, and when they are retired are not core product responsibilities.

Room-first product model — ownership inversion

Free4Chat is Room-first, not App-first or Game-first.

Most game/activity products are shaped roughly like:

Game / App
└─ Lobby / Room
   ├─ Player A
   ├─ Player B
   ├─ chat / voice
   └─ multiplayer/session state

The game or activity is the product. The room exists to support it.

Free4Chat inverts that ownership:

Room
├─ Humans
├─ Agents
├─ conversation / voice / files / screen
├─ ephemeral shared context
└─ Activities / Room Apps
   ├─ content / information
   ├─ utility
   ├─ solo or parallel activity
   ├─ shared activity
   └─ realtime shared state

The Room is the continuity boundary. Apps are replaceable activity surfaces inside it.

This distinction matters:

• a Room can exist before an App opens and continue after it closes;
• several Apps may be used sequentially without creating a new social context;
• an App does not need to own identity, presence, invite, text chat or generic voice just because standalone products normally do;
• App state may be client-owned, App-owned, or realtime shared depending on the activity;
• an App may be short-lived, experimental or retired without invalidating the Room product;
• the same people can move from content consumption to conversation to a game to a whiteboard while the Room remains the same temporary social context.

A Room App therefore does not need to be realtime collaboration or multiplayer to be a valid Free4Chat use case.

Valid activity shapes include:

SHARED CONTEXT
→ people consume / discuss the same information or content

PARALLEL ACTIVITY
→ people independently do the same thing while present together
→ e.g. each person plays the same solo game

SHARED ACTIVITY
→ people loosely participate / compare / vote / take turns / react together

SHARED STATE
→ realtime collaborative or multiplayer state

Examples:

• several people enter a Room around the same event/information page and chat or gossip;
• several people each play the same solo game and compare runs while talking;
• people use a poll, timer or tier list together;
• people play a realtime co-op/PvP game;
• people work on a shared whiteboard or pad.

The App supplies something worth gathering around. Free4Chat supplies the temporary place and relationship boundary around that activity.

This is also why Room Apps should not be judged only by “collaboration fit.” A surface can be valuable through acquisition, intrinsic usefulness/fun, session depth, repeat use, sharing, conversation or direct collaboration. Realtime Room leverage is a multiplier, not an eligibility gate.

Canonical App portfolio/activity policy lives in i365dev/free4chat-extension-lab#31; portfolio research lives in free4chat-extension-lab#19.

Stable product constraints

Protect these as experiments change:

• anonymous-first — core collaboration does not require registration;
• zero-workspace — no team/project workspace is required before collaboration starts;
• participant-owned capability — models, tools, credentials, private memory and durable state stay with the participant/Harness unless explicitly shared;
• ephemeral by default — durable output leaves only through explicit artifacts or externally owned workflows;
• thin core — Room membership, addressing, bounded shared context, artifacts/media, sandbox/transport and grants belong in Free4Chat; domain logic does not;
• low friction — optimize time-to-collaboration rather than feature count;
• low surprise cost — client/external-surface-owned compute and bounded transport are preferred; high-frequency application data must not become Room DO/history traffic;
• enterprise completeness is not the goal — do not add permanent workspace/governance semantics for parity.

Useful invariants:

capability advertisement != authorization
request != remote function invocation
visibility != activation
event != trigger
Action != Cognition
join != work authorization
Room id != owner/admin credential

Competitive differentiation — not the north star

Free4Chat overlaps several dimensions at once:

temporary / no-workspace collaboration
+ realtime Human presence
+ independent Agent participants
+ participant-owned tools/models/credentials
+ lightweight external shared surfaces
+ low-cost ephemeral operation
+ open-source core

The product does not need feature-by-feature competitor parity.

The open-source core is a competitive, trust and distribution differentiator, not the reason Free4Chat exists and not a reason by itself to add features. Open source should reinforce trust, adoption and inspectability around the temporary-Room boundary.

Current proven boundaries

Agent / Task / Live View

The native Go Runtime, ACP Harness boundary, Task collaboration, bounded Live View, voice/transcript/media path and Room-scoped approval model are production/dogfood proven enough for the current phase.

Free4Chat does not own the Agent's intelligence, tools, credentials or private memory.

Agent work should be primarily workflow-pulled:

real Room workflow
→ current Agent participant cannot complete it cleanly
→ one narrow missing primitive is proven
→ add that primitive

Do not expand the Agent surface merely because a new AI protocol/capability is fashionable or technically possible.

Room App host boundary

The Room App v1 host seam is established. After the control-plane migration, the intended split is:

Free4Chat core
├─ sandboxed iframe lifecycle
├─ fixed trusted production origin policy
├─ participant projection
├─ bounded reliable/realtime transport
├─ bounded authenticated reliable unicast
├─ protocol / payload / rate guardrails
├─ generic App launch seam
├─ validated consumption of Lab-owned curated metadata
└─ coarse host-owned lifecycle analytics

Extension Lab / App
├─ which curated Apps exist
├─ registry / runtime path / lifecycle
├─ rendering / domain rules
├─ state / convergence / CRDT if needed
├─ optional App-owned persistence/backend
├─ discovery / SEO / sitemap
└─ retirement redirect / 410 policy

The core must not remotely accept arbitrary iframe origins or become a generic marketplace/plugin host. The trusted origin, sandbox and transport/security policy remain core-owned.

Do not respond to new App ideas by extending the core contract first. A concrete App must prove a missing host primitive before core work is earned.

Current execution gate

#375 owns only the one-time transition required to establish the thin host seam described above. When free4chat-extension-lab#73 is deployed and verified, #375 should close.

Normal App add/remove/promote/SEO/retire work should then happen outside this repository without a matching core issue or PR.

Context ownership

Keep three classes separate:

private participant context
→ Harness reasoning/history, credentials, unshared files/tool state

Room-shared ephemeral context
→ messages/events, requests/results, transcript, Task interaction, bounded App transport

explicit artifacts / externally owned durable state
→ intentionally published output or domain-specific persistence

Do not add a central Memory/ContextStore/vector DB or generic Room App state database merely to make temporary collaboration durable.

Product / economic filter

For any new core feature ask:

1. Does it strengthen the temporary Room, participant capability, or safe shared-surface boundary?
2. Is there a demonstrated workflow gap rather than roadmap completeness?
3. Does it reduce time-to-collaboration or unlock a clearly useful temporary capability?
4. Can domain/state remain participant/App-owned?
5. Does the Room remain temporary and thin?
6. Is ordinary action deterministic/client-side where possible rather than model-funded?
7. Does it avoid high-frequency DO/history/storage traffic?
8. If usage grows 100×, is the cost shape still welcome?
9. Can the change be removed or kept narrow if the hypothesis fails?

Doing nothing is valid when existing primitives already solve the problem.

A useful rejection test is:

Is this strengthening the temporary Room boundary, or quietly moving an external product into core?

What Free4Chat should not become by default

• central planner / workflow DAG / scheduler;
• hosted Agent platform;
• credential vault;
• central/global Agent memory;
• permanent project/workspace/meeting archive;
• remote shell/control-plane or remote desktop product;
• global Agent/device registry;
• Agent marketplace/social graph;
• generic plugin/App marketplace;
• standalone game portal or utility/SEO portfolio repo;
• App catalog/content/retirement control plane;
• matchmaking/progression platform;
• Slack/Jira/Notion/Zoom replacement.

Keep this issue open as the product/core boundary. Close or reopen concrete core follow-ups independently as evidence changes.

No implementation files or tests are named. Start by reading this boundary issue together with #375 and the referenced Extension Lab issues, then inspect the current Room, Agent, Task, Live View, and Room App host entry points. Done would require a concrete, evidence-backed core follow-up rather than another product idea, while preserving the stated thin Room boundary.