Instant Messaging
The Demos SDK ships two instant-messaging client classes under theinstantMessaging namespace. Both use the same E2E encryption layer (ml-kem-aes for key encapsulation and AES-GCM, ml-dsa for the registration proof key), but they target different transports and delivery guarantees:
| Class | Default port | Transport | History | Offline delivery | Delivery acknowledgement | When to use |
|---|---|---|---|---|---|---|
L2PSMessagingPeer | 3006 | L2PS messaging server | Yes — history() API with pagination | Yes — server queues messages for offline peers | Yes — message_sent / message_queued frames | Production. L2PS-backed messaging with persistence and L2PS pipeline (mempool → batch → L1 proof → L1 finality). |
MessagingPeer | 3005 | Legacy signaling server | No | No | No | Transient relay-only messaging. Kept for backwards compatibility. |
L2PSMessagingPeer. Every code example below uses it unless explicitly labeled “legacy”.
Where to go next
What is the Instant Messaging Protocol?
The L2PS-backed protocol, plus how the legacy signaling-only path differs.
Architecture overview
Port 3005 vs port 3006, and the L2PS pipeline.
Quickstart
Connect, send, receive, and read history with
L2PSMessagingPeer.API reference
Method-by-method reference for both classes.
Message types
Wire-protocol message types for each class.
Encryption
The shared
ml-kem-aes E2E layer.FAQ
Common questions, including which class to pick.