Skip to main content

Connectivity and Collaboration

Telemus AI connects supported devices through configured sync hubs and provides channel integrations for working through messaging services. Connectivity, workspace permission and successful delivery are separate states; check the relevant status before assuming a change appeared elsewhere.

Networking Control Center​

Open Networking Center in the native app, Network → Sync in Command Center, or /networking in the terminal.

  • Enable or pause automatic sync without removing the saved connection.
  • Inspect configured hubs, connection status, progress and last successful sync.
  • Use Sync now for an explicit transfer and read its result.
  • Review conflicts and available connection diagnostics.
  • Open Advanced settings to review the server and workspace/device identity. The bearer field does not display a saved token; leaving it blank keeps the saved value.

A brief Checking license, retrying… message means access verification is in progress. Read-only status can be retried; a failed action is not automatically replayed. Inspect its result before retrying. Native and terminal controls report the same host state using their own layouts.

Live sync paused: device identity needs review​

An orphan device identity means the sync server has older changes from this device but no recorded owner. Your data still exists. Do not wipe the workspace, rename the device or relink accounts simply to clear this notice.

A workspace owner can open Network in Command Center and choose Claim this device's sync history when offered. Read the explanation and type confirm. The terminal equivalent is /access claim-device confirm. Other members should ask the workspace owner to review the device setup.

A claim records ownership; it does not change workspace contents or take an identity already owned by another account. Native 3D shows the reason and directs you to the Web or terminal confirmation flow.

Status reasonWhat to do
orphan_device_identityAsk the workspace owner to review a claim for this device.
device_bound_to_other_principalReview account/device setup; this identity cannot be claimed.
device_binding_limit or unowned_identity_limitAsk the operator to review available capacity.
device_identity_invalidReview the device configuration with the operator.
access_server_unconfiguredComplete or clear incomplete sync configuration before retrying.

After a successful claim, allow the next sync attempt or select Sync now. Repeated retries do not resolve an ownership problem. A successful connection still does not prove that workspace data was transferred.

Shared 3D objects deferred​

A device can load up to 256 shared 3D object records, including retained deletion records. A larger shared scene, or objects in an unsupported older format, can produce Shared 3D objects deferred. Other eligible workspace content can still be received while the shared objects remain unchanged on the hub and device.

Web Network and Device Link, terminal /sync or /networking, and the native Networking Center report the reason and available counts. Do not relink or erase your workspace to clear the message. A workspace owner can review whether old objects need to be removed or recreated.

While this state persists, foreground native flat/XR apps may receive workspace data without uploading their local mind-map, note or workspace edits. Headless hosts do not have that foreground limitation. Check both devices when confirming a handoff.

Saved objects beyond the local scene limit​

Local restore can display up to 256 active spawned objects. Additional saved objects remain on disk for a later load. They are not rendered, included in workspace exports or published by sync until loaded.

Clear scene clears loaded objects only. Retained objects can reappear after a later restart when space is available. If restore cannot complete, saving is refused to protect the saved world. Preserve a backup before downgrading to an older build, which may not retain these extra objects when it saves.

Dedicated servers and private networks​

A configured dedicated server can provide a persistent sync hub. Exposed servers require authenticated access and an appropriate TLS deployment. Workspace roles control what viewers, members, moderators and owners can do; connecting to the server alone does not grant workspace permission.

Each server process needs its own address and port. If an existing server is unavailable, review its configuration rather than starting a second server on the same listener.

Tailscale can provide a private route to an existing dedicated server. It does not replace application authentication, workspace roles or public callback URLs needed by some messaging providers. Operators can advertise a private server address with --tailscale-url or VRAI_TAILSCALE_URL; use --prefer-tailscale when that address should be preferred by supported discovery clients.

Trusted LAN hosting​

Desktop HOST LAN supports local discovery and joining. Discovery advertises the server transport token to devices that can reach the listener. Use it only on a trusted network, not public or shared Wi-Fi. The token is not limited to joining; account and workspace-role checks remain separate.

An operator must configure the verified owner for a license-gated multi-user host. For private hosting, use --no-lan-discovery or --private, restrict network access and share credentials separately. Rotate a token previously advertised on a network you no longer trust.

