Frequently Asked Questions
Everything you need to know about how Mera works, your privacy, and our plans, including what we haven't finished yet.
About Mera
Mera is an impact-first personal news assistant. There's no feed to scroll. It continuously scans thousands of sources and delivers the number of daily alerts you choose, each with a plain-language "Why this matters to you" explanation and a direct link to the original publisher. It's built to give back the 60–90 minutes a day most people lose filtering the news themselves.
There's no engagement farming and no infinite feed. Mera only alerts you when something genuinely affects you, instead of maximising the time you spend inside the app. In fact, Mera succeeds when you spend less time reading news, not more.
Mera monitors thousands of publications worldwide across many languages. Articles are translated and matched across languages, so a local-language report and an English report about the same event are grouped together. The full list of sources is publicly available on GitHub for anyone to inspect.
No. Mera only shows you headlines and its reasoning for why a story matters. The actual reading happens at the original publisher. Rather than replacing journalism, Mera routes traffic and attention back to the newsrooms that produced it.
Privacy
No. Your profile and the personal facts behind it never leave your device. What we send instead is a short list of broad topic phrases (things like “Amsterdam housing policy”) plus optionally a country. That is the entire payload: no profile, no personal facts, no reading history, and nothing about which articles you opened. We call this design the Mera Protocol.
Never. There are no ads and we never sell your data. You're the customer, not the product being sold to advertisers.
Most of it you can check rather than take on faith. The app's code is source-available and we publish network-traffic analysis guides, so you can see for yourself exactly what leaves your device: broad topic phrases and nothing more. Our backend isn't published yet, and that's the honest gap. We're still building this: we're moving every service that touches your data into a source-available repository (see Transparency & roadmap below). Until it's ready, one thing comes down to trust: that we keep no record linking you to the topics you send. We built it so that record cannot exist: topics are stored in a shared cache keyed by the text itself, with no user ID attached. And the uncomfortable part, said plainly: publishing server source proves what the code does, never which code a server is actually running. That's true of everyone who publishes a backend, Signal included.
You can delete your account in the app. Your phone's sign-in record is removed right away, so the deletion can't be undone. You can also use the data-deletion page on this website with your Support ID, which is at the bottom of Settings in the app, and we handle that within one month, as the law requires. Deleting your account doesn't cancel an App Store or Google Play subscription, so cancel that in the store. Your profile lives on your device, so deleting the app removes it, but deleting the app on its own doesn't delete your account.
No. Mera never asks for an email, a phone number or a password. Your phone signs you in. On iPhone, Apple's App Attest confirms each sign-in comes from the real Mera app on a real iPhone, and our servers send nothing to Apple. On Android, your phone's Android ID is sent to our servers, which keep only a sign-in record made from it: a one-way hash that can't be turned back into the ID. Google Play Integrity also checks each sign-in, and we check the result without keeping it. We use all this only to sign you in, to make sure sign-ins come from the real app on a real phone, and to limit how fast accounts can be created from one connection. Your account lives on that phone. If you lose the phone, reset an Android phone to factory settings, or reinstall the app on an iPhone, you start with a new account. Reinstalling on Android keeps it. See “What happens when I get a new phone?” below for how your data and your plan come with you. If an account has no sign-in and no use of the app for 12 months, we delete it, unless it has an active paid plan. When you delete your account, the sign-in record is removed right away, so that deletion can't be undone, and nothing about your phone is kept.
Using Mera
You decide: you can configure up to 24 alert opportunities per day at the times that suit you. Life-safety emergency alerts are the one exception and always break through your cap.
Every article that matches your interests reaches your Feed. Mera reads them, sets aside the noise and lifts what matters. Semantic search finds the candidates, then an LLM reads each one to decide whether, and why, it matters to you. When that reading happens in the cloud, your plan sets how much of it Mera does each day: Starter reads 10 MB a day, Individual 50 MB (5x Starter) and Professional 200 MB (20x Starter). Mera reads for you through end-to-end encryption, so it can't see which articles it reads or how many. That's why plans are measured in megabytes of encrypted text, not in articles. Articles Mera hasn't read yet still appear in your Feed, below Mera's picks. On supported phones, reading on the phone is unlimited on every plan.
iPhones and Android phones, worldwide. Android phones need Google Play. Mera signs you in with your phone, using Apple's App Attest on iPhone and Google Play Integrity on Android, and a phone that can't pass that check can't use Mera.
Twenty, and the same twenty on iOS and Android: Arabic, Chinese (Simplified and Traditional), Dutch, English, French, German, Hindi, Indonesian, Italian, Japanese, Korean, Polish, Portuguese, Russian, Spanish, Thai, Turkish, Ukrainian and Vietnamese. News itself is gathered from sources in many more languages and matched across them, so the language a story was written in never limits what reaches you.
59. Android translates with Google's on-device models, and the model for a language is downloaded the first time you need it, so the count doesn't depend on your Android version.
20 on a current iPhone, and 26 on iOS 27 and later. Apple ships translation languages with the operating system itself, so which ones you get depends on your iOS version: Ukrainian needs iOS 17, Hindi needs iOS 18, and Cantonese, Danish, Hebrew, Malay, Norwegian and Swedish need iOS 27. Whatever your iPhone can't handle, Google Translate still can.
More than 200, on iOS and Android alike. Article pages carry a Read on Google Translate button that opens the publisher's page translated into your app language, with nothing to download and no dependence on your OS version. Google detects the source language itself, so this path isn't limited to what your phone can translate on device; the translation goes into whichever of our 20 app languages you've chosen. The button is there whenever we hold a secure link to the article.
Plans & billing
Starter is free. Individual and Professional are paid plans, and they differ from Starter only in how much Mera reads for you in the cloud each day (see “What's the difference between the plans?” below). Every article that matches your interests reaches your Feed on every plan. You can use Starter for as long as you like, with no payment details. Current pricing for the paid plans in your region is shown in the app's plan picker and on the App Store or Google Play listing.
You get Starter, free: the complete Mera experience, including the AI analysis. Every article that matches your interests reaches your Feed, and Mera reads a set amount for you in the cloud each day. That amount resets once a day at midnight UTC, and the app shows you what time that is where you are. On supported phones, reading on the phone is unlimited on every plan. Paid plans let Mera read more in the cloud and change nothing else.
No. Starter is free and stays free, so there's no card, no App Store or Google Play trial, and nothing to cancel. You choose a paid plan only when you want Mera to read more for you each day.
Only how much Mera reads for you in the cloud each day: 10 MB on Starter, 50 MB on Individual (5x Starter) and 200 MB on Professional (20x Starter). Plans are measured in megabytes because Mera reads through end-to-end encryption and can't count the articles it reads. Every plan includes the complete Mera experience, Starter included, and every article that matches your interests reaches your Feed on every plan. On supported phones, reading on the phone is unlimited on every plan.
Starter isn't a subscription, so there's nothing to cancel. If you cancel a paid plan you go back to Starter rather than losing access to your account. A paid plan is managed through the App Store or Google Play, and there's also a manage-subscription screen inside the app. You can cancel anytime.
Apple or Google bills you, not Mera. Apple sends receipts and invoices to the email on your Apple Account, and Google Play sends receipts to the email on your Google Account. Mera doesn't send billing emails. On iPhone, manage your plan in the App Store's subscription settings, and go to reportaproblem.apple.com for receipts, refunds and billing problems. On Android, open Google Play and go to Payments & subscriptions.
Your new phone gets a new Mera account, because your phone is what signs you in. Your data comes back from your own iCloud or Google Drive backup. Your paid plan follows your App Store or Google Play account: sign in to the store with the same account and tap Restore purchases in Mera. If you switch between iPhone and Android, your plan stays with your old store. Cancel it there, then subscribe again on the new one. Mera can't see plans on other stores, so it can't refund any overlap.
Technical & troubleshooting
Relevance scoring is real LLM work that runs on your own device or in a private enclave, not on a server farm reading your profile. Articles are analysed in batches with visible progress. That's the cost of privacy-preserving personalisation, and it gets noticeably faster on newer phones.
On your device. Your profile, personal facts, reading history, and saved articles all stay local. Mera's servers never receive them. What we hold about you is a sign-in record for your phone, a Support ID, your subscription status, and, for each day, how much encrypted text Mera sent to be read for you (never the text itself), how many requests that took, how many articles reached your Feed, your plan's daily amount and the time it ran out, which is how your plan is applied. If your account was created with an email before 30 October 2026, we also hold that email until we delete it on that date. If you've submitted a request to be unblocked after the chat guardrail flagged you, the transcript you chose to attach is held for review. See “What do you store on your servers?” for the full picture.
If your phone can't run the model locally, analysis runs inside a trusted execution environment. Your app fetches the enclave's attestation report and encrypts the request to the key it publishes (X25519 key exchange with XChaCha20-Poly1305), so the request is unreadable in transit and unreadable to us, and everything is wiped once the computation finishes. Being precise about today's limit: the app does not yet check the attestation's signature against the hardware vendor and refuse to continue if it fails. So right now the thing you're trusting is Mera and the enclave operator, not the silicon itself. Closing that gap (verifying the quote and failing closed) is on the roadmap below.
Tied to your account: a Support ID, your subscription status, a daily record of how much encrypted text Mera sent to be read for you (never the text itself), how many requests that took, how many articles reached your Feed, your plan's daily amount and the time it ran out, used to apply your plan (kept for 90 days, with no article text, topics or chat), your sign-in sessions (no IP address or browser details, and each one is deleted when it expires, after a year at most), and the billing records the app stores send us when your subscription changes. If your account was created with an email before 30 October 2026, we hold that email until we delete it on that date. We also keep a sign-in record for your phone: an App Attest key on iPhone, or a one-way hash of your Android ID on Android. It's deleted as soon as you ask to delete your account. If you've filed a request to be unblocked after the chat guardrail flagged you, the transcript you chose to attach is stored until a human reviews it and deleted 90 days after that, or after 180 days if nobody has reviewed it by then. We're still adding a clearer preview of exactly what gets attached. Our server error logs can include the IP address and device type of a request that failed, and they're deleted after 30 days. The topic phrases you send are stored too, but in a cache keyed by the text itself: no user ID is attached, every reader draws from the same shared cache, and any topic nobody has requested for 14 days is deleted. Your profile, your personal facts, and your reading behaviour are never sent to us and never stored.
Transparency & roadmap
No. Mera is source-available. The app's full source is published so anyone can read it, compile it, and audit it, but the licence doesn't grant production or commercial use. We're deliberate about the wording: “open source” has a specific meaning (an OSI-approved licence, with the freedom to use and redistribute) and Mera doesn't meet it. Calling ourselves open source would be the cheapest claim available to us, which is exactly why we don't make it.
We're still building this. It isn't a matter of flipping a repository to public: the code that handles your data and the code that runs our news pipeline currently live in one codebase, and separating them properly is most of the work. What we're building is a new service, one repository with four deployable parts, all source-available: the API the app queries, the authentication service that handles sign-in, sessions and signing keys, the end-to-end-encrypted inference relay, and a background worker for notifications. That service becomes the only thing the app talks to. Everything that knows who you are moves into it. Our news backend stays closed and becomes a pure article service that receives topic phrases with no identifier of any kind attached (no user ID, no session, no device ID, no client IP); this will be enforced by a fixed allowlist of outbound fields, with a test that fails the build if anything is ever added to it. The two systems will run on separate databases with separate credentials and no cross-system database access, so the closed side will not be able to read a user record even by mistake. None of that is in place yet. It is what we are building, and we would rather describe it in the future tense than let you read it as already done.
That's the point of doing it this way, though to be clear, this describes what we're building, not something you can download today. The source-available service will ship with pluggable providers: a news-provider interface with a reference adapter backed by a public search API, so you'll be able to run the whole app against your own data without our pipeline, and an entitlements interface defaulting to unlimited, so you won't need a billing account to try it. You'll get a working, genuinely private news reader. You won't get our semantic retrieval, story clustering across languages, or breadth-ranked headlines: that's where the infrastructure and cost work lives, and it's what the subscription pays for. We think that's the honest line to draw: you should be able to verify what happens to your data, not necessarily rebuild the product from our source.
We'd rather you heard these from us than found them. Cloud inference is the default, not on-device: running the model on your own phone is something you turn on, and we should say that more plainly than we have, because the rest of our writing can leave the impression it's the other way round. The backend isn't published yet, so what happens to your topic phrases is documented but not readable. The app encrypts inference requests to the enclave's attested key but doesn't yet verify that attestation against the hardware vendor and refuse to continue on failure, so today's trust anchor is us plus the enclave operator, not the silicon. We don't publish reproducible builds or signed release hashes yet, so you can read our source but can't yet prove the app on your phone was built from it. Even once the backend is public, source code can't prove which code a server runs: nobody's can, and we'd rather say so than imply otherwise; a transparency report is planned so at least our conduct under legal requests is on the record. Hardening against prompt injection in AI-processed content is ongoing. And our published list of third-party providers was incomplete and named payment processors we don't actually use. That's corrected in this update.
For some topics, and only in a narrow, literal sense. When one of your topic phrases pairs a city or locality name with a subject word — "Bhopal weather", "Amsterdam jazz events" — the server requires the article's own text to actually mention that place before it can be returned for that topic. It's a keyword post-filter on the phrase, added because semantic search alone couldn't do the job: for a place-plus-subject query the vector anchors almost entirely on the subject word, with geography contributing at most about 0.03 to the similarity score, so same-subject articles from unrelated cities were reliably outscoring genuine local ones. The limits matter more than the feature, so here they are. It applies only to city and locality topics: a topic whose subject IS a country or a continent ("Netherlands policy", "EU AI Act") is deliberately never filtered this way, because there the place is the subject matter and precise place-matching would throw away legitimate national coverage. The match itself is a plain case-insensitive substring test against the article's title, description and original-language title. There is no gazetteer and no alias list, so a topic that says "Bombay" will not match an article that says "Mumbai" — that is a known gap we haven't closed, not a solved problem. And it fails open by design: where the check can't be made confidently, such as a phrase we don't read as a place or an article with no text to search, the article is kept rather than dropped. None of this makes your feed location-aware, and none of it involves the server knowing where you are. It is a filter on the words in a topic phrase. The gate reads only the topic phrase, and topic records carry no location field and no record of which fact produced them.
Partly, you shouldn't have to. That's the entire point of the work above. The more of this you can check for yourself, the less you have to take my word for anything. But I'll be straight about where things stand: Mera is built by one person. Full transparency is what I'm aiming for and I'm not there yet. The gaps listed above are real, I've published them rather than waited to be caught, and my resources are what they are. For now the honest ask is that you trust me to ship these quickly, not that you trust they're already done. This page gets updated as each one lands.
Support
Email us at contact@mera.news, or use the Report a Bug option inside the app. If you email us, include your Support ID from the bottom of Settings in the app.
Still have a question? Email us at contact@mera.news. We're happy to help.