Privacy policy · Pod Monster

The short version:

Pod Monster's servers store the shows you follow, your playback positions, sort order, and the devices using your library.
Railway hosts the server, Sentry receives crash reports, and Expo and Apple deliver push notifications. The app also contacts podcast host servers directly, and Pod Monster's servers ask Podcast Index when you search. For a boost, the app talks to your wallet through the relays in your wallet connection. Your wallet pays each recipient, and the app can ask a recipient's payment host for an invoice. When you open a podcast's funding link, the app opens the page of the funding service that the podcast names.
Pod Monster shows no ads, sells no data, and tracks nobody across other apps or websites.
The device that started the library, the host, can delete the whole library in Settings. If you no longer have access, you can ask by email for deletion once no device has opened the library for 30 days.

Who we are

One person, Adam Drago, builds and maintains the Pod Monster app and this site through Pod Monster LLC, a Pennsylvania company. On this page, "we" and "Pod Monster" mean Pod Monster LLC. The company decides what data the app and the site collect and why, so it is the controller of that data under European and United Kingdom law.

For support or privacy requests, email [email protected]. You can also write to Pod Monster LLC at 1604 Philadelphia Pike PMB 331, Wilmington, DE 19809, United States.

Pod Monster has appointed no data protection officer.

What we collect and why

The table below gives every kind of data Pod Monster handles, where it comes from, who receives it, why, the lawful basis, and how long it is kept.

A lawful basis is the legal reason for processing data under European and United Kingdom law. Pod Monster relies on contract to store your library and provide search, chapters, transcripts, and imports. It also relies on contract for boosts and funding links: the boost record, the wallet requests, any invoice request, the lookups that find the recipients of a boost, and the request that opens a funding link. It relies on legitimate interest for crash and performance reports, server error events, rate limits that use IP addresses, and support email, to keep the app working, prevent abuse, and answer you. It relies on consent for push notifications, chat, and the waitlist. You can withdraw consent at any time.

