Delivery, mailboxes, and push

Relay owns one durable mailbox for each device and mailbox generation. A send is durable only after the destination mailbox accepts the encrypted envelope or shared-body reference. Pull and acknowledgment remove accepted work through the same device authority.

Delivery units

One delivery unit is one accepted encrypted envelope or shared-body reference for one destination device. An exact retry with the same stable operation identifier does not charge twice.

A direct message to one account with two destination devices uses two delivery units. A group send uses approximately one unit for each destination device that accepts its shared-body reference. The direct encrypted-envelope limit is 256 KiB.

Mailbox behavior

Each device mailbox has a 3,000-message working ceiling. At the maximum envelope size, that ceiling is 786,432,000 bytes. This is 78.6432% of the Free production storage allowance before other ciphertext.

Relay never silently evicts a live message to make space. A full mailbox still permits pull, acknowledgment, expiry, deletion, and revocation. A new direct send receives a typed MAILBOX_FULL refusal and is not charged.

Push and notification profiles

Expo, APNs, FCM, and Web Push carry best-effort wakes. Provider payloads contain no message plaintext, ciphertext, sender or recipient identity, device or message identifier, group or conversation identifier, attachment reference, or receipt state. A wake tells the SDK to authenticate, pull all pending mailbox work, process each envelope, and acknowledge accepted work.

Push providers can lose, delay, duplicate, or reorder a best-effort wake. Delivery correctness therefore depends on mailbox pull, not on a push provider. Relay removes an invalid provider token after the provider returns its terminal invalid-token result.

The device registers one profile that the project allows:

nse-filtering stays unavailable until Apple approves the filtering entitlement and a signed physical-device build proves extension execution and suppression. The entitlement does not improve APNs transport or guarantee execution. A Notification Service Extension does not require that entitlement when it only modifies visible content.

Configure iOS

Use the CLI after the first acknowledged encrypted message:

oe notifications setup ios --profile background-only
oe notifications setup ios --profile visible-alert
oe notifications add-nse
oe notifications verify ios

Expo applications need a development or native build. Expo Go cannot receive this remote-push configuration or contain OpenE2EE's extension. Expo CNG uses a generated Apple target. Bare React Native uses the same generated, generic Swift source and an exact Xcode target handoff.

The generated extension has a timeout-safe generic fallback. It does not receive App Group or Keychain access by default and does not decrypt a preview. Use oe notifications verify ios --app-bundle PATH to inspect a signed build. A Simulator build proves target generation and compilation, not physical-device execution, locked-device behavior, or Apple-approved filtering.