Secure Messaging (Telegram)

Phase 11.1 introduces the first production secure-messaging connector for Nous: Telegram, routed through the canonical communication-gateway runtime. Phase 11.3 adds the canonical voice-control runtime that later messaging and mobile surfaces can consume without creating a connector-owned voice policy path.

This guide explains what operators can expect from messaging behavior, what is required for trusted actions, and what remains out of scope in this phase.

Current Connector Posture

• Production connector in this phase: Telegram
• Runtime boundary: Telegram adapter traffic is normalized and routed through ICommunicationGatewayService
• Control-plane rule: Connector code does not become the source of truth for routing, escalation status, advisory status, trust, or project state

Identity-Binding Expectations

Messaging identities are explicit and fail closed:

• unbound identities are routed to approval intake only
• active identities can participate in trusted messaging actions allowed by policy
• revoked identities are treated as untrusted for privileged behavior

If an identity is not actively bound, privileged actions are blocked rather than inferred.

Escalation Acknowledgement Continuity

Escalation acknowledgement from messaging updates the same canonical escalation record used by in-app surfaces.

What this means:

• Acknowledging from messaging does not create a parallel escalation state
• Acknowledgement status remains consistent across Projects, Chat, and messaging routes
• Acknowledgement records awareness; it does not bypass project control-state or other governance rules

Advisory-Delivery Continuity

Messaging advisory delivery uses the existing communication_gateway advisory surface and canonical nudge/runtime seams.

What this means:

• Trust, suppression, compatibility, and ranking posture are reused from existing runtime services
• Messaging does not re-rank recommendations locally
• Blocked advisory delivery remains reason-coded and evidence-linked

Voice Continuity (Phase 11.3)

Voice safety now has a canonical runtime even though connector-native call UX and mobile continuity are still later-phase work.

What this means:

• Voice turn completion requires combined semantic, silence-window, and explicit handoff signals
• Risky voice actions can be deferred to text confirmation instead of executing from voice alone
• T3 and destructive voice actions require dual-channel confirmation from the active Principal session
• Barge-in stops assistant output immediately and requires explicit continuation
• Degraded mode pushes risky control handling to text-first behavior while keeping voice state visible to other surfaces

The connector remains thin. When a messaging or bridge surface eventually supplies normalized voice signals, canonical voice turn state still lives in IVoiceControlService, not in the connector.

Operator Examples

Example: unbound identity

1. Message arrives from an identity without active binding.
2. Nous records approval intake.
3. Privileged project actions are not executed from that message.

Example: escalation acknowledgement from messaging

1. A user acknowledges an escalation from Telegram.
2. The canonical escalation record is updated.
3. Projects/Chat reflect the same acknowledgement state.

Out-of-Scope Boundaries for Phase 11.1

• Signal connector support
• Endpoint trust and device pairing workflows
• Mobile app-specific runtime surfaces
• Connector-native voice call UX and mobile continuity behavior

These are handled in later Phase 11 sub-phases and are intentionally not part of Phase 11.1 delivery.

Related

• Chat
• Voice Control
• Projects
• Interaction Surfaces