Spec: Unified Computer and Cloud conversations

Date: 2026-10-18. Status: product direction and testing boundaries confirmed; specification only. Implementation, deployment and merge are not started or authorized by publishing this specification. Runtime verification is restricted to UAT; Prod is outside scope.

Problem Statement

DeepSeekBot users converse with Bots and Humans across a local Computer, explicitly paired remote Computers, and independently hosted TOB cloud services. A single active-Host view plus separate cloud pages makes users switch environments before finding a conversation, obscures which identity sends a message, and makes cross-device Bot collaboration difficult to understand.

Mobile, browser Web and DSH Desktop need one coherent conversation experience without moving ownership of messages, credentials or Bot execution into the viewing client. A cloud connection on one client must not silently connect every other client.

Solution

Show all authorized conversations from sources explicitly connected on this client in a unified Channel list. Include Bot DMs and group Channels, with optional Computer and cloud Organization filters. Opening a conversation routes its reads, writes and related actions to its owning source and identity without changing unrelated application context.

Place only a small Computer or cloud icon after the Channel name in the list and message header. Show precise source, cloud Organization and identity information in Channel details. Preserve pins first, then recent-message ordering. Offline sources retain cached conversations and drafts, with explicit offline state and no automatic send on reconnect.

Mobile is an access/control client. Computer conversation data stays on its Host; cloud Channel messages stay in the owning cloud service. A cloud message can be accepted while a participating Bot's Computer is offline. When the Host reconnects, it synchronizes authorized messages and applies its own reception rules, Bot Inbox and Wake Policy. Only the Bot owner can change that Bot's policy in this scope.

User Stories

1. As a mobile user, I want one list of connected Computer and Cloud conversations, so that I can find a conversation without first changing environments.
2. As a browser Web user, I want conversations from the serving Host, paired Hosts and signed-in cloud services together, so that I can work across sources.
3. As a DSH Desktop user, I want the same conversation model with my own client connections, so that desktop is a supported surface rather than an assumed browser equivalent.
4. As a user, I want both Bot DMs and group Channels in this list, so that private and group work remain accessible.
5. As a user, I want to explicitly pair a remote Computer, so that network reachability alone never grants access.
6. As a user, I want to connect a cloud service and sign into that instance, so that self-hosted and official services use the same navigation model.
7. As a returning cloud user, I want my existing authorized Organizations and Channels discovered after login, so that I do not repeat accepted invitations.
8. As a user, I want each phone, browser context and Desktop client to keep its own connections, so that adding a service on one device does not add it elsewhere.
9. As a user, I want Computer and cloud Organization filters, so that I can narrow the list without changing my access or message identity.
10. As a channel-only guest, I want the containing Organization to appear as a navigation context while exposing only my granted Channels, so that I can participate without gaining broader Organization access.
11. As a user, I want a trailing source-type icon on Channel names, so that I can distinguish Computer and Cloud conversations without crowded labels.
12. As a user, I want exact source and account details in Channel details, so that identically named Channels remain distinguishable.
13. As a user, I want the composer to send as the identity of the selected source, so that a Host's configured Human and a cloud account cannot be confused.
14. As a user, I want opening a remote conversation to leave unrelated local management context unchanged, so that I do not accidentally manage another Host.
15. As a user, I want one direct entry for the same cloud Channel under the same account, so that multiple access paths do not duplicate it.
16. As a user, I want independently owned local groups that mirror cloud messages to remain distinct, so that the UI does not merge separate histories or permissions.
17. As a user, I want disconnected sources to retain cached rows and history with an offline indication, so that an outage does not make my conversations disappear.
18. As a user, I want an offline draft to remain scoped to its original conversation and identity, so that reconnect never sends it to the wrong place or sends it unexpectedly.
19. As a user, I want to send to a cloud Channel while a Bot's Computer is offline, so that discussion can continue until the Bot reconnects.
20. As a user, I want sending to a Computer Channel to require a reachable authorized Host, so that the UI reports the actual delivery condition.
21. As a user, I want pins first and other conversations ordered by recent messages, so that the mixed list follows the existing navigation convention.
22. As a user, I want read progress synchronized for the same source identity, so that reading on one connected client updates my other connected clients.
23. As a user, I want pins saved by their owning source, so that the unified list does not introduce a conflicting second preference store.
24. As a Bot owner, I want my Bot to join another person's authorized cloud Channel, so that collaboration is not confined to my own service or Organization.
25. As a Bot owner, I want per-Bot/per-Channel reception and Wake Policy enforced on the executing Host, so that cloud chat reuses local Bot behavior.
26. As a Bot owner, I want policies and available local work to remain usable during cloud outages, so that loss of cloud connectivity does not disable local operation.
27. As a Bot owner, I want reconnect to recover messages without repeating completed work, so that transport retries do not duplicate side effects.
28. As a Bot owner, I want expired or state-invalid execution requests to require confirmation, so that reconnect does not authorize stale work.
29. As a Bot owner, I want my phone's read position to be independent of my Bot's delivery progress, so that reading a conversation never prevents the Bot from receiving it.
30. As a Bot owner, I want cloud membership and administration to remain separate from editing my Bot's Wake Policy, so that only I control its local attention settings.
31. As a developer, I want the same business operations available through CLI and public interfaces, so that automated verification does not depend on a model or private UI shortcuts.

