Ntfyx
Ntfyx encryption: CLI, HTTPS push and hosted monitors
Protected Topic CLI and agent messages are encrypted on your devices. Public Topic names and content are readable by the service and anyone with the identifier. HTTPS push and My Monitor process plaintext inputs before encrypted delivery. Understand the boundary for each path.
Updated
The short answer
#For protected Topics, your CLI encrypts message content for each authorized receiver before sending it. The iPhone or Web Inbox verifies the sender and decrypts locally. Replies are signed and encrypted back to the original source and authorized receivers. Content private keys stay on those endpoints; the relay routes ciphertext.
HTTPS push and My Monitor use hosted senders
#The simple HTTPS push entry point receives the title and body over TLS. Ntfyx can process that plaintext before encrypting a standard notification for the authorized receiving devices. Its phone-created push key grants sending only to one configured Topic; it cannot read messages, manage your Inbox or receive agent replies.
My Monitor reads its public URL, expected rule and a bounded response to perform checks, then encrypts alerts. These hosted paths are not sender-to-phone end-to-end encryption. Protected Topic CLI and agent messages are encrypted on their sending device; public Topic content is visible to the service and anyone with its ID or link.
Follow one message and answer
#The phone is the management authority. Scanning a private, five-minute QR authorizes a particular source or browser for a protected Topic; knowing its identifier alone grants no access. Public Topics instead allow anyone with the identifier to read and send ordinary messages, without answers or Call.
The private QR authorizes the source after you name or choose a Topic on your phone. The iPhone authorizes each source and browser. The relay sees routing metadata, timing, sizes and request states, not the plaintext content. The Web receives only messages addressed to it after authorization.
- The phone binds authorization to the service origin, role and endpoint keys. It signs the Topic membership list. The CLI source and browser do not receive the phone management key.
- The source verifies the membership list, encrypts a separate copy for every authorized receiver, and signs the envelope including all recipient ciphertexts.
- The relay validates the envelope and routes stored ciphertext. APNs wakes or alerts the iPhone with a generic notification path; content is decrypted locally when keys are available.
- The receiver checks the sender and envelope before opening its copy. A browser sees newly addressed messages after it joins, not earlier phone history.
- The receiver signs and encrypts its answer bound to the original request. The relay accepts only the first valid answer while the request is pending.
- The source verifies the answer and request binding, then acquires the one-time consumption claim before continuing. An external side effect needs its own durable outcome and idempotency handling.
Who can see what?
#Encryption applies to content, not all service operation. The source that creates a message and any agent or model that already had that text are inside your workflow’s trust boundary.
| Participant | Content and access |
|---|---|
| Your CLI / agent computer | Sees the message it creates and replies addressed to it. An agent may separately send context to its configured model provider. |
| Ntfyx HTTPS entry point / monitor service | Can read HTTPS request content or monitor configuration and bounded responses before generating encrypted notifications. A hosted publisher knows the content it sends. |
| Authorized iPhone / browser | Decrypts its addressed messages and replies. Device previews or browser extensions can expose content after decryption. |
| Ntfyx relay and gateway | Process ciphertext, opaque routing IDs, event kind, timestamps, sizes, request states and delivery information. They do not receive content private keys. Public Topic names and messages are readable by the service; a Topic API name is metadata, so protected clients upload a fixed label and retain the real label locally. |
| Apple push service | Handles notification delivery and device-token metadata. Ntfyx message plaintext is not submitted as the APNs title or body. |
| A newly authorized browser | Has independent receiver keys for newly addressed content. It does not gain the phone management root or earlier encrypted history. |
Cryptography and protocol scope
#Protocol v1 uses HPKE with DHKEM(P-256, HKDF-SHA256), HKDF-SHA256 and AES-256-GCM. Separate P-256 ES256 signing keys authenticate compact JWS envelopes including the recipient ciphertexts. Clients verify the original signed bytes. These choices do not by themselves establish a secure system; membership checks, key handling, request binding and endpoint integrity also matter.
What Allow and revoke actually mean
#A verified Allow authorizes the original bound request once. A read-only result query, message acceptance, receipt or timeout is not authorization. If a claim or external operation has an unknown outcome, investigate before retrying. Revoking a source or browser removes future service access; it cannot delete screenshots, exported text or already-delivered local copies.
Recovery: three common failure cases
#Keep the encrypted recovery package and its separate recovery code in safe, separate places before changing phones. Apple purchase restoration restores the plan; it does not recreate cryptographic keys.
| Situation | Consequence / next step |
|---|---|
| Phone lost; valid package and code available | Use the documented recovery flow. Review old device and source access afterward. |
| Package available, but recovery code lost | Support cannot decrypt the package. A purchase receipt cannot replace the code. |
| Phone keys lost; no usable package and code | Support cannot recover old content. Starting a new Inbox does not decrypt old messages. |
| Browser storage cleared | Pair the browser again. Its old receiver identity and earlier history do not reappear automatically. |
Verification and remaining limits
#As of 30 September 2026, project protocol tests cover published RFC 9180 Base / PSK vectors, cross-language vectors, signature tampering and per-recipient decryption. Local relay tests cover signed replies and repeat-claim rejection. Real Claude and Codex host tests use the specific versions and modes listed in their guides; programmatic receivers in those tests do not establish phone or APNs delivery.
The public scripts and plugin configuration are inspectable; the application source and internal test logs are not published as an audit.
Report a security issue
#Independent security review has not yet been completed. Send findings privately to x@bagex.online, the operator contact. Include only the minimum diagnostic context. Never include real keys, pairing links, recovery codes, tokens or private message content.
Public Topics: send your first notification without pairing
#Anyone with an existing public Topic ID or link can read and send without an account, pairing or key. The name and messages are readable by the service and anyone with the link; keep passwords, private logs and approval requests out of it. Public messages support text, Markdown and lightweight rich content, without answers, approvals or Call reminders.
Use a protected Topic for private messages, authenticated senders or signed answers.