Field Notes

source

Air secure messenger

StatusStableUpdatedStands on2 sourcesSupportsnotes

Air is a free end-to-end encrypted messaging app built on the Messaging Layer Security protocol, developed by Phoenix R&D and reachable at air.ms. This note records the vendor’s own homepage and privacy page as evidence for its claims. See the homepage saved copy and the privacy page saved copy.

What the source is

Two vendor-controlled marketing pages captured on 2026-07-21: the air.ms homepage and its linked privacy page. They are self-descriptions, not independent evaluations, so their security claims are promises to verify rather than audited findings. The pages carry no dated changelog, so treat the feature set as a snapshot of the capture date.

What Air claims

Air is presented as a consumer messenger that minimizes the personal data it holds. Account creation requires no phone number or email address, and a chosen username is described as unlinked to any identifying data. Messages and attachments are end-to-end encrypted by default using MLS, so that chat membership, message content, and delivery timing are described as unreadable to Air staff, server administrators, and third parties.

Two claims go beyond a default E2EE messenger. First, Air states that it does not retain metadata such as who talks to whom and when. Second, it encrypts push tokens, the technical identifiers a mobile device needs to receive push notifications, so that these identifiers cannot be combined with other data to identify a user. Push tokens are a recognized metadata leak in mobile messengers, because delivering a notification normally routes a device identifier through Apple or Google infrastructure; encrypting them targets a real exposure that E2EE alone does not close.

Air describes itself as open-source, built on open standards, and designed, built, and hosted in the EU. It is not financed by advertising or investors; the privacy page attributes funding to grants from NLnet, the Open Technology Fund, the Prototype Fund, and the Sovereign Tech Fund. Distribution is invite-only: a new account requires an invite code from an existing user. The app targets Android and iOS, with desktop support described as forthcoming.

Provenance and maturity signals

Air is developed by Phoenix R&D, which the privacy page describes as a social-impact company that co-authored the MLS protocol now used by Apple, Cisco, Discord, and Google. That lineage is the strongest verifiable signal here, and it checks out against primary sources: Phoenix R&D’s Raphael Robert is a listed author of RFC 9420, and the company co-maintains OpenMLS, the Rust MLS implementation whose 2026 SRLabs security audit the page cites as evidence of a solid foundation. Air’s own initial architecture is described as audited in late 2024.

The homepage is candid that Air is early: it states plainly that the app is not fully featured and that not all advanced security measures are implemented yet. That admission matters for placement. Air currently offers an MLS foundation and a metadata-minimizing design, not the deployment history, post-quantum ratchets, or independent scrutiny of a mature messenger.

Limitations for reliance

The claims worth checking before relying on Air are exactly the ones the vendor cannot settle by asserting them:

  • Whether metadata is genuinely not retained, as distinct from not being sold, since a store-and-forward server still observes connection timing, message size, and network address at delivery.
  • Whether the shipped clients and server match the open-source repository at github.com/phnx-im/air, and whether reproducible builds let a user confirm it.
  • Which “advanced security measures” remain unimplemented, and whether the gaps affect the threat model a given user has.
  • Whether push-token encryption survives the constraints of Apple and Google notification delivery in practice.

Secure and decentralized communication stacks places Air against Signal, Session, SimpleX, and the MLS-based Marmot Protocol and White Noise stacks, where the recurring lesson is that the security unit is the complete deployed system, not the name of its protocol.

Built on 2 sources (2 external).

Working out connections…