Implementation Decisions

Authorities and identities

These are application-defined BotHarness/TOB concepts, not new DSH-native primitives.

Cloud Organization means the service's workspace boundary. The UI label Computer means a connected Host here; it must not silently redefine the existing glossary's Bot desktop environment. Cloud service, Organization and local workspace directory are separate concepts.

A source's display name or URL alone is not proof of identity. Preserve verified Host/service identity and authenticated account context. A cloud Agent credential does not grant its owner's client a Human login. Different services do not share a global Human identity.

Client source lifecycle and routing

Introduce one application-defined client conversation-source abstraction with Computer and Cloud adapters. It owns source-specific connection lifecycle, authorized summaries, history and operation routing; it is not a new server or canonical message database. Reuse existing authenticated Host and TOB interfaces.

Source identity must namespace conversation routes, cached summaries/history, drafts, pending requests and refresh state. Include the source, applicable principal/account, and conversation identity; a bare Bot slug or Channel ID is insufficient. Include Organization scope where required by the cloud contract. Switching filters must not reuse the last selected source's credentials or Organization token for another target.

Maintain independent source state so one failed or expired connection does not disconnect unrelated sources. Filter selection changes presentation, not authority. Reconnect refreshes source state using its own credentials. Logout, account change and explicit removal must prevent the next principal from seeing or sending the prior principal's cached content/drafts; offline retention applies to a still-enrolled source, not as a bypass after removal or known revocation.

Prefer existing Typert/API Gateway capability seams for Host operations and public TOB API contracts for cloud operations. The API Gateway remains the sole owner of the Host /api interceptor. Browser transport must be verified separately from native custom-header WebSocket capabilities. No new cloud proxy for all local Host traffic is implied.

Client lifecycle owners dispose subscriptions and pending requests for removed sources. Rebuild list projections from source-owned facts; transient notifications are not durable authority. Do not create DSH SessionEvents merely to persist aggregate UI preferences.

Client persistence boundaries

• Mobile: app installation, using its existing appropriate credential storage.
• Browser Web: browser profile plus application origin. Do not persist cloud secrets in shared Host settings to simulate browser persistence.
• DSH Desktop: app-owned connection/session storage, separate from browser Web and mobile; qualify its concrete secure-storage and redirect behavior before delivery.
• Existing Host Bot cloud bindings remain independent of these Human client connections.

Navigation and visual language

Default to all connected authorized conversations, with a remembered client-local filter. Keep Computers and Cloud as separate connection-management categories; their add flows must remain contextual rather than mixing computer pairing and cloud joining.

Reuse existing named connection entries and invitation/QR paths. A cloud channel-only grant may contribute an Organization filter entry without admitting the Human to other Channels. Never request an extra grant solely to populate the list.

Channel rows and message headers use a trailing Computer/cloud icon only; accessible labels describe it. The row's secondary content is a message preview, not another source label. Details show the source, Organization where applicable, and effective identity. The icon denotes ownership type; offline status is separate. Same-named Channels are not merged or renamed.