Data and where it comes from	Why	Who receives it	Lawful basis	How long it is kept
Device ID The app makes it on first launch and keeps it in the device Keychain.	Why: It ties this installation to your library.	Who receives it: Pod Monster's servers.	Lawful basis: Contract.	How long it is kept: As long as the library. Deleting the library replaces it.
Your library: the shows you follow, your playback positions, and your sort order The app, as you use it.	Why: Sync between the devices on your library.	Who receives it: Pod Monster's servers.	Lawful basis: Contract.	How long it is kept: Until 90 days after the last device leaves.
Device model name and last seen time The app, on each request to the server.	Why: Settings shows which devices are on your library.	Who receives it: Pod Monster's servers.	Lawful basis: Contract.	How long it is kept: As long as the library.
Library ID, library code, and link token The server makes them for your library.	Why: Sync, a new device joining, recovery, and email deletion requests.	Who receives it: Pod Monster's servers, which store only a hash of the code and the token.	Lawful basis: Contract.	How long it is kept: As long as the library.
Link offer: the Library ID, the link token, and an expiry time The app, once you have a library.	Why: Your other devices can offer to join this library.	Who receives it: Apple iCloud key-value storage, under your Apple Account.	Lawful basis: Contract.	How long it is kept: Until the device leaves or deletes the library.
Push token and alert details: feed address, episode title, and episode ID The app, after you allow notifications at the iOS prompt.	Why: New episode alerts and live alerts.	Who receives it: Pod Monster's servers, Expo, and Apple.	Lawful basis: Consent, given at the iOS prompt.	How long it is kept: As long as the library, or until the token stops working.
IP address and browser or app identifier on every request to the server Your device, on every network request.	Why: Rate limits and abuse protection.	Who receives it: Pod Monster's servers, in memory to count requests, and Railway, in its request logs.	Lawful basis: Legitimate interest.	How long it is kept: Up to 30 days in the Railway request logs.
IP addresses sent to podcast hosts and chat servers Your phone, for audio, artwork, and chat. The server sends its own address for chapters and transcripts.	Why: Playback, chapters, transcripts, and chat.	Who receives it: The podcast's host, and the chat server the podcast names.	Lawful basis: Contract.	How long it is kept: Pod Monster never holds it. Each service has its own policy.
Chapter, transcript, and chapter image requests The app. A chapter or transcript request includes the episode address and the Device ID. A chapter image request carries no Device ID.	Why: To show chapters and transcripts.	Who receives it: Pod Monster's servers. The fetched file is cached with no device attached to it.	Lawful basis: Contract.	How long it is kept: For the request only. The rate limiter holds the Device ID and the IP address in memory for one minute, and they are gone when the server restarts. When a device hits the limit, a log line records a keyed hash of the Device ID and of the IP address, or of the IP address alone for a chapter image, and Railway keeps that log for up to 30 days. The key is random, stays in the server's memory, and changes at each server restart or deploy, so a hash matches only within one server run.
OPML file text, or the show list from an Apple Podcasts import You, through the document picker or the import Shortcut.	Why: To add the shows in the file to your library.	Who receives it: Pod Monster's servers, for the request only.	Lawful basis: Contract.	How long it is kept: The file is not stored. Only the shows you now follow remain.
Search term The app, when you search for a podcast. The request includes the Device ID.	Why: To find podcasts.	Who receives it: Pod Monster's servers. They then ask Podcast Index, which receives the search term with no Device ID and no IP address of your device.	Lawful basis: Contract.	How long it is kept: For the request only. Pod Monster's servers never save the search term or write it to a log. The rate limiter holds the Device ID and the IP address in memory for one minute. When a device hits the limit, a log line records a keyed hash of the Device ID and of the IP address, and Railway keeps that log for up to 30 days. The key changes at each server restart or deploy, so a hash matches only within one server run.
Chat nickname You, when you join a room.	Why: It is the name the room sees.	Who receives it: Apple iCloud key-value storage, the chat server the podcast names, and everyone in the room.	Lawful basis: Consent, given when you join a room.	How long it is kept: Pod Monster never holds it.
Boost record: your sender name, your message, the amounts, the show title and the episode or livestream title, the feed identifier and the episode or livestream identifier, your position in the episode (a livestream boost sends no position), the app name and version, and two random IDs, one for the boost and one for each payment The app, when you send a boost. For an invoice payment, the record holds your message and sender name only when the payment host took them.	Why: To tell each recipient who sent the boost and for which episode or livestream.	Who receives it: Your wallet, with each payment, keysend or invoice. The wallet of each recipient paid by keysend, through your wallet.	Lawful basis: Contract.	How long it is kept: Pod Monster never holds it, and no Pod Monster server receives it. Your wallet can keep it under its own terms, and other apps you connect to that wallet with the history permission can read it. Alby Hub does not send the record of an invoice payment on. Other wallets can differ.
Wallet request: an encrypted request, the connection public key, the wallet public key, the time, and your IP address The app, each time it asks your wallet for something.	Why: To pair with your wallet, pay a boost, check the wallet and its payments, and show Boost History.	Who receives it: Each Nostr relay that your wallet connection names, up to four, and then your wallet. Your wallet chooses the relays.	Lawful basis: Contract.	How long it is kept: Pod Monster never holds it. Each relay and your wallet have their own policies.
Invoice request: the amount, a comment with the show title and your message, your sender name, and your IP address The app, straight from your phone. It pays a Lightning address by invoice when the address offers no keysend, when your wallet pays invoices only, or when you pay a failed keysend payment by invoice. The comment and the sender name go only when the host accepts them. At Send, the app truncates the comment to the host's limit. For a failed keysend payment, you edit the comment to fit, and the app does not truncate it.	Why: To pay a Lightning address that takes invoices.	Who receives it: The payment host that the LNURL-pay record of the address names. It can be a different company than the domain of the address.	Lawful basis: Contract.	How long it is kept: Pod Monster never holds it, and no Pod Monster server receives it.
Boost recipient lookups: a Lightning address from a podcast feed, or the identifiers and the address of another feed that lists recipients for it The app, when you open the boost sheet, and for a Lightning address after a keysend payment to it fails. The request includes the Device ID.	Why: To find the recipients of a boost.	Who receives it: Pod Monster's servers. They then ask Podcast Index, the host of the other feed, or the domain of the Lightning address, which receive no Device ID and no IP address of your device.	Lawful basis: Contract.	How long it is kept: For the request only. The rate limiter holds the Device ID and the IP address in memory for one minute. When a device hits the limit, a log line records a keyed hash of the Device ID and of the IP address, and Railway keeps that log for up to 30 days. The key changes at each server restart or deploy, so a hash matches only within one server run. The answer is cached for up to 24 hours with no device attached to it.
Funding link: the request to the funding page, your IP address, and anything you enter on that page The app, when you open a podcast's funding link. The page opens in an in-app browser.	Why: To open the podcast's donation page.	Who receives it: The funding service the podcast names. Pod Monster sends it no data of its own.	Lawful basis: Contract.	How long it is kept: Pod Monster never holds it, and does not know if you donate.
Support email: your address, your message, and any Library ID you quote You, when you write to [email protected].	Why: To answer your request.	Who receives it: Google, in the United States.	Lawful basis: Legitimate interest.	How long it is kept: 90 days after the thread closes, or sooner if you ask.
Waitlist email address and the time you sent it You, through the form on podmonster.app.	Why: To invite you to test the app before release, and to tell you once when it is released.	Who receives it: The Pod Monster site database, in the United States, and Apple, when Pod Monster adds you as a TestFlight tester. Cloudflare checks that a person, not a program, sent the form. Pod Monster never sends it your email address.	Lawful basis: Consent.	How long it is kept: Until you ask for deletion, or until Pod Monster becomes publicly available.
Turnstile check: browser signals and a Cloudflare cookie Your browser, once you start to use the waitlist form.	Why: To tell a person from a program.	Who receives it: Cloudflare.	Lawful basis: Legitimate interest.	How long it is kept: Pod Monster never holds it. Cloudflare's addendum states its own period.
App crash and performance reports The app, when it crashes, runs slowly, or a boost fails. A report has the device model, the OS and app versions, a trace, a random per-install identifier that is not the Device ID, and each request's method and status, but not its address. The trace of a request outside Pod Monster also leaves out its host. The screen trail in a report names screens only, with no show, episode, or feed address, and a tap on a boost row records only the kind of row. For a failed boost, a report adds the stage, the error code, and the counts of payments by state. If an invoice payment of a failed keysend payment also fails, another report adds the same facts and marks it as an invoice retry. A report about a boost never carries a recipient, an amount, your message, your sender name, the show, the episode, the payment host, or the wallet connection.	Why: To find and fix defects in the app.	Who receives it: Sentry, in the United States.	Lawful basis: Legitimate interest.	How long it is kept: 30 days.
Server error and trace events Pod Monster's servers, when a request fails or runs slowly. An event has the procedure name, the error message, the stack, and the timing, but no request headers, cookies, query strings, or bodies.	Why: To find and fix faults on the server.	Who receives it: Sentry, in the United States.	Lawful basis: Legitimate interest.	How long it is kept: 30 days.

