[RFC] Desktop User System Design

[aworki]

Summary

This RFC proposes a minimal first-step user model for DeerFlow Desktop.

The goal is not to introduce full multi-user management in Desktop right now. The goal is to define the Desktop user-system boundary explicitly before we lock in filesystem, config, workspace, and secret ownership semantics.

The proposed starting point is a single local profile scoped to the current OS user, while keeping the design compatible with future multi-user or multi-profile evolution if DeerFlow decides to go there later.

Why This Needs Discussion Now

PR #2137 started from a narrow Desktop goal: package the Desktop runtime and make its config/workspace routing more isolated and predictable.

But even that minimal implementation starts to define a Desktop user system implicitly:

• what counts as a Desktop user identity
• where workspace files should live
• where uploads and outputs should live
• where runtime config should live
• where secrets and provider settings should live
• what boundary Desktop should assume by default

That boundary should be discussed explicitly instead of being set accidentally by implementation details.

Proposal

Use the following minimal Desktop user model as phase 1:

• Desktop supports one local profile scoped to the current OS user
• Desktop does not introduce in-app account switching in this phase
• Desktop does not try to implement full DeerFlow multi-user management in this phase
• Desktop isolates runtime/config/workspace paths from repo defaults and development defaults
• Desktop keeps DeerFlow virtual user-data semantics where possible (/mnt/user-data/workspace, /mnt/user-data/uploads, /mnt/user-data/outputs), while mapping them to stable local Desktop-owned paths

Suggested boundary:

• workspace: user-visible working files
• uploads: user-provided input files
• outputs: generated artifacts
• runtime config: Desktop runtime-specific config used to launch the local app/runtime
• secrets: provider credentials stored separately from user-visible workspace data

Why Start Here

This keeps the initial Desktop model simple:

• one local profile
• one local workspace boundary
• no in-app multi-user complexity yet

At the same time, it makes the assumptions explicit and gives us a chance to verify that the phase-1 Desktop model does not block future user-system evolution.

Future Multi-User Considerations

This RFC is not proposing full multi-user support now, but it should still answer what constraints the phase-1 Desktop model should avoid.

Questions worth validating now:

• Should the initial Desktop path model leave room for multiple local profiles later?
• Should Desktop treat the current OS user as the only identity boundary for now?
• Which data belongs under Electron userData versus a user-visible workspace root?
• What migration path would be acceptable if DeerFlow later adds multi-profile or broader multi-user support?
• How should Desktop align with DeerFlow broader user-system direction across Desktop and Web?

Goals

• Define the Desktop user-system boundary explicitly
• Keep the initial Desktop model simple
• Make Desktop filesystem behavior predictable for local users
• Isolate Desktop runtime/config/workspace paths from repo defaults
• Leave room for future multi-user or multi-profile evolution

Non-Goals

• Full DeerFlow multi-user management
• In-app login/account switching in Desktop
• Cross-device identity sync
• Finalizing the complete DeerFlow-wide user model in this RFC

Open Questions

1. Is single local profile scoped to the current OS user the right phase-1 Desktop model?
2. Should Desktop workspace data live under a stable user-scoped directory such as ~/.deer/workspace?
3. Which files should remain under Electron userData, and which should move to a user-visible workspace root?
4. What constraints should the phase-1 Desktop model avoid so future multi-user / multi-profile support remains possible?
5. How should this Desktop model relate to DeerFlow broader user-system planning?

Relation to PR #2137

PR #2137 should be treated as an implementation attempt for this minimal Desktop model, not as a proposal for full multi-user support.

Depending on discussion outcome, that PR can then be narrowed, adjusted, split, or paused to match the agreed Desktop user-system direction.

Related PR: #2137

[dhb118]

The ability to configure local MCP also needs to be considered.