Sort pins before other conversations, then by committed recent-message activity, with deterministic ties. Fetch summaries from the owning source rather than downloading all message histories. Preserve source-owned roster arrangement; aggregate filtering/sorting must not rewrite it. Cross-source total chronological ordering is not a new server guarantee.

Read and pin synchronization

Preserve Host-owned read/roster semantics. Add cloud-account read progress and pin operations to TOB through its public authenticated interface, including the summary data needed for unread and recent-message presentation. Exact physical tables and endpoint names belong to implementation design; do not reuse a history-access floor as a read cursor.

Read advancement must be monotonic, authorized and scoped to the account/Channel. Cloud pin changes are account preferences, not organization-wide administration. Human read progress and Bot delivery/admission progress are distinct. Sync applies only to clients already connected to the same source and identity; it never enrolls another device.

Host-local cloud reception and wake

The target path is cloud message → authorized, deduplicated local Source Event → local reception/admission rules → Bot Inbox → local Wake Policy → execution → permitted reply to the original Channel. These are existing application-defined domain boundaries; reuse their owning Host module instead of adding a cloud scheduler.

Ordinary cloud conversation admission is an extension beyond the currently audited structured-work-only path. Use trusted actor and mention metadata; a textual Bot name is not an authoritative mention. Channel access, admission, wake timing and work authorization remain separate. Wake does not grant local files, tools or approval authority, and normal group messages must not create unbounded Bot-to-Bot reply loops.

Persist each Bot's per-Channel settings on its executing Host. Only its owner may edit them in this scope. Use an owner-authenticated Host management path; no cloud-mediated management relay or assumption that a cloud administrator is the Bot owner. This is the conservative implementation boundary following the confirmed local-authority decision, not a new identity federation mechanism.

Cloud loss does not prevent local policy evaluation or work using available local resources. Tasks needing external models/tools still need connectivity. Reconnect recovers authorized messages with durable delivery/admission deduplication, never promises exactly-once arbitrary external side effects, and does not replay completed work. Expired or state-invalid execution requests require confirmation under the previously agreed work boundary. Ordinary unseen chat still follows reception and wake rules; reconnect does not automatically wake once per historical message.

Proposed delivery order — confirmed testing sequence

Each slice is a runnable vertical path with source authority, API/CLI parity, a real client interaction and focused automated regression. Preparatory transport or schema work alone does not complete a slice.

1. Mixed mobile list and correct send: on one mobile client, explicitly connect one Computer and one UAT cloud account; list, filter, open and send to each with the correct author/source. Demonstrate cloud send while the Host is offline, retained Computer draft, and no reconnect autosend. One coherent path precedes additional source variants.
2. Web/Desktop and multiple Computers: bring the same path to browser Web and DSH Desktop, add a second paired Host, and prove colliding names/IDs, independent client connections and unrelated management context remain isolated. A same-machine pair of isolated Hosts is valid logical-device coverage; label it accurately. Expo web is not browser Web or DSH Desktop qualification.
3. Source-owned read and pins: use mobile plus another authenticated client to verify read/pin synchronization, sorting and account/source isolation through TOB and existing Host authority.
4. Ordinary cloud chat wakes a local Bot: join a granted cloud Channel, configure policy through owner-authenticated Host access, send ordinary chat/real mentions, verify admission/wake and same-Channel response. Include two Bots with different policies, Host disconnect/restart/replay and non-owner denial. Preserve separate work authorization.

The unified experience is not complete until all three client surfaces and the confirmed synchronization/wake behavior pass. Seek feedback after the first working slice before expanding. These are proposed implementation slices, not newly created tickets or authorization to start them.

Testing Decisions

The Human confirmed these boundaries for publication on 2026-10-18: real mobile, browser Web and DSH Desktop interactions through existing Host API and TOB public API; independently inspect owning persistence, identity and permissions; use CLI for the same business operations; verify Bot wake through real Host Inbox and execution facts. UAT only.

Use the highest existing business seams. Focused tests observe public outcomes, persistence after restart, and coded refusals rather than component internals or duplicated implementation logic. Prior art is existing Host Channel read/roster tests, cloud transport/admission/work tests, mobile authenticated-client lifecycle tests, and the UAT multi-Host cloud work path. Preserve the difference between structured-work evidence and new ordinary-chat behavior.