P2P quick sessions​

P2P quick sessions remain an experimental connectivity feature. They are not an authoritative route for ordinary workspace or private assistant synchronization. A successful connectivity test does not establish complete collaboration, account invitations or transfer support.

Supported builds offer NAT and STUN/TURN diagnostics. The native Networking Center, Web Network panel and /networking turn-allocate in the terminal can inspect available relay connectivity. Unsupported browser, device or transport capabilities are reported rather than silently replaced with a working session.

Connect messaging services​

Use Quick Connect, Channels Center, or the account portal's Device settings to find supported connectors and their setup requirements. A catalog entry is not proof that a connection is active or that every provider feature is available on your host.

The catalog includes integrations for Telegram, WhatsApp, Discord, Slack, Email, Matrix, Microsoft Teams, Signal, Mattermost, IRC, Twitch, iMessage/BlueBubbles, WeChat, LINE, Google Chat, Twilio SMS, Home Assistant and other supported services. Some require a desktop/headless host, a provider-approved callback setup or a separate local companion. iMessage requires an appropriate Mac companion.

Configure provider credentials on the authorized app or relay host as directed by its setup guide. General portal device settings and Web/terminal channel controls do not accept provider tokens. Do not paste credentials into conversations.

Setup complete means required settings and checklist steps are present. Use Test Connection for current health. Keep existing pairing, pending messages and saved work while investigating a failure.

Voice, encrypted messaging and attachment support vary by connector and packaged build. In particular, native Discord voice transport availability does not prove that conversational speech recognition is available, and Matrix encrypted messaging requires an appropriately configured supported host. A missing security capability must not be worked around by disabling verification.

Channel conversations and approvals​

Supported channel conversations can use these controls:

CommandPurpose
/help, /status, /usageRead available commands and current status.
/newStart a fresh conversation context.
/stopStop supported active work in this conversation.
/model, /personaSelect supported conversation preferences.
/approve, /denyResolve a matching pending approval when the workflow allows it.
/background, /retry, /agentsInspect or request supported background and agent workflows.
/compact [instructions]Request a conversation summary, with an optional focus hint.
/thinkRead or set a supported reasoning preference for later turns.

Available controls depend on the active host and connector. Read confirmation cards completely. Approval applies to the displayed action and conversation; a chat message does not grant general execution permission. Some actions cannot proceed when their required review is unavailable.

Telemus can show typing and progress while work continues. If a background command finishes, the assistant can report its result or continue within the original task limits. Clearing or stopping work does not recall provider messages or undo completed side effects. After a restart or uncertain result, inspect existing output before explicitly resuming; work is not a guaranteed saved research checkpoint.

Long replies may be collapsed or split to fit the messaging service. Approval prompts remain fully visible. The assistant may end repeated unproductive checks with a partial answer explaining what remains unresolved.

Telegram group engagement​

Telegram groups require an assistant-name mention by default. Direct messages keep their normal behavior. Use the channel engagement setting always to allow ordinary group replies without a mention, or off to disable them. Per-chat settings take priority over connector and global preferences.

A mention affects engagement, not sender authorization. Allowlist and approval requirements still apply. Separate group messages are handled independently.

Bind a channel to a workspace​

A channel conversation needs an explicit owner grant before it can act on a saved workspace. This is separate from channel setup, pairing and private memory.

  1. Open Channels Center → Workspace Access in the native app, or Operations → Channels → Channel Workspaces → Review workspace access in Command Center.
  2. On a configured hosted Command Center, sign in to the dashboard, then verify the workspace owner using Continue with Telemus account or the offered email/authenticator flow.
  3. Select the exact listed channel actor and saved workspace.
  4. Read the complete grant or revoke review, including any group disclosure, and confirm that exact review once.

The verified account must match the saved workspace owner. A dashboard password, bot pairing or connector catalog entry alone does not grant ownership. Closing the review discards it without revoking an existing grant. Private details clear when you leave the review; reopen it explicitly when needed.

After a grant, supported conversations can use:

  • /bind to inspect the current binding.
  • /bind list to list granted workspaces.
  • /bind <exact workspace name or ID> to preview a selection.
  • /bind confirm <preview-id> to confirm that selection.
  • /unbind to clear the active selection.

