Add native Miniflux account type with API key authentication

[IngmarStein]

Uses Miniflux's native REST API (/v1/*) instead of the Google Reader compatibility layer. Authenticates via X-Auth-Token header.

• New AccountType.miniflux (24) with dedicated MinifluxAccountDelegate
• MinifluxCaller: full API client for feeds, categories, entries, OPML
• Version detection (GET /v1/version) gates /v1/entries/ids for v2.3.2+ with transparent fallback to /v1/entries pagination on older instances
• macOS: credential sheet with API URL + API key fields
• iOS: credential view controller with same
• Asset catalogs: accountMiniflux icon in both Mac and iOS

Closes #3593
Closes #4743

[rcarmo]

I'd love to see this merged, as I've just moved to Miniflux as a back-end for my feeds.

[IngmarStein]

Hey @brentsimmons, is this something you'd consider merging? I know that Miniflux can already be connected as a FreshRSS account, but this PR improves upon that in several ways:

• it doesn't require Miniflux users to enable the Reader API (works out of the box)
• it provides authentication through an API key instead of an additional username / password pair for the Reader API
• the native API is more efficient
• it's discoverable (Miniflux users will instantly recognize the correct account type)

[rcarmo]

Yeah, it would be nice to have this instead of having the other API poke at the database. My picoflux fork (which uses SQLite) works with the Reader API, but the native one is quite a bit more efficient, and it shows at the database level.

[dave-atx]

Hi @IngmarStein — great to see this PR. I owe you an apology for not finding it sooner: I've been building a native Miniflux account type for NetNewsWire in parallel, over on dave-atx/miniflux. We even independently picked the same AccountType raw value (24), so we clearly agree on the fundamentals. 😆

Rather than run two competing PRs, I'd like to team up on a single effort. I feel like one well-tested PR seems like our best shot at getting Miniflux support landed.

A few things my branch brings that might be useful to combine:

• Incremental sync via changed_after — entry fetches and status changes ride along in one request, so routine refreshes don't rescan the whole account
• Missing-article backfill via GET /v1/entries/{id}, with 404s cleaning up orphaned sync statuses
• Batched status updates, basic + API-token auth, enclosure support, and three test suites with local fixtures

And I've already adopted two ideas from your PR into my branch — thank you for these:

• Runtime server-version detection with graceful fallbacks. My branch originally had a hard 2.3.2 floor, which would have excluded nearly every real install; your approach was the right one. The floor is now 2.0.49 (/v1/version + changed_after), with /v1/entries/ids and batch starred updates gated at 2.3.2 and falling back to paged /v1/entries and per-entry bookmark toggles below that.
• Rejecting a duplicate account for the same server endpoint.

One thing I deliberately didn't carry over is POST /v1/discover: NetNewsWire's account delegates run the app's own FeedFinder before calling the API, so the server only ever sees an already-resolved feed URL — the discover round-trip would duplicate that.

If you're open to it: take a look at my branch, poke holes in it, and let's jointly propose a merged version as the successor to this PR. Or just tell me to go fly a kite 😉

[IngmarStein]

@dave-atx looks like you already incorporated the good parts of this PR into your branch. Happy to retire this one in favor of yours - maybe you get more traction!

[dave-atx]

Sounds great... I opened a thread in the NetNewsWire discourse to discuss there.

[IngmarStein]

Alright. That link doesn't work for me, but there's also https://discourse.netnewswire.com/t/miniflux-support/37