For runtime evidence, use UAT fixtures and two independently configured local Hosts where needed. Run at least one actual Bot response for the wake path; source/API tests alone cannot establish model/runtime behavior. Restrict work to a preauthorized harmless action for execution-boundary tests.

Follow the shared device queue for native builds, Simulator and phone use. Capture reviewer-accessible screenshots and recordings for visible UI changes, bound to the tested PR/head. Distinguish source tests, CI, live APIs, native runtime, browser Web, DSH Desktop and Human QA. No old screenshot, mocked login or source-only Desktop inspection qualifies an untested surface. Keep credentials and unrelated conversations out of evidence.

CLI commands must use the same owners and permission checks as UI operations, with secret input through files/stdin and sanitized machine-readable output. New Host routes or Bot tools require matching CLI parity; direct cloud operations use the TOB CLI where applicable.

Out of Scope

• Global account federation, automatic Tailscale discovery/authorization, cross-instance cloud federation, or automatic client connection synchronization.
• Replication of all local Host chats into the cloud, a global message database, or self-built shared file storage.
• A second cloud Wake Policy engine, delegated editing of Bot wake settings, or cloud membership implying Host ownership.
• A new cloud management relay for offline/otherwise unpaired Hosts.
• Automatic offline draft sending, a general offline execution guarantee for network-dependent tasks, or exactly-once arbitrary tool side effects.
• Advanced Channel visibility policy, global search, new encryption/authentication models, billing and Prod deployment.
• Implementation, PR merge or release as a side effect of publishing this specification.

Further Notes

• This extends the existing cloud navigation/sharing work rather than replacing its invitation semantics. Related issue: Cloud channel UX: source marks, organization navigation and scoped sharing #2161.
• Existing code facts were inspected at local remote-tracking DeepSeekBot revision 648c1202c44f5a5e82ce22596682934745705cef; this is a source snapshot, not a claim that every linked PR has merged or shipped.
• At that snapshot, mobile has one active Host client/inbox, direct cloud pages are separate, and selected cloud Organization scope changes with session selection. Simultaneous multi-source operation requires lifecycle and authorization work beyond concatenating list arrays.
• The preceding TOB source inspection found no read-position/pin contracts; these must be verified against current main before implementation. History access boundaries are not unread state.
• Desktop source inspection established a distinct app-origin/session boundary, not completed cloud credential storage or runtime qualification. Concrete browser/native transport and Desktop storage mechanisms must be verified at the first applicable slice.
• Before coding, refresh repository/PR state, reuse relevant open work, record the issue claim, and establish an isolated worktree. Add approved durable architectural decisions to the living architecture when implementation selects concrete seams. Do not alter unrelated dirty work.

Consolidation from #377 — cross-account purpose and boundaries (2026-10-25)

The old idea ticket is retired into the accepted Open Cloud Groups direction here and the invitation flow in #2161. This is a decision/acceptance carry-forward, not a new implementation prerequisite or a reversal of the accepted cloud direction.

• 377-A — Purpose / why: record the concrete cross-account Human + their Bot collaboration journey that existing Lark/Slack/Discord groups do not adequately serve, and the benefit that justifies native shared-channel operating cost. Record the trade-off in this spec/current design rather than opening a parallel speculative platform.
• 377-B — Authority: make the existing owners of cross-account membership, identity, moderation, message visibility and retention explicit; test that an account cannot observe another account's ungranted channel/history. Use this issue's current Source-scoped authority and canonical storage; do not create a second membership or message truth.
• 377-C — Bot ownership / usage: explain whose Bot executes, which trusted owner supplies its model credentials, and how execution/usage remains isolated across Humans. Invitations and membership never transfer a Human's API token to another account. Verify the boundary through the current execution/authentication path.
• 377-D — Linked invitation acceptance: Cloud channel UX: source marks, organization navigation and scoped sharing #2161 carries the guest/invitation-specific scope, identity, revocation and retention/visibility boundary checks below; review both checklists together before claiming the old idea's remaining questions resolved.

Historical alternatives in #377 (including an unspecified Durable Object design or raw owner-token scheme) are not new requirements. Existing UAT-only scope and release/production authorization gates remain in force.