Some data needs no lawful basis, because Pod Monster does not process it, or because it is not about you:

Your preferences for playback, appearance, and auto-join, and your boost sender name, are in Apple iCloud key-value storage under your Apple Account. They follow you between your own devices until you clear them. A recipient of a boost sees your sender name if their payment host supports it. The name can be up to 64 characters.
Downloads and the chapter and transcript caches stay on your device and out of the device backup. They remain until the app clears them or you remove them.
Your wallet connection stays in the Keychain of the device you paired it on. It does not sync, a backup does not carry it to another device, and no Pod Monster server receives it. If you remove the app, iOS keeps the connection on the device, and a new install of Pod Monster deletes it before any use. The app suggests that you scan the QR code, because a copied connection string can stay on your Mac or in a clipboard manager, and Universal Clipboard can carry it to your other devices. A paste reads the clipboard once, and after you pair with a paste, the app clears the clipboard.
When you scan to pair a wallet, the camera reads only the QR code, and only on your device. When you pick an image in Files instead, the app reads the code on your device, then deletes its copy of the image. The app keeps no image and sends none.
When you open Boost History in Settings > Boosts, the app reads the outgoing payments from your wallet so it can show your boosts. It needs the optional "Read transaction history" permission, which lets the connection read every payment in your wallet. The request goes through the relays in your wallet connection, like every wallet request. Your wallet returns payments from every app that uses it, and Boost History shows only boosts. The app holds them in memory only while Boost History is open, and never saves them to storage, logs, crash reports, or a server.
Before each boost, the Send Boost button asks for Face ID, Touch ID, or the device passcode. Before an invoice payment of a failed keysend payment, the Pay Invoice button asks again. If you cancel the check, nothing is sent. The app receives only a pass or a fail, and no face or fingerprint data.
A place name and its coordinates come from a podcast feed and describe the show, not you. The server asks Wikimedia and OpenStreetMap about the place, for the request only. When you tap a place, your phone opens Apple Maps or Google Maps.

