Mocha Enchanced Network Protocol (MENP) Specification and Reference

(Last updated: April 29th, 2026)

This document is the current public reference for the Mocha Enhanced Network Protocol (MENP/1.0) and the services around it.

Service map

• Mocha Passport Identity, account, and supporting web APIs for the Mocha stack.
• Notification Server (NS) Public Messenger entry point for sign-in, contact sync, presence, and conversation routing.
• Switchboard (SB) Conversation relay for chat, typing, and the current media lanes.
• Mocha Messenger Windows desktop client that speaks MENP and consumes the Passport web APIs.

Line framing and payload rules

MENP commands are CRLF-delimited ASCII lines. Commands may optionally carry a payload after the line header.

Public framing rules:

• line encoding: ASCII
• payload header format: command line followed by payload length information when a payload is present
• payload bytes follow immediately after the header line
• multiple commands may carry structured payloads depending on the service lane

This public reference intentionally avoids publishing every command-specific payload detail or private field shape.

Notification Server lane

The Notification Server owns authentication, roster sync, presence, and switchboard discovery.

Handshake

Typical flow:

1. Client sends a protocol/version command
2. Server replies with the accepted protocol and service banner
3. Client sends client-version information
4. Server replies with client acceptance

Heartbeat

• client may send a heartbeat command
• server replies with a heartbeat acknowledgement

Sign-in

Typical flow:

• client sends a sign-in request
• server replies with either success state or failure state
• successful sign-in returns account/session state needed by the client

This public reference intentionally does not document exact credential, token, or failure payload structure.

Contact sync

Client requests roster state with a sync command.

Server replies with zero or more contact rows, followed by a sync completion response.

Public contact state includes concepts such as:

• display name
• alias or preferred label
• block state
• presence state
• personal message
• optional social or profile-related data

Pending contact-request behavior may also be exposed to the client after sync, but exact wire details are intentionally omitted here.

Presence

Clients can update their current status and public-facing presence details.

Presence fanout informs other users when an account comes online, changes status, or goes offline.

Contact and privacy management

The Notification Server also mediates:

• contact additions
• contact approvals or declines
• contact removal
• block and unblock actions

These operations delegate persistence to Passport and then fan out updated roster or privacy state as needed.

Conversation routing

For direct or group conversations, the Notification Server advertises the current Switchboard endpoint and the session state required to join it.

Publicly useful concepts:

• session creation or reuse
• participant invitation
• incoming conversation notification

Private routing, trust, and session-proof details are intentionally not published in this README.

Switchboard lane

Switchboard handles actual conversation traffic after Notification Server routing.

Chat authentication

The normal conversation socket authenticates against the assigned conversation session before it can exchange traffic.

Media authentication

Media may use a separate authenticated conversation path so live voice and video traffic do not have to share the exact same path as normal chat messages.

Chat/session commands

Switchboard supports concepts such as:

• initial participant snapshot
• participant join
• typing notification relay
• chat payload relay
• participant leave
• heartbeat and acknowledgement

Media commands

Switchboard also supports current live media behavior for:

• audio
• video

Current public behavior notes:

• audio and video are relayed through Mocha services rather than direct peer-to-peer transport
• chat and media are intentionally separated so text traffic does not compete directly with live call traffic on the same path

Shared payload concepts worth knowing

The public-facing protocol surface includes concepts such as:

• account and login state
• contact and roster entries
• presence payloads
• pending contact requests
• activity alerts
• service-status data
• update manifest data

This public README intentionally avoids publishing the full internal model list or private implementation names behind those concepts.

Update manifests

Passport publishes update feeds that the Windows client can consume.

Public update concepts include:

• product
• channel
• version
• package identity
• package integrity data
• publish timestamp
• release notes
• whether an update is mandatory

The mandatory-update concept is part of the public client behavior, but the private update and deployment implementation remains outside the scope of this README.