CraysNoflux
Noflux is a feed reader first and a Nostr app second. That is its strength: it lets NIP-23 articles enter the same quiet reading workflow as RSS, Atom, RDF and JSON feeds, with OPML, APIs, keyboard shortcuts and self-hosted discipline around it.
A feed reader with a Nostr door
Noflux is not trying to turn reading into a new social feed. That alone makes it refreshing. Its homepage calls it a Nostr and RSS feed reader, and the first promise is not virality, discovery magic or a new public square. The promise is readability. You subscribe to sources, scan unread items, open articles, mark things read, save what matters and move on. Nostr enters through the side door: alongside RSS, Atom, RDF and JSON feeds, Noflux can subscribe to NIP-23 long-form posts from Nostr accounts.
That makes Noflux useful for a very specific kind of reader. If you already follow writers through RSS and you also care about Nostr long-form posts, you know the awkward gap. One world lives in feeds, OPML exports, old reader apps and quiet self-hosted habits. The other world lives in relays, npubs, naddrs and clients that often treat articles as an extension of social posting. Noflux does not ask you to pick a side. It lets Nostr articles behave like feed items.
The project trail is clear. Noflux lives at noflux.nostr.technology, and the code is in fiatjaf/noflux. The repository was created in December 2024, is Apache-2.0 licensed, written primarily in Go, and describes the project as a minimalist and opinionated feed reader. The man page credits fiatjaf as the author and names Miniflux by Frederic Guillot as the base. That last part matters more than the logo: Noflux inherits a mature reader philosophy and then grafts Nostr article discovery onto it.
Why Miniflux matters here
Miniflux is one of those apps that knows exactly what it wants to be: a small, readable, self-hosted feed reader with as little theater as possible. Noflux keeps that spine. The feature list still sounds like a serious reader's checklist: OPML import and export, categories, bookmarks, favicons, multiple enclosures for podcasts and media, full-text search, keyboard shortcuts, responsive design, themes, a REST API, webhooks, and support for existing reader apps through Fever or Google Reader APIs. This is not a novelty client built around one Nostr feature. It is a real reader into which Nostr was invited.
The infrastructure choices show the same temperament. Noflux is written in Go, bundles static files into the application binary, publishes prebuilt binaries and packages, and can be installed through Docker or system packages. Unlike Narr, which is a single-binary SQLite desktop or personal server reader, Noflux expects PostgreSQL. The requirements page says PostgreSQL 9.5 or newer is the supported database, and the feature page calls the full-text search a Postgres benefit. That makes Noflux less casual to install, but more familiar to people who already run self-hosted services.
Privacy is part of the reader story, not a separate slogan. The official feature page says Noflux removes pixel trackers, rewrites FeedBurner-style original links, opens external links with safer attributes, uses a no-referrer policy, can proxy images to avoid mixed-content and tracking issues, blocks external JavaScript in content, sanitizes external HTML, and can play YouTube through less invasive routes such as youtube-nocookie.com. If you read a lot, this matters. A feed reader is a machine that visits pages on your behalf. You should care about how it handles trackers, scripts, referrers and scraped content.
How an npub becomes an inbox
The Nostr code is compact and worth reading. Noflux accepts Nostr-flavored feed URLs: nostr:, nostr://, npub and nprofile. It will also resolve a NIP-05 identifier when it is explicitly given with a Nostr prefix. Once it has a profile, it stores the feed as a Nostr profile feed, builds an nprofile, and sets the site URL to njump for that profile. This is a practical choice. Noflux is not trying to become a general Nostr browser. It needs stable web URLs for entries and profiles inside a reader.
When the feed refreshes, Noflux fetches the author's outbox relays through go-nostr's SDK and subscribes to nostr.KindArticle, the long-form article kind behind NIP-23. In code terms, that means the reader asks for events from that author, filters by the article kind, and uses a limit of 300. It then reads the article title from the title tag, uses published_at when available, turns the Markdown body into HTML with the NIP-23 helper, builds an naddr link, and stores a feed entry whose URL points to njump.
That is a lovely little bridge. NIP-23 says long-form posts are addressable kind:30023 events, written in Markdown, usually carrying tags such as d, title, image, summary and published_at. Noflux does not ask the writer to syndicate a separate RSS feed. It lets the Nostr article itself become the feed item. It also replaces nostr: links in article bodies with readable HTML links to njump, including profile names when it can resolve them. That turns the strange-looking NIP-19 strings into something a reader can click without needing to understand every encoding detail first.
The tradeoff is visible too. Noflux is reading a public author's long-form stream; it is not trying to mirror every relay forever or solve every archival problem. The limit, the relay discovery path and the dependence on outbox metadata all mean that a missing relay setup can feel like a missing article. That is not a flaw so much as a reminder of what Nostr reading actually depends on. A writer can publish a perfect NIP-23 event, but readers still need hints, relays and clients that know where to look.
A serious reader, not a social app
This is where Noflux should be judged fairly. It is not a replacement for Primal, Iris, Damus, Coracle or noStrudel. It is not where you go to argue under notes, watch short posts roll by, manage a follower graph or live inside a social client. Noflux is for a quieter job: collect long-form reading, keep it organized, make it searchable, let existing reader habits keep working, and give Nostr writers a place in that stack.
The external-reader support is a big part of the appeal. NostrApps calls out Reeder and ReadKit-style access, and the Noflux documentation backs that up through Fever and Google Reader compatibility. The API reference is not a small marketing page; it documents authentication, feed discovery, feed CRUD, entry updates, OPML import/export, user management, counters, health checks and application version endpoints. Noflux also supports per-application API keys, which is exactly the kind of boring feature that tells you the project expects real use.
There is also a wider integration layer. The feature page lists more than 25 third-party integrations, including Instapaper, Linkding, Matrix, Notion, Ntfy, Pinboard, Pocket, Readwise Reader, Shaarli, Shiori, Telegram and Wallabag. You may not use all of them. You probably should not. But they show the kind of product Noflux is: a reading control room. Nostr articles become part of the same workflow as web articles, newsletters, podcasts, video feeds and saved reading destinations.
This is also why Noflux belongs in a Nostr app archive even though it looks, at first glance, like old web infrastructure. The open web never really disappeared; it just became less glamorous than timelines. Nostr long-form posts are stronger when they can sit beside older publishing routes instead of replacing them by force. Noflux respects that continuity. It lets a reader keep the old discipline of subscriptions while adding the newer protocol layer where it is genuinely useful.
What to test before moving in
If you are evaluating Noflux, start with your actual reading life. Import an OPML file. Add a normal RSS feed. Add a Nostr author by npub or nprofile. Add one NIP-05 address with the explicit Nostr prefix. Then watch what happens during refresh. Do the NIP-23 posts appear with titles, readable content and sane dates? Do njump links resolve the article and profile correctly? Do the outbox relays produce the articles you expected, or does the writer publish through relays that your reader does not find?
Then test the reader habits. Use the keyboard shortcuts. Open the original article. Fetch original content for a web feed. Bookmark an entry. Export OPML. Connect a mobile or desktop reader through the compatible API if that is part of your workflow. Check search. Check authentication. If you are hosting it for more than yourself, look closely at PostgreSQL, backups, HTTPS, user accounts and API keys. Noflux is calm on the surface, but it is still a server holding your reading history.
The best reason to use Noflux is not that it is "decentralized." The best reason is that it respects reading. Nostr long-form posts are most powerful when they do not have to be trapped inside one client. Noflux gives them another life: not as a social notification, but as an article in an inbox you control. That is a small idea with teeth. If Nostr is going to matter for writers, researchers and people who actually read slowly, apps like Noflux are part of the bridge.
Sources worth opening
This article keeps claims close to the project site, repository, documentation and the NIP-23 text that defines the article event Noflux reads.
- Noflux official site
- Noflux features
- Noflux requirements
- Noflux installation docs
- Noflux user-interface docs
- Noflux API reference
- Noflux man page
- NostrApps listing for Noflux
- fiatjaf/noflux GitHub repository
- Noflux README
- Noflux Nostr reader code
- Noflux feed handler
- Noflux Go module file
- NIP-23 long-form content
- Miniflux project site
- NIP-25 reactions
- NIP-27 text note references
- Nostr protocol NIPs repository
- NIP-01 basic protocol flow
- NIP-05 DNS identifiers
- NIP-07 browser signer capability
- NIP-10 text note threading
- NIP-11 relay information document
- NIP-19 bech32 encoded entities
- NIP-44 versioned encryption