Who receives your data

Companies that work for Pod Monster

Each one handles data on Pod Monster's instructions, under a written contract that holds it to protection at least as strong as this policy describes.

Railway hosts Pod Monster's servers, this site, and the databases behind both.
Google holds the support mailbox in Google Workspace.
Cloudflare Turnstile checks that a person, not a program, sent a waitlist form.
Sentry receives the crash reports from the app and the error events from the server.
Expo delivers push notifications.
Apple delivers those notifications to your device and holds the iCloud key-value data under your Apple Account. It also receives a waitlist address when Pod Monster adds that person as a TestFlight tester.

Services with their own privacy policies

These services are not Pod Monster's contractors. Each handles requests under its own privacy policy.

General

The podcast host serves the audio, the artwork, the chapters, and the transcript for a show.

Search

Podcast Index is used for search.

Live and Chat

The chat server a podcast names hosts the room you join and receives your nickname.

Places

Apple Maps or Google Maps opens when you tap a place in a show.
The Pod Monster server asks Wikimedia and OpenStreetMap about place names. Those requests carry no personal data.

Boosts

Your wallet receives each wallet request through the Nostr relays in your wallet connection. Your wallet can keep the record of each boost payment.
Each recipient's wallet receives its payment, and the boost record when the payment goes by keysend.
For a Lightning address, the payment host named in the address's LNURL-pay record receives an invoice request straight from your phone.
The Pod Monster server asks Podcast Index, the host of another feed, and the domain of a Lightning address to find the recipients of a boost. Those requests carry no Device ID and no IP address of your device.

Funding links

The funding service a podcast names runs the donation page that a funding link opens. A donation there is between you and that service, under its terms, and Pod Monster cannot refund it.

A podcast host and a chat server are run by the podcast, not by Pod Monster. Pod Monster makes no promise about either service.

The podcast, not Pod Monster, chooses the recipients of a boost and the funding service. A boost goes from a wallet you own to the recipients the podcast names in its feed, and Pod Monster does not check them. The boosts page shows where the sats go.

Where your data is kept

Pod Monster runs in the United States, and everything on the server is processed there. Pod Monster LLC is the controller of that data, and it applies the GDPR to people in the European Economic Area and the UK GDPR to people in the United Kingdom. It collects the data from your device directly, rather than receiving it from anyone in Europe.

When Pod Monster passes data to a company that works for it, that company is in the United States too. Each one holds a certification under the EU-US Data Privacy Framework, or a data processing agreement with the standard contractual clauses, or both. This covers Railway, Cloudflare, Sentry, Expo, Google, and Apple.

Pod Monster LLC itself holds no such certification. It relies on those agreements. Ask at [email protected] for the safeguard that covers a particular company.

How long we keep it

A crash or performance report is kept for 30 days and then deleted.

