Notifai Private Alpha Privacy Policy
Read this before using the Alpha: This policy describes the code currently checked in for the Private Alpha, including its limitations. It does not turn planned features into promises. Email one-time-code authentication, account access control, and self-service deletion are implemented locally; external use still waits on live email/deletion acceptance, production verification, provider review, and App Store/TestFlight gates.
1. What Notifai does
Notifai relays notifications from a machine or agent to a selected iPhone or Mac companion. The service keeps enough account, pairing, device, request, delivery, and reply information to authenticate the parties, route a notification, show local history, and report delivery evidence.
The canonical policy URL is /privacy on the same service origin as the dashboard and companion configuration. The current configured origin is https://notifai.fly.dev/privacy; a deployment must verify that URL before it is used in a release or store submission.
2. Data the current build processes
Examples below describe the fields used by the current implementation. A notification is user content even when it was generated by an agent. We do not sell this data or use it for advertising.
| Area | Examples | Why it is needed |
|---|---|---|
| Account | Supabase auth user ID, email address, account ID, creation time. | Create and identify an account, authenticate requests, and scope data to the account. |
| Authentication and sessions | Email one-time-code requests; Supabase-managed authentication records; browser session state; iPhone and Mac access/refresh tokens and expiry in the shared OS Keychain. | Create or sign in to an account, keep a signed-in session, and authorize the dashboard and companions. The Notifai server validates access tokens; it does not receive a password. |
| Machine and pairing | Machine name, machine credential hash, pairing code and polling-verifier hashes, pairing status, and pairing timestamps. | Pair an authorized sending machine with an account. Raw machine credentials and raw polling verifiers are not stored by the server. |
| Device and companion | Installation ID, platform, display name, app version, notification permission state, alert setting, enabled state, last-seen time, and APNs registration data. | Register a companion, choose delivery targets, and send a notification to the right installation. APNs tokens are hashed for lookup and encrypted for use. |
| Project | Project identifier, display name, settings, last-seen time, and a reference to a custom avatar. | Identify which project sent a notification and display its avatar or generated project image. |
| Notification | Request and delivery IDs, idempotency key, event name, project and target snapshots, title, subtitle, body, reply choices, optional detail, accepted/reply deadlines, and lifecycle timestamps. | Deduplicate, route, present, answer, and report delivery of a requested notification. |
| Media | Uploaded image bytes, private storage key, media type, size, checksum, account, status, and expiry. | Deliver an attachment or project avatar. Media is stored in a private bucket and accessed with short-lived signed URLs. |
| Replies | Reply text, selected choice ID, source, client reply ID, request/delivery/device/account links, and timestamps. | Send an answer back to the originating notification and prevent duplicate replies. |
| Evidence and operations | Delivery state, attempts, provider status/reason/ID, evidence stage and source, request/installation/registration IDs, timestamps, and service error or request metadata. | Operate the queue, diagnose delivery, prevent abuse, and show delivery evidence. Evidence rows intentionally do not contain notification body or media. |
| On-device companion data | Local notification history, title/subtitle/body, cached detail and images, project avatars, reply history, reply outbox, pending replies, installation/device IDs, and local session material. | Show the inbox offline or later, render a notification, and retry a reply. This data is held in the iPhone or Mac app group and OS Keychain, not only on the server. |
3. Purposes and use
We use the data above only to provide and protect the notification relay: account authentication; machine pairing; device registration; notification routing and presentation; media delivery; reply handling; delivery evidence; deduplication, expiry, abuse prevention, troubleshooting, and service operation.
The current code has no advertising SDK, cross-app or cross-site tracking, marketing program, analytics service, crash-reporting service, or Sentry integration. We do not use notification content to advertise, profile, or train a model.
4. Retention in the current implementation
These are implementation observations, not a promise that a provider will retain data for exactly these periods. Scheduled cleanup runs periodically, so a sweep can occur after the stated threshold.
| Data | Current behavior |
|---|---|
| Notification content and reply text on the server | For accepted requests, the hourly retention sweep runs at approximately 72 hours. It replaces the request payload with a purge marker and blanks reply bodies. Request, reply, delivery, and evidence metadata remains. |
| Uploaded media | Normally expires about 48 hours after upload and is then deleted from private storage. A signed media URL lasts about 1 hour. A selected custom project avatar is currently pinned for approximately 10 years; replacing or clearing it returns the old media to normal expiry. |
| Account, machine, device, project, delivery, and evidence metadata | No fixed automatic deletion period applies while an account remains open. Self-service account deletion removes the account and its owned machine, pairing, device, provider-registration, project, media-metadata, notification, delivery, evidence, reply, and access-grant rows. References where the deleted account acted on another account's grant are anonymized rather than deleting the other account's record. |
| Deletion recovery record | Notifai retains a one-way digest derived from the authentication subject, deletion status, attempt count, timestamps, and generic failure stage/code without a scheduled expiry. The record briefly holds the internal account ID until the database snapshot/purge and holds an encrypted authentication subject until provider cleanup completes. Temporary cleanup ledgers hold only Notification Request IDs and media storage key/upload-expiry pairs until queue and storage cleanup succeeds. Those recoverable identifiers and ledgers are erased on completion; no notification/reply content or completed account ID remains. |
| Browser and companion authentication | Sessions normally remain until token expiry, sign-out, revocation, or OS/app removal. Account deletion hard-deletes the Supabase Auth identity and immediately blocks existing tokens at the Notifai server. The initiating client clears its local session when deletion completes; another offline client clears when it next contacts the server and learns the account was deleted. |
| iPhone and Mac local history | History is capped at 500 entries and reply-origin history at 500 entries, but there is no time-based purge or separate clear-history control. A Companion App clears its local history, cached detail, attachments, project avatars, and OS notifications as soon as the server confirms deletion started, then blocks late pushes from recreating that history until a fresh account passes the service access check. Another offline Companion can retain its physical-device copy until it next contacts the service, the app is uninstalled, or the OS removes its data. |
| Local reply delivery | The reply outbox and pending queue are each capped at 50 items. Retries are bounded for a given failure, while transient pending items remain until a later flush or local cleanup. A Companion App that starts account deletion clears and closes both queues until a fresh account passes the service access check. |
| Service and provider logs | Operational logs and platform/provider records may contain request IDs, statuses, timestamps, or errors. Their retention is controlled by the hosting and platform providers and is not specified or guaranteed by this build. |
5. Lock-screen previews and notification content
Push payloads currently include the notification title, subtitle, and body in the Apple alert payload. Apple APNs transports that payload to the selected Apple device, and iOS or macOS may show it on a lock screen, notification banner, or notification center according to the user's OS settings. Notifai does not redact, encrypt end-to-end, or guarantee that a preview is hidden.
Never send passwords, API keys, access tokens, private keys, recovery codes, financial credentials, health information, or other highly sensitive work or personal content through a notification. This prohibition applies to titles, subtitles, bodies, details, images, replies, and project names. Use a notification as a prompt to open a properly secured system, not as a secret container.
6. Security limits
The implementation uses HTTPS/TLS, hashes machine credentials, protects APNs registration data for server use, keeps media in private storage, and uses short-lived signed media URLs. These measures are not a security certification or a guarantee of a particular provider's controls. Notification content and account data are not end-to-end encrypted between the sender and companion; transport, database, storage, operating-system, and provider encryption do not change that limitation.
7. Service providers
The current service depends on these providers for the stated functions:
- Supabase: authentication, PostgreSQL database, and private object storage for the service's account, operational, notification, reply, and media records.
- Fly.io: hosting for the web and worker processes that receive requests, run delivery and retention jobs, and serve the dashboard.
- Apple: APNs transports push payloads to Apple devices; Apple's operating systems control local presentation. TestFlight/App Store Connect distribute pre-release builds when the operator enables that external release.
No additional analytics, advertising, crash-reporting, or model-training subprocessor is enabled in the checked-in application. Provider terms, locations, operational logs, and provider retention are outside Notifai's control; this policy does not promise a region, deletion SLA, or provider security certification.
8. Deletion and contact in this Alpha build
Self-service account deletion is available in the dashboard, iPhone app, and Mac app, including for an authenticated account without an active plan. Open account settings, choose Delete account, and type DELETE. The server independently requires an explicit confirmation and authentication within the preceding ten minutes. Signing out, uninstalling an app, removing a device, or letting a pairing expire is not account deletion.
Deletion first checks account-level safety invariants and creates a credential barrier. A sole active platform owner must transfer ownership before deletion; that conflict changes nothing. Once accepted, deletion snapshots the request IDs and media coordinates needed for remote cleanup and removes or anonymizes the account-owned PostgreSQL records described above in one transaction. This immediately removes sending machines and push registrations and prevents an in-flight mutation from adding new account data. It then cancels queued work, deletes private media objects, and hard-deletes the Supabase Auth identity. A background worker retries an observable queue, storage, identity, or database failure. If an unexpired signed upload grant could recreate an object, the worker waits until that grant expires and repeats storage cleanup before erasing the temporary cleanup ledger; the client shows that deletion is still in progress.
The initiating browser clears its local session after the server reports completion. The initiating Companion App clears its content, reply queues, device identifiers, and OS notifications as soon as the server confirms deletion started; it keeps only the session needed to retry until completion or local sign-out. Notifai cannot erase data from another physical device while it is offline; that Companion's server credentials are already unusable, and it clears its local copy if its still-valid session next reaches Notifai and learns the account was deleted. If the deleted authentication identity can no longer refresh that offline session, uninstalling the app or OS data removal is the fallback for that device copy. Operational hosting, authentication, storage, and Apple platform logs remain subject to provider retention and are not covered by a guaranteed deletion time.
The current build links to the Private Alpha support page at /support. Invited testers send feedback through TestFlight or the release-owned Feedback Email shown there. There is no public support queue or invented personal contact embedded in the app; the release owner must verify that address in App Store Connect before external testing.
9. Current release gates and policy updates
Before an external Private Alpha release, the operator must verify transactional email and one-time-code authentication against live providers, the deletion flow against live Auth, Storage, database, and worker providers, production behavior, deployment of the /privacy and /support routes, the provider roster, and the App Store/TestFlight review path. Once those gates pass, this policy must record any measured provider deletion behavior and re-check the deployed URLs and providers.
Questions or changes to this policy should go through the verified TestFlight feedback address published by the Alpha operator. The repository deliberately does not publish a personal address.