Messenger protocol and support boundary
Messenger's native clients and the Aegis library expose different execution
paths. A shared VELI-* label is not evidence of wire compatibility or the same
signature/encryption construction. Neither a primitive catalog nor a TLS catalog
activates Messenger algorithms.
Native client source compatibility
The native iOS and Android Messenger source reviewed at revision
be7f621f457756f458eb692c439bd32595699fab registers three labels:
| Label | Session key establishment | Authentication path | Message encryption |
|---|---|---|---|
VELI-CLASSICAL-2025 |
X25519 | Ed25519 signed prekeys | Single AES-256-GCM in the Double Ratchet |
VELI-HYBRID-LITE |
ML-KEM-768 + X25519 when the provider and peer prekeys are available | Ed25519 signed prekeys | Single AES-256-GCM in the Double Ratchet |
VELI-DEFAULT-2025 |
ML-KEM-768 + X25519 when the provider and peer prekeys are available | Ed25519 signed prekeys | Single AES-256-GCM in the Double Ratchet |
The CompositeSignature and NestedAEAD building blocks are not the reviewed native message path. This source review does not prove that a specific installed or store-distributed client has those providers. Installed-client compatibility remains unknown until its build and runtime capabilities are checked. In particular, a suite name or policy ordinal is not proof that a given session used post-quantum cryptography.
Outbound and inbound are different decisions
Outbound initiation uses the policy preference, local implementation support, peer acceptance, provider/prekey availability, and the permitted policy floor. Do not infer that a server-listed label can be initiated by every client.
Inbound processing requires the supported envelope protocol, the accepted-inbound policy, authentication, and retained session/key material. Tagged protocol-v2 messages carry a suite label; legacy protocol-v1 messages are untagged and need separate compatibility handling. Changing the outbound preference does not change an established session or erase old inbound key requirements.
Axis's /api/messenger/suites is a public description, not a capability report
or activation endpoint. It exposes separate inbound/outbound prerequisites and
marks installed-client compatibility unknown. Existing fleet policy, minimum
floors, authorization, and the 30-day minimum retirement/spool runway remain in
force. Do not retire decrypt/verify support while queued messages still need it.
Standalone Aegis library
Aegis's registered library implementations include VeliDefault2025,
VeliHybridLite, and VeliClassical2025. Their typed APIs and tests describe their
own envelope formats; the default library suite includes nested AEAD and
composite signatures. The contextual support export labels this
aegis-core-library and does not claim native-client interoperability.
The TLS/primitive support reference has separate build applicability. Transport encryption, message end-to-end encryption, metadata privacy, and device storage are different properties and require separate verification. This document makes no deployment claim about PIR, OHTTP, QUIC, hardware-backed storage, or app-store release status.