Pod Monster keeps a library with at least one registered device until you delete it in the app or by email. Removing the app does not unregister the device: its identifier survives a reinstall. A library can therefore stay registered after you stop using it. To remove a device, leave the library in Settings before deleting the app.

When the last device leaves a library, the library is kept for 90 days and then deleted. The wait gives you time to rejoin with a code you wrote down.

Pod Monster keeps a waitlist email address until you ask for deletion or until it closes the waitlist. It will close the waitlist and delete every address on it when Pod Monster becomes publicly available.

The app saves no record of a boost, and no Pod Monster server receives one. The app remembers the result of each boost only until you quit the app. So that you can pay a failed keysend payment by invoice, the app also keeps the Lightning address, your message, and your sender name in memory. It deletes them when that payment can no longer go by invoice, when you pay it, or when you quit the app. Your wallet history is the record. Boost History keeps what it reads in memory only while it is open.

Your choices and deletion

Delete your library in the app

Open Settings in Pod Monster and use "Delete this library". That removes the shows, the playback positions, the sort order, and the device list from the server for every device on the library, not only for the device that asked. The app then starts a new, empty library under a new Library ID.

A device that joined a library with a code cannot delete it. That device leaves the library in Settings instead. This removes only that device; the library stays available to everyone else. Only a host device, meaning a device that started the library, can delete it.

Delete your library by email

If you no longer have a device that can open the library, write to [email protected] and quote the Library ID from Settings. Pod Monster holds no name or email address for a library. It uses the Library ID to identify the library and as proof for an email deletion request. Copy the ID from Settings while you still have access.

Pod Monster acts on an email request only when no device has opened the library in the last 30 days. If a device is still using it, Pod Monster does not delete it by email. The reply says so, and it points you to "Delete this library" in Settings on a host device. Either way you get an answer within 30 days.

Anyone who reads the Library ID from a device on the library, or from a link offer stored under an Apple Account, can ask Pod Monster to delete the library. Pod Monster acts on that request only if no device has opened the library in the last 30 days.

Everything else Pod Monster holds

A crash report contains a random per-install identifier but no Library ID, so Pod Monster cannot match it to you.
A waitlist address is deleted when you ask.
A support thread is deleted on request or 90 days after the thread closes.
Railway's request logs expire after up to 30 days. Pod Monster cannot delete an individual entry from those logs.
Pod Monster holds no record of a boost: no amount, recipient, or message. The diagnostics of a failed boost are part of a crash report, as above. Pod Monster cannot delete what a recipient received through your wallet, or the record your wallet keeps. If a wallet is connected, "Delete this library" in Settings also offers "Delete and Disconnect Wallet". That option deletes the library, then the wallet connection on the device, and then clears your sender name on every device signed in to your Apple Account. Your wallet keeps the connection until you revoke it there.

Turning things off

Notifications. Open the iOS Settings app, find Pod Monster, and turn Notifications off. That withdraws the consent you gave at the prompt, and the new episode alerts and live alerts stop.
Chat. Leave the room from the room screen in the app, and your nickname stops appearing in it. Pod Monster does not run the chat server, and the app cannot send chat messages.
Boosts. On the device where you connected your wallet, tap Disconnect in Settings > Boosts to delete the wallet connection. Your wallet keeps the connection until you revoke it there, so revoke it in your wallet too. Removing the app does not revoke it either. Disconnect does not clear your sender name. You can clear it in Settings > Boosts. To turn off only Boost History, turn off "Read transaction history" for the Pod Monster connection in your wallet.
The waitlist. Write to [email protected] from the address you sent, or name that address in the message, and ask to come off it. The address is deleted.

Your rights

Wherever you live: Pod Monster sells no data, shares none for advertising, tracks nobody across other apps or websites, and makes no decision about you by automated means.

Pod Monster is not offering the app in the European Economic Area or the United Kingdom during its initial alpha. It will decide again after the alpha whether to offer the app there.

