I’m not sure how that comment is helpful?

Thank you!

Honest answer: It’s a different kind of tool, so “better” depends on what you’re after. Compass isn’t a sync client — it doesn’t speak the GReader API and doesn’t connect to FreshRSS or any other backend. There’s no server involved at all; it fetches public RSS/Atom feeds directly on the device. So if your workflow is built around FreshRSS as your source of truth with read-state syncing across devices, Compass won’t slot into that — a dedicated GReader client is what you want there. Where it might appeal even so:

No server to run. It’s fully self-contained — nothing to host, maintain or expose. The reader strips trackers. Articles are fetched and rebuilt as clean text with the scripts, ad slots and tracking pixels removed before render — so you’re not just getting a clean feed list, the article view itself is de-junked. Political-lean dial on every headline, so you can read across the spectrum at a glance. Curated NZ + international outlets out of the box, plus you can add your own feeds.

GReader/FreshRSS sync isn’t there and isn’t on the immediate roadmap — it’s a meaningful piece of work and I’d rather not half-build it. If there’s genuine interest from self-hosters, though, I’m listening. Honestly, it sounds like we might be solving slightly different problems, but if the standalone + tracker-stripping angle appeals, I’d love your feedback on it. 🧭

This is a genuinely good set of points — let me take them honestly rather than pretend I’ve got a slick answer to all of them. “Tons of RSS readers already” / lite.cnn.com / gnus.el — completely fair. I’m not claiming to reinvent RSS. What I was actually after was a specific combination: curated NZ outlets working out of the box, a political-lean indicator on each source, and — the main thing — an article view that strips the ads and trackers rather than dumping you into a bloaty page. If you already have a reading setup you like, I’m honestly not going to pull you off it, and that’s fine. Why a built-in reader instead of a webview — this is the crux, and it’s the opposite of “yet another special text UI for its own sake.” A webview loads the page with its scripts, ads and tracking pixels — which is exactly the thing I was trying to avoid. The custom reader exists specifically so none of that executes: fetch the page, extract the article, discard the rest, render clean. The text UI isn’t the goal; killing the trackers is, and a clean reading view is the byproduct. Could it be a static page with local storage / a local httpd — you’re close, and you’ve basically described what it is under the hood: it’s an HTML/JS app. The reason it’s wrapped natively rather than being a pure browser page is CORS — a plain static page can’t fetch arbitrary third-party RSS feeds from the browser; the outlets don’t send the headers that would allow it. The native shell is really there to make the cross-origin fetch possible, plus give durable local storage. A local httpd would work for you personally but isn’t something I can ship to non-technical phone users. Headline-only feeds + bot detection — this is the sharpest point and you’re right. Some feeds are headline+summary only, and some article pages sit behind bot-detection that a straightforward fetch won’t beat. I don’t try to defeat that — when extraction fails or a feed is summary-only, the app is honest about it: it shows the summary and offers to open the full page externally, rather than pretending it scraped something it couldn’t. Full “orchestrate a real browser to get past bot walls” scraping is a road I’ve deliberately not gone down — it’s an arms race and it’s exactly the kind of heavy machinery I was trying to get away from. The name — ha, fair. “Compass” is not what you’d call unclaimed. Noted. F-Droid / no Play account — totally understood, and same as I said to another commenter: an APK and eventually F-Droid are the direction I want to go once it’s stable. No worries if you’d rather wait for that. Appreciate you engaging with it properly. 🧭

Checked the merged manifest, so this is the real answer, not a guess: The app requests exactly one permission: INTERNET. That’s it — needed to fetch the news feeds and article pages, and nothing else. No storage, location, contacts, camera, microphone, phone state, Bluetooth, or notification permissions. It doesn’t request them because it doesn’t do anything that would need them. Saved articles and settings live in the app’s own private sandbox, which doesn’t require a storage permission. The only other line you’ll spot in the manifest is DYNAMIC_RECEIVER_NOT_EXPORTED_PERMISSION at the signature protection level. That’s not a user-facing permission and grants the app no access to anything — Android auto-generates it to lock the app’s internal broadcast receivers to its own signing key. Every modern Android app targeting recent API levels has it; it’s a security measure, not a capability. So if you install it and check, you should see a single permission: internet access. If it ever asks for more, something’s wrong and I’d want to hear about it.

Fair question! Right now it’s Play Store closed testing only, so no F-Droid or direct APK just yet. That’s purely a “still in testing” thing, not a permanent choice. Both are on my radar though: once it’s stable I’d like to offer a direct APK for folks who don’t do Play Store, and F-Droid is a natural fit given the app’s whole ethos (no ads, no trackers, nothing phoning home). F-Droid takes a bit more work — the build has to be fully open-source and reproducible — so it’s a “when I get there” rather than “next week,” but it’s genuinely the direction I want to go. If you’d rather wait for an APK than use the Play Store, totally understand — drop a follow and I’ll post when there’s one available. Appreciate you asking. 🧭