Owner Revoke removes the grant. For supported local terminal owner review, start with /sync assistant channel-workspaces, then follow the listed grant or revoke review and confirmation commands. Remote terminal owner review is not a substitute for the separately verified hosted Web workflow.

A grant saves permission; it does not prove that a remote action ran or appeared on a device. Supported saved-workspace edits are limited. Whole-section replacement, imported assets, live-device actions and general native-world editing are not available through this workflow. Requests needing an unavailable confirmation are refused.

Workspace details are withheld when the connector lacks a supported private reply path. A fixed request notice is not proof that the action was applied. After an uncertain reply, refresh owner status instead of repeating an old confirmation. See channel workspace callbacks for supported integration requirements.

Explicit private channel memory​

On a supported official Telegram bot private-text connection, a local owner can consent to a separate private memory for that verified conversation. Pairing and allowlisting alone are not memory consent. This workflow requires a supported desktop/headless host; ordinary mobile and standalone Web apps do not host it.

Available private-conversation commands are:

  • /memory remember <text>: save a fact, up to 3,000 bytes.
  • /memory search <query>: find scoped facts.
  • /memory get <entry-id>: read a scoped fact.
  • /memory delete <entry-id>: delete that fact.

The local owner uses the Assistant Sharing private controls to review the observed peer and consent. Remote Web, generic tool confirmations and ordinary chat replies cannot approve this private-store grant. Restart, configuration changes or consent expiry can require fresh verification and consent.

Revoke stops new access; it cannot recall a copy already delivered. Erase reports incomplete cleanup when work is still pending and does not erase provider copies or backups. Groups, forwarded or edited messages, attachments and unsupported adapters are outside this private-text workflow.

Owner-shared recall is separate: configured connectors may use canonical owner notes and trusted main-agent memories in replies. Other chats' transcripts and these private binding stores are excluded. Operators can disable shared channel recall with VRAI_MEMORY_CHANNELS=0. The configured relay and provider process messages; this is not end-to-end secrecy from that infrastructure.

Talk in an existing channel from the app​

The Channel dropdown beside Workspace selects a known conversation. Local / private assistant is the default. Selecting a channel sends both your operator message and the assistant's reply there, using the bot's identity. Always check the visible recipient, account and topic before sending.

Use Refresh conversations, Check status, or Cancel channel turn from the dropdown. Opening it or refreshing does not select a recipient or send a message. If no verified conversation is listed, receive a fresh message from the intended conversation and refresh. A connector name alone is not a destination.

The terminal provides /destination, /destination <number>, /destination history, /destination status and /destination cancel. Return with /destination local after active work settles. /channels manages connectors rather than selecting a conversation.

Channel history stays separate from private chat. The picker currently accepts text only. Switching destinations keeps the channel draft, so review it before sending. An active request keeps its original destination. Host file/process permissions and normal approvals still apply.

Queued is not delivered. Confirmed needs provider evidence. Uncertain means the result is unknown: check status and the conversation before resending. Cancellation cannot recall a message already accepted by the host or provider.

Attachments, audio and message actions​

Supported channel turns can preview a stored UTF-8 text or code attachment up to 5 MiB. The preview can be shorter than the file and applies to the current turn only. For a later question, attach it again or request a read of the retained original. Attachment content is treated as untrusted input.

Automatic PDF previews and UTF-16 decoding are unavailable in this channel workflow. PDF references are retained without claiming that page images or extracted text were supplied to the assistant. Provider download restrictions can also leave an attachment as metadata only.

Desktop/headless channel transcription supports Ogg/Opus voice notes up to 8 MiB and 120 seconds when a usable local speech model is configured. Unsupported formats or unavailable transcription prompt a text fallback. There is no automatic cloud-transcription fallback for this path.

Supported Telegram conversations can request a reaction to a known message or an edit/delete of the bot's own recorded text message in the current conversation. Other people's messages and unknown message IDs cannot be changed. Wait for a streamed reply to finish before editing it. Queuing an action is not delivery proof, and an uncertain action is not automatically repeated.