If you are in the European Economic Area or the United Kingdom, the GDPR and UK GDPR let you ask for a copy of your data, correction, deletion, restricted use, or a portable copy. You can object to processing based on legitimate interest. If processing is based on consent, you can withdraw it at any time without undoing earlier processing.

Send a request to [email protected]. Quote your Library ID if the request is about your library, because Pod Monster holds no name and no email address for one and cannot find it any other way. If Pod Monster cannot identify the library from your request, it will tell you and will not guess.

Pod Monster acts on a request for a copy, a correction, or a portable copy of a library under the same rule as an email deletion request: only when no device has opened the library in the last 30 days. If a device is still using it, the reply points you to the app, which shows everything the server holds for the library.

You can also complain to a supervisory authority. In the European Economic Area that is the data protection authority of the country you live in. In the United Kingdom it is the Information Commissioner's Office.

California

Under the California Consumer Privacy Act, Pod Monster sells no personal information and shares none for cross-context behavioral advertising. It does not track you across other apps or websites or make automated decisions about you. The categories it collects, why it collects them, and who receives them are listed above. You can ask for access, correction, or deletion at the same address.

Children

Pod Monster is for people who are 16 or older. The app is not directed at children, and Pod Monster does not knowingly collect data from anyone under 16.

Pod Monster holds no name, email address, or age for a library. A report without a Library ID therefore does not identify one. If you believe a library belongs to someone under 16, write to [email protected] and quote the Library ID from Settings on that device. Pod Monster then deletes the library, if no device has opened it in the last 30 days. If a device is still using it, the reply points you to "Delete this library" in Settings on a host device.

Pod Monster does not promise deletion based on a report alone.

The podmonster.app website

This site runs no analytics, sets no cookies of its own, and does not track you across other sites.

The site and the app do not change their behavior when a browser sends a Do Not Track signal, because neither one tracks you across other sites or apps.

The waitlist form on the home page stores the email address you type and the time you send it. Cloudflare Turnstile checks the form for automated submissions.

Turnstile loads only when you start to use the waitlist form. Once it loads, Turnstile reads technical signals from your browser, and it can set its own cookie to record that the check passed. Read Cloudflare's Cloudflare Turnstile Privacy Addendum for what it collects.

Railway hosts this site and the app's server in the same account, and it keeps request logs for up to 30 days. Those logs record the IP address, browser or app identifier, and requested path.

The app opens this policy, the terms of use, the support page, the library sync page, and the boosts page from podmonster.app. Opening any of them in the app sends a request to Railway, just as opening one in a browser does.

Security and breaches

The app uses no password, and no name or email address is attached to a library. Pod Monster's servers store the library code and the link token as a hash, not in readable form. The link offer in Apple iCloud key-value storage holds the link token in readable form, so your other devices can read it. The Device ID never appears on screen, because it is the credential the app uses to reach the server. Downloads and the caches on the device are kept out of the device backup. Every request between the app and Pod Monster's servers travels over HTTPS, so it is encrypted in transit.

Your wallet connection stays in the Keychain of the device you paired it on, and no Pod Monster server receives it. Each wallet request goes through the Nostr relays in the connection. Each relay sees the connection public key, the wallet public key, the time, and the IP address of each request. The request is encrypted, so the relay cannot read its content, such as the amount.

If a breach happens, Pod Monster can give notice in the following ways.

Post a notice on podmonster.app, the channel available to every library.
Send a push notification if notifications are on. A breach notice is a service message that Pod Monster sends under its legal duty to tell you, not under the alert consent. This does not reach every library.
Notify the supervisory authority, where the law requires it.

Pod Monster holds no email address for an app user unless that person has written to support, so it cannot email everyone, and there is no broadcast notification.

Changes to this policy

When this policy changes, Pod Monster posts the changed page, sets the "Updated" date at the top of it to the day of the change, and adds an entry at podmonster.app/changelog.

Contact

Email [email protected] with a question about this policy, a request about your data, or a complaint. You can also write to Pod Monster LLC at 1604 Philadelphia Pike PMB 331, Wilmington, DE 19809, United States.