Private by design.
Specific about limits.

WHAT IS STORED

Enough to deliver and recover.

Ordinary channels store notification events, structured metadata, delivery results, registered-device metadata, deduplication records, and interactive phone responses. End-to-end encrypted channels store routing metadata and separate ciphertext for each recipient device. Event and response retention is bounded.

Android keeps an app-private inbox. Sensitive events can enforce an absolute expiry or a timer that starts when the detail is opened. Authenticated purge commands remove matching channel history from participating phones when they reconnect.

DELIVERY PARTNERS

Where third parties fit.

Public HTTPS traffic passes through Cloudflare. Ordinary Android delivery can place notification content in a Firebase Cloud Messaging payload. Opaque and end-to-end encrypted modes send Firebase a generic wake-up instead.

Firebase is delivery transport, not Pushify's event-history database. Cloudflare, Firebase, and Pushify still see connection and routing metadata even when the content is end-to-end encrypted.

ENCRYPTION BOUNDARY

Each channel states its boundary.

direct_fcm channels use HTTPS but remain readable by the Pushify server and delivery path. opaque_fcm hides content from the Firebase notification payload but not from Pushify. A prepared e2ee_required channel uses official libsignal sessions and stores only per-device ciphertext plus the metadata needed to route it.

No channel migrates automatically. Activation requires a readiness check and an explicit administrative action. Pushify fails closed instead of falling back to plaintext.

The server currently supplies the device directory. Strong resistance to a malicious directory requires the separately reviewed verified-roster design, which is not claimed today. Encryption also cannot prevent screenshots, an unlocked endpoint, malware, or a recipient copying content after decryption.

CREDENTIALS

Credentials stay off the page.

Every private API route requires a database-backed bearer credential or protected phone session. Each principal is limited by capability, immutable channel ID, and event type. A publisher can read answers to its own events without gaining access to every publisher's responses.

Credentials must remain in server-side environment variables or protected configuration. They should never appear in URLs, frontend JavaScript, notification payloads, screenshots, or logs.

APPLICATION CONTROLS

Defense is layered.

• Strict JSON, URL, payload-size, action, and response validation
• Separate client-address and credential rate limits
• Connection limits for event and response streams
• Argon2id password hashing, strict browser cookies, CSRF checks, and login throttling
• Constant-time bearer-token and browser-session verification
• Exact grant checks for publish, Firebase recipients, history, streams, and phone responses
• Event deduplication scoped to the authenticated publisher
• Logs designed to omit bearer tokens and notification bodies

YOUR PART

Privacy is shared work.

Use a separate scoped token for each service, keep payloads proportionate, avoid sensitive data when a short status is enough, validate listener fields before using them, and rotate a credential if you suspect exposure.