Feature parity across the clients
nanoMuse is one agent on every device: the phone (Android, iOS), the computer (nanoMuse Desktop — the dsh-nanomuse harness bundle in the Electron shell) and the browser (nanoMuse Web, served by the runtime). The rule since 0.1.32 is the union: whatever one client can do, every client does, unless the platform itself forbids it (the computer does not build a mini-Linux the way the phone does; iOS does not let an app drive another). This page is the ledger — what each client has, what is platform-specific by design, and what is still open for a decision.
Legend: ✓ done · ◐ partial (what is missing is in the note) · — not on this client · n/a platform-specific, not meant to be.
Account (nanoMuse Cloud)
| Feature | Android | iOS | Desktop | Web |
|---|---|---|---|---|
| Sign in with a code (phone / e-mail) | ✓ | ✓ | ✓ | ✓ |
| Sign in with a password | ✓ | ✓ 0.1.32 | ✓ | ✓ |
| Invite code at sign-in | ✓ | ✓ 0.1.32 | ✓ 0.1.32 | ✓ |
Amounts from the relay (/v1/config) before sign-in | ✓ | ✓ 0.1.32 | ✓ 0.1.32 | ✓ |
| Allowance in yuan, 80 % heads-up | ✓ | ✓ 0.1.32 | ✓ 0.1.32 | ✓ |
| "Ways on" when the pool is spent (own key · invite · star) | ✓ | ✓ 0.1.32 | ✓ 0.1.32 | ✓ |
| Invite code and link, earnings | ✓ | ✓ 0.1.32 | ✓ | ✓ |
| Usage by kind and by model, today / all time | ✓ | ✓ 0.1.32 | ✓ 0.1.32 | ✓ |
| Set / change / remove the password | ✓ | ✓ 0.1.32 | ✓ 0.1.32 | ✓ |
| Signed-in devices, revoke one, sign out everywhere | ✓ | ✓ 0.1.32 | ✓ 0.1.32 | ✓ |
| Account timeline (sign-ins, settings, refusals) | ✓ | ✓ 0.1.32 | ✓ 0.1.32 | ✓ |
| Delete account | ✓ | ✓ 0.1.32 | ✓ 0.1.32 | ✓ |
| Data controls (what the relay keeps of the chats) | ✓ | ✓ 0.1.33 | ✓ | ✓ |
| Own-key presets (Bailian · OpenRouter, by region) | ✓ 0.1.34 | ✓ 0.1.34 | ✓ 0.1.34 | ✓ 0.1.34 |
Chat model and Hands model as two settings (deepseek-v4.1-flash / qwen3.8-27b, the relay's for) | ✓ 0.1.34 | ✓ 0.1.34 (chat; no hands) | ✓ 0.1.34 | ✓ 0.1.34 |
| "Ways on" ordered by region (Bailian first on the mainland, OpenRouter first elsewhere) | ✓ 0.1.34 | ✓ 0.1.34 | ✓ 0.1.34 | ✓ 0.1.34 |
Own-key catalogue (providers.json: 18 providers, what each covers — chat · screen · pictures · clips — key pages, regions; one file, generated for every client) | ✓ 0.1.39 | ◐ 0.1.39 (the file ships with the app; the ways card still reads the 0.1.34 presets) (32) | ✓ 0.1.39 | ✓ 0.1.39 |
| "Ways on" from the catalogue: the region's lead first, more providers, the plans one can sign in with, the key taken inline | ✓ 0.1.39 | — (32) | ✓ 0.1.39 Settings → Account, the own-key first-run step | ✓ 0.1.39 |
| Sign in with a ChatGPT plan — chat and the hands' screen reading only, with the line about OpenAI's terms | ✓ 0.1.39 upstream's sign-ins (also Claude, Kimi, OpenRouter) | — (32) | ✓ 0.1.39 through the bundled runtime | ✓ 0.1.39 the runtime's nanomuse chatgpt login |
| A capability nobody configured has is one sentence naming who could (pictures, clips, the screen), never a raw error | ✓ 0.1.39 | — (32) | ✓ 0.1.39 | ✓ 0.1.39 |
| Conversations belong to the account that synced them: another account's stay on the device, hidden, never pushed under the new key; a switch restarts the pull (contract C10) | ✓ 0.1.39 | ✓ 0.1.39 | ✓ 0.1.39 | ✓ 0.1.39 the runtime's lists |
The agent in the chat
| Feature | Android | iOS | Desktop | Web |
|---|---|---|---|---|
| Status line says what it is on, never "Thinking" | ✓ | ✓ 0.1.32 "is on it" | ✓ | ✓ |
Status line = the step's own words (step: 打开携程网站), never the raw command | ✓ 0.1.33 | ✓ 0.1.33 | ✓ 0.1.33 | ✓ 0.1.33 |
| "Show the agent's steps", on by default since 0.1.37 (a stored off stays off) | ✓ 0.1.37 (nm.show_steps) | ✓ 0.1.37 (nanomuse.show_steps) (2) | ✓ 0.1.37 | ✓ 0.1.37 |
Star asks at the relay's moments (/v1/nudges: sign-in · 3rd / 10th / 30th task · 7th / 30th day · a goal reached · a new look · allowance spent; 7 days apart, 4 per device; never in the first conversation) | ✓ 0.1.35 | ✓ 0.1.35 (3) | ✓ 0.1.35 | ✓ 0.1.35 |
First conversation: the app speaks first, asks what to call you, the model's nanomuse-naming fence becomes the naming card | ✓ | ✓ 0.1.34 | ✓ 0.1.35 (25) | ✓ |
| First run: "Sign in — free" before anything else | ✓ | ✓ 0.1.32 (4) | ✓ | ✓ |
| Approval cards, three tiers, remembered grants | ✓ | upstream's | ✓ | ✓ |
| Approvals answered outside the app while the hands work | ✓ 0.1.33 capsule Allow / Deny | n/a (10) | ✓ 0.1.34 stage Allow once / Always in app / Deny, capsule when the window is behind (17) | n/a |
| Hand-over: a login / code / payment / CAPTCHA goes back to the person, the agent waits and resumes (holds) | ✓ 0.1.33 hand_over | — (16) | ✓ 0.1.34 Your turn — Done, I'll take it (16) | ✓ 0.1.34 drivable browser viewer, hold cards (16) |
| Face tap opens the agent page (Change avatar · Edit name · studio; Activity · Approvals · Daily · Soul & memory; share card) | ✓ | ✓ 0.1.34 | ✓ 0.1.34 | ✓ Muse page |
| Change the look from the chat (the same words, four candidates, pick by words, regenerate) | ✓ | ✓ 0.1.34 | ✓ 0.1.34 | ✓ studio intercept, reference picture 0.1.34 |
Connectors, agents, devices
| Feature | Android | iOS | Desktop | Web |
|---|---|---|---|---|
| Connectors catalogue (75 remote MCP servers, sign in) | ✓ 0.1.32 (5) | ✓ 0.1.33 (6) | ✓ | — (7) |
| Services without dynamic registration (GitHub, Slack, Discord, …) ask for an OAuth client id | ✓ 0.1.33 | ✓ 0.1.33 | ✓ 0.1.33 | — (7) |
| MCP servers by hand (URL / command) | ✓ Your own servers under Connectors 0.1.33 | ✓ Your own servers under Connectors 0.1.33 | ✓ (harness) | ✓ |
Connections shared across the account's devices (the profile's connectors; never a credential) | ✓ 0.1.34 | ✓ 0.1.34 | ✓ 0.1.34 | ✓ 0.1.34 (18) |
| Chat apps: Feishu · DingTalk · WeCom · Telegram answer as the agent (pairing codes, allowlists, deliver here) | — (22) | — (22) | ✓ 0.1.34 the web screen | ✓ 0.1.34 Settings → Chat apps |
| Skills | ✓ upstream | ✓ upstream | — (8) | ✓ |
| Coding agents (Cursor, Codex, Claude Code on the computers) | ✓ | ✓ 0.1.34 over the hub (9) | — (8) | ✓ |
| Devices of the account, remote control, rename, forget | ✓ | ◐ list, Reach sheet 0.1.33 | ✓ | ✓ |
| Hands — the device's own screen as a hand | ✓ | n/a (10) | ✓ the screen; on macOS one window while the person keeps the mouse, per-app grants, glow and capsule out of the shots (19) | n/a |
Installed and latest version, side by side (nanomuse.cn/dl/index.json first, GitHub second, a day's cache) | ✓ 0.1.35 Settings → Version | ✓ 0.1.35 Settings → Version | ✓ 0.1.35 About, Settings row | ✓ 0.1.35 Settings |
| A black capture is an error with the fix (Screen Recording, Wayland), never a picture | n/a | n/a | ✓ 0.1.33 | n/a |
| macOS permissions read back live; Open System Settings after an ask; Screen Recording relaunch notice | n/a | n/a | ✓ 0.1.33; 0.1.35: only nanoMuse Desktop has to be switched on, Try it rows, a restart dialog when Screen Recording flips on (26) | n/a |
| Mini-Linux sandbox on the device | ✓ | ✓ upstream (iSH) | n/a — the runtime's own sandbox | n/a |
Face, rooms, look
| Feature | Android | iOS | Desktop | Web |
|---|---|---|---|---|
| Avatar studio: generate, pick, pose; the face shared across devices | ✓ | ✓ 0.1.33 (11) | ✓ | ✓ |
Motion clips for a drawn face (idle · working · waiting · happy; wan2.2-i2v-flash; Animate the avatar after a change) | ✓ | ✓ 0.1.35 | ✓ 0.1.35 header, sidebar, capsule | — (27) |
| Emoji faces | ◐ falls back to the dragon (12) | ◐ falls back to the dragon (12) | ✓ | ✓ |
| Theme colour swatches | — | — | — removed 0.1.33 (13) | — |
| Accent follows the avatar | ✓ | ✓ | ✓ | ✓ |
| Rooms: Feed · Ideas · Goals · Library | ✓ | ✓ 0.1.34 with a scheduler (11) | ✓ 0.1.34 on the phone's fence protocol | ✓ |
| Ideas by kind: chat · routine (at a time) · goal (a category) | ✓ | ✓ 0.1.34 | ✓ 0.1.34 the phone's list | ✓ 0.1.34 |
| First run: the phone's pages (sign in · password · which model answers · models · permissions · notifications · meet), then the shell; never skipped on a fresh install | ✓ | ✓ 0.1.34, notifications page 0.1.35 (4) | ✓ 0.1.35 kept by the host in firstrun.json (25) | ✓ onboarding |
| Feed opens on the intro card (Write it now), the first day is written after the first conversation, a daily routine at 08:00 | ✓ | ✓ 0.1.35 | ✓ 0.1.35 | ✓ 0.1.35 |
Ideas prefilled with the curated list (ideas.{en,zh}.json, byte for byte, with a test) | ✓ | ✓ | ✓ 0.1.34; empty-when-bundled bug fixed 0.1.35 | ✓ 0.1.35 |
| Splash: wordmark and the person's own face, never the dragon | ✓ | ✓ system launch screen | ✓ 0.1.35 | n/a |
| Settings as Muse cards in one order (Image & video models · Avatar · Computers · Appearance · … · Version) | ✓ | ✓ 0.1.35 | ✓ sections | ✓ sections |
| Memory as a room | — settings page (14) | — | ✓ | ✓ |
| Live stage / browser viewer while the hands work | ✓ stage | n/a (10) | ✓ live stage — movable, resizable, remembered 0.1.33; Allow/Deny, holds, glow 0.1.34 | ✓ browser viewer you can drive 0.1.34 |
| Quick chat (global shortcut) | n/a | n/a | ✓ | n/a |
| Widgets | ✓ upstream | ✓ upstream | n/a | n/a |
Open for a decision (the "next-next" list)
These are the gaps left open on purpose since 0.1.32 — either the platform makes them a different design, or they are large enough that the call is the maintainer's. Numbers match the notes above; a settled item keeps its number and says how it went.
- iOS · Data controls — done in 0.1.33 (
NanoMuseDataControls.swift). - iOS · Steps. The header line (and the face) are there since 0.1.33; the steps of the message still running stay visible even with the setting off, finished messages hide them. Hide them too, now that the status line says what is going on?
- iOS · Star after the first task — done in 0.1.33, as a card pinned under the header (the message list is a UICollectionView; nothing can be placed under the last message). A cancelled turn counts as finished, the stream has no cancel signal. In 0.1.35 the card follows the relay's policy like everyone else (28): no ask in the first conversation, the 3rd task is the first moment.
- iOS · First run — done in 0.1.34 (
NanoMuseFirstRun.swift, the Androidneeded / stagelogic). Shown to anyone without a Cloud account, so a person upgrading who only ever used their own key sees it once; All settings skips it. - Android · OAuth connectors need a device test. Discovery, dynamic client registration, PKCE and the token written into the entry's
Authorizationheader compile and follow the desktop's flow line by line, but no connector was signed into on a device before 0.1.32 (no emulator on the build machine); the same goes for 0.1.33's client-id path (GitHub, Slack, …) and the browser hand-over. Key and open connectors are plain MCP entries and need nothing new. The token ends up inservers.jsonnext to API keys, as the in-guest client reads it; refresh runs at app start and when the page opens, not in the background. - iOS · Connectors — done in 0.1.33 (
NanoMuseConnectors.swift, the Android flow ported), with the same caveat as 5: compiled, not yet signed into on a device. - Web · Connectors. The runtime would have to run the OAuth flow itself and hold the tokens (the desktop does it in the harness host). The web app has MCP servers by hand. Decision: run the flow in the runtime (
nanomuse mcpalready bridges connectors), or point the web app at a desktop on the account? - Desktop · Skills and coding agents pages. The harness has its own skills; the coding agents live on the computer the desktop runs on, so a page would show the local CLIs. Recommendation: coding agents page yes (the web app has one), skills no (duplicate).
- iOS · Coding agents — done in 0.1.34 (
NanoMuseCoding.swift, the hub'scoding.*). - iOS · Hands. iOS does not let an app drive another; App Intents / Shortcuts are the door. Not planned as "hands". Settled in 0.1.36: the Settings row is there (Hands — Not on iPhone) and opens a page that says why, and what a computer of the account can do; the iPhone's own Muse takes
taskcalls from the other devices while the app is open (@iPhone …). - iOS · The Muse shell — done in 0.1.33 on the iPhone; in 0.1.34 Feed and Goals are real (
NanoMuseScheduler.swift: foreground catch-up,BGAppRefreshTask, a local notification at the set time), the iPad runs the shell too, the shell and header switches are in the nanoMuse settings page, and the studio draws through the relay or your own Bailian key. Left: a routine runs in the background only when iOS gives the refresh task a slot — the copy says so (at the set time the phone reminds you to open it); the hub route (a computer of the account runs them) is still the sure one. The iPad's layout is the iPhone's, larger — settled in 0.1.35: no split layout of its own. - Android and iOS · Emoji faces. A face set to an emoji on the web or the desktop shows the dragon on the phones. Small.
- Theme colour swatches — settled in 0.1.33: removed from the desktop; one rule everywhere, the accent follows the avatar.
- Android · Memory as a room. It is a settings page on the phone, a room elsewhere. Design call.
- Browser viewer on the desktop. The live stage shows the hands; a page viewer like the web app's is not there. Design call.
- Hand-over on the desktop and the web — settled in 0.1.34, both: holds in the runtime (
nanomuse/agent/holds.py;hand_overonbrowser,computer_act,phone_act;POST /api/holds,/done;holdevents; the agent waits up to ten minutes and looks again). The desktop's stage shows Your turn — Done and I'll take it; the web's browser viewer can be driven (Take over, click, type, scroll, URL, Done). Left: iOS has no hands, so nothing to hand over there (10). - Desktop · approvals outside the window — settled in 0.1.34: the live stage carries Allow once / Always in <app> / Deny, and a small always-on-top capsule shows the same card when the main window is not in front. Left to check on a Mac: the capsule's
showInactivemust not steal focus from the app being driven — on the Mac task sheet (docs/tasks/mac-check-0.1.36.md, D). - Connections shared across devices — settled in 0.1.34: the profile's
connectors(relay 0.17; merged per device, 64 at most, a key-like field name is a 400), four clients read and write it, the other devices' entries show as Connected on <device> — sign in here. The credential never leaves the device that minted it. - Desktop · hands that do not fight the person — settled for macOS in 0.1.34 the way the Codex app does it: window mode (
nanomuse/computer/mac_window.py;[hands] mode = auto) captures one application's window and posts the events to its process, so the person keeps the mouse; each application asks once (Let <Muse> use <App>?). Elsewhere the screen is shared, with the UI-TARS-style glow and the overlays kept out of the shots. Left: Linux and Windows have no window mode (a virtual display or a second session would be the port — Linux first, cheapest); the macOS path is written against the Quartz APIs and must be tried on a Mac (Screen Recording fallback, AX-less clicks, Retina mapping, scroll direction). Settled in 0.1.35:autostays the default, with a fail-safe — when the Quartz layer itself fails (not "the window went away", which is retried every look) the hands fall back to the whole screen for the rest of that target and say so once; an explicitwindowmode keeps trying. Settled in 0.1.36 for the pointer itself: the desktop's hands are UI-TARS-desktop's operator moved into the Electron main process (harness/desktop/src/operator.ts,@computer-use/nut-js, loopback HTTP to the runtime'sdesktopbackend), and the model's coordinates are pixels of the picture it saw, mapped once to the operator's screen (nanomuse/computer/coords.py) — the clicks that landed beside their targets on scaled displays are gone (≤1 px on a 4K display at scale 2). Left to try on a Mac and on Windows: the native addon in the packaged app, the coordinate space (points on a Mac), scroll units, ⌘ forctrl, content protection — the Mac task sheet, F. - Services without a public remote MCP server — the chat apps are settled in 0.1.34 the way nanobot does it: 飞书, 钉钉, 企业微信 and Telegram are channels the agent answers in (
nanomuse/channels/, the vendors' long-connection SDKs, no public address, pairing codes), which is what most people wanted from them. Still open as connectors (the agent reading or acting in the service): Zoom, LinkedIn, Zoho Invoice, WHOOP, 腾讯文档, 滴答清单, 网易邮箱, QQ 邮箱, 微信读书 — each a bridge of its own over the vendor's REST API, one developer account per vendor. Decision: which, if any, are worth a bridge? - Hands on Linux under Wayland. The capture and the pointer need X11 or XWayland today; a Wayland session gives a black frame (now an error with the hint). Since 0.1.36 the operator says so itself (
/info→available: false, Wayland session … log in with Xorg), and the Hands card shows the reason; UI-TARS-desktop has no Wayland path either. The portal route (xdg-desktop-portalScreenCast +libei) would make it work natively, at the cost of a permission dialog per session. Decision: worth it before the Linux desktop is promoted? - Chat apps on the phones. The channels live in the runtime; the web app (and so the desktop) has the settings screen. Android and iOS would need an
/api/channelsclient and the same card list (switch, fields, pairing codes, paired chats, Feishu QR) — the API and the strings are ready. Decision: next version? Also open: no vendor was connected end to end from the build machine (the SDK calls were checked offline against the real packages) — one test bot per vendor before announcing; Feishu sender names needcontact:user.base:readonly; approvals from a chat are always once. - Own-key presets and the chat default. After a Bailian or OpenRouter key is saved, the provider's
/modelslist decides what is offered;deepseek-v4.1-flashis not moved to the front automatically (only the Cloud group hasfollowPick). Recommendation: promote it when the list has it. - Relay billing of reasoning tokens. Counted as completion tokens; when a provider reports them separately and the count exceeds the completion count they are added, otherwise taken as included. A provider that reports them separately and smaller would be under-counted. Decision: keep the heuristic, or switch per provider?
- Desktop · first run and first conversation — settled in 0.1.35 after the phone: the host keeps
firstrun.jsonand never skips the pages on a fresh install; the app speaks first (three scripted lines, no tokens), asks what to call you, and the model'snanomuse-namingfence becomes the naming card (take_name/ask_user_questionare gone). Left, by design: the scripted lines are a client overlay, not stored messages; the address is a memory line rather than aGLOBAL.mdedit; the gear on the first-run pages dismisses them for the session only. - Desktop · macOS permissions — re-audited in 0.1.35: TCC attributes the bundled runtime to the responsible process, so only nanoMuse Desktop has to be switched on (the words say so now; the runtime no longer appears as a second entry to hunt for). Left to try on a Mac: the Try it rows after a fresh grant, the restart dialog when Screen Recording flips on, the capsule's
showInactive(17), window mode's AX-less clicks and Retina mapping (19), the face click after 0.1.36's change (no drag region under the face at all; the face below the title-bar band) — all on the Mac task sheet,docs/tasks/mac-check-0.1.36.md, written so that an agent on a Mac can run it end to end and send the fixes back. - Web · motion clips. The clips are per device (drawn where the face lives: the phone, the iPhone, the desktop). The web app shows the still face. Decision: draw them in the runtime too, or leave the web still?
- Star asks · what counts. The policy is the relay's (
/v1/admin/nudges, console → Star asks) and reaches every client within a day without an update. Two small differences left: Android asks once per phone when the allowance is spent (the other clients the same); the first feed day is not written when the person changes the face during the naming conversation (the first run never reaches done). Small. - One conversation on every device — settled in 0.1.36 (contract C7 in
docs/cloud.md): the text of the chats lives on the relay (/v1/sync/*, relay 0.19), on by default when signed in, with the switch and the delete under Data controls on every client; one main conversation per account; what a device started on its own (routines, goals, the feed, work for another device) stays on it. One thread since 0.1.37 (contract C8): the main chat on every device is the union of what was said on all of them in time order, the other devices' turns as read-only bubbles (From Pixel 8) the model reads too; a side chat from elsewhere is a chat on the device at once; the person's message goes up when sent, the reply at the turn's end; the whole history is backfilled on sign-in. The desktop appends the other devices' turns to the dsh session log (user/message, sourcenanomuse-sync) and dresses them in the browser. Left: the dsh plugin has no delete, so an archived session is not a tombstone, a message deleted elsewhere is hidden rather than removed from the log; switching sync off on one device reaches the others at their next push or pull (a409), not at once; on iOS a pulled message that arrives late sits after the local ones (the OpenMinis store appends).@<device name>runs a turn on another device — computers whenever online, phones while the app is open; on iOS the mention goes to the hub directly (nodelegatetool there) and the iPhone answerstaskcalls itself. - iOS · composer, bubbles, header — settled in 0.1.36 after the phone: the one-row pill, flat grey bubbles for the person, a floating translucent header. Left: on iOS 16–18 the transcript starts below the header's edge rather than scrolling under it (the UIKit list needs the inset passed down; to be tried on a device — the risk of covering the first message was not worth taking blind).
- Desktop · the operator on a Mac and on Windows. Ported from UI-TARS-desktop and proven on Linux X11; the native addon, the coordinate space (points on a Mac, physical pixels on Windows), scroll units, ⌘ for
ctrl, content protection of the glow are on the Mac task sheet (docs/tasks/mac-check-0.1.36.md, F). Wayland stays item 21. - iOS · the ways card on the catalogue. 0.1.39 gave the iPhone its account-scoped conversations (contract C10,
NanoMuseSync) and the bundledproviders.json, but the allowance card still offers the 0.1.34 presets and has no plan sign-in; the AndroidAllowanceWaysCardis the model (the region's lead, more providers, the plans, the one-sentence unavailable lines where a picker is empty). On the Mac side's sheet for 0.1.40.
Keeping this true
- The desktop's connectors catalogue is the source (
harness/dsh-nanomuse/src/connectors-catalogue.ts);node scripts/connectors-json.mjswrites the Android asset and the iPhone's bundled copy,--check(in the harness workflow) fails when either is stale. - The own-key provider catalogue is
nanomuse/llm/providers.json;node scripts/providers-json.mjswrites the desktop's, the relay's and the phones' copies and--checkfails when one is stale. A new provider, a changed endpoint or a capability lands there and nowhere else. - Relay-facing code mirrors the same wire format on every client:
nanomuse/cloud.py(runtime),harness/dsh-nanomuse/src/relay.ts(desktop),io.github.nanomuse.cloud.NanoMuseCloud(Android),NanoMuse/NanoMuseCloud.swift+NanoMuseAccount.swift(iOS). A new relay field lands in all four. - The star asks follow one policy everywhere — the relay's
/v1/nudges(contract C1 indocs/cloud.md), with the same defaults built into every client: a task is a turn the person started that got a reply, never the first conversation, a routine, a feed post or a goal check-in; once per moment,cooldown_daysapart,max_asksper device, never again after Star on GitHub (nm.star.*/nanomuse.star.*). Clients:nanomuse/nudges.py,harness/dsh-nanomuse/src/nudges.ts,web/src/nudges.ts,io.github.nanomuse.community.Nudges,NanoMuse/NanoMuseNudges.swift. - The release check reads the same two sources in the same order on every client:
https://nanomuse.cn/dl/index.json, then GitHub'sreleases/latest; a day's cache; the row always shows the installed version too. - Conversation sync speaks one wire format (contract C7 in
docs/cloud.md) from four clients and one relay:cloud/nanomuse_cloud/sync.py,nanomuse/sync/(runtime and web),harness/dsh-nanomuse/src/sync.ts(desktop),io.github.nanomuse.sync(Android),NanoMuse/NanoMuseSync.swift(iOS). Every client applies a page's conversations before its messages and moves its cursor only on a pull; every client pushes the person's lines and the final answer only — never tool steps, tool results or the system prompt — and leaves routines, goals, the feed and work for another device at home. ideas.en.json/ideas.zh.jsonare one file four times (Android assets, iOS Resources,harness/dsh-nanomuse/assets,web/src/ideas); the harness and web tests fail when a copy drifts.