CraysNarr
Narr is what happens when RSS, local software and Nostr long-form articles meet in the same reading chair. It is small, technical, stubbornly useful and very much not trying to be a social network.
RSS never left the room
There is a temptation in Nostr to treat every old web technology as if it has been spiritually replaced. That is usually a mistake. RSS did not fail as a reading technology. It was pushed aside by platform timelines, app stores, engagement metrics and the convenience of letting somebody else decide what deserves your eyes today. If you care about long-form writing, RSS still has a beautiful shape: subscribe to sources, pull new items, read on your own terms, export your list, leave when you want.
Narr understands that Nostr long-form content belongs in that same mental family. It is not a client for posting hot takes. It is not a feed algorithm. It is not a social app pretending that every article has to arrive through a notification storm. Narr is a reader for people who want old-web feeds and Nostr articles in one quieter place. The name is a joke: "not another rss reader." The product is more serious than the joke. It asks a good question: what if NIP-23 articles could sit beside RSS, Atom, RDF and JSON feeds in the reader you already know how to use?
The official repository describes Narr as a web-based RSS and Nostr long-form feed aggregator that can be used as both a desktop application and a personal self-hosted server. That one sentence is the whole design. You can run it locally, keep the database near you, and use the web interface or another compatible reading client. It feels less like joining a service and more like adding an instrument to your desk.
Narr comes from fiatjaf, one of the central Nostr builders. His tools page lists it as a Nostr-capable RSS reader based on yarr. NostrApps lists the highlights: RSS feeds, Nostr NIP-23 long-form articles, OPML import and export, desktop use with a web-based UI and remote access from apps such as Reeder and ReadKit. Those are not random checkboxes. They are the practical pieces that let long-form Nostr leave the social feed and enter a reading workflow.
What Narr actually runs
Narr is written primarily in Go and released under the MIT license. The GitHub repository was created on December 21, 2024, and describes the project as a self-hosted Nostr and RSS reader. The latest release found during this research was v0.3.3, published on January 25, 2025, with prebuilt zip assets for Linux, macOS and Windows AMD64. That matters because Narr is not merely a hosted website. It is software you can download and run.
The README says the app is a single binary with an embedded SQLite database and that it is based on yarr. In practice, that gives Narr a very specific personality. It is not a cloud feed service with an account page somewhere. It is a local server with a database file. The default command-line address is 127.0.0.1:7049. There are flags and environment variables for server address, base path, authentication, TLS certificate and key files, database path, log file and opening the server in a browser.
That setup has consequences. It means your feed state, read state and stored items live in SQLite unless you configure otherwise. It means backups are your responsibility. It means self-hosting can be private and sturdy, but not magical. If you expose Narr beyond localhost, you need to understand auth and TLS. The README is plain about this: for self-hosting, check narr -h for auth, TLS and server configuration flags.
The codebase also shows that Narr is not only a wrapper around Nostr. It contains feed parsers for RSS, Atom, RDF and JSON Feed, OPML import/export code, readability and sanitizer modules, storage layers, a web UI, systray integration and server routes. The Go module pulls in github.com/mattn/go-sqlite3, github.com/nbd-wtf/go-nostr, github.com/fiatjaf/eventstore, Markdown rendering and HTML sanitation. The result is a reader with old-web plumbing and Nostr plumbing in the same body.
How Nostr becomes a feed
The most interesting part of Narr is how it turns a Nostr profile into something feed-like. The Nostr worker accepts inputs with nostr: or nostr:// prefixes, and it recognizes profile-style identifiers such as npub and nprofile. The server route also helps by prepending nostr: when a user enters an npub, an nprofile or a NIP-05-style address without a Nostr prefix.
Once Narr resolves the profile, it fetches outbox relays, subscribes for the author's article events and asks for nostr.KindArticle, which maps to the NIP-23 long-form kind. The worker uses a limit of 300 events. For each article it builds a feed item from the event: title, summary, image, published time, update time, HTML content and a URL pointing to njump with an naddr. That is the bridge. The Nostr article remains a Nostr article, but Narr gives it the shape a feed reader understands.
The article content path is careful in ways that matter. The worker converts NIP-23 Markdown to HTML, replaces Nostr identifiers with HTML links, and when it sees profile identifiers it tries to fetch profile names so the output can be more readable than a wall of bech32 strings. It also links Nostr references to njump. This is exactly the kind of boring-looking translation work that makes open protocols pleasant. A standard is only useful when somebody does the patient work of making it readable at the edge.
Narr does not turn all of Nostr into RSS. That would be a different product. It focuses on long-form articles. That focus is healthy. A social firehose and a long-form reader are not the same kind of attention. Narr treats NIP-23 like the article format it is supposed to be: something you subscribe to, store, search, mark read, revisit and maybe read later in an app that does not care about likes or follower drama.
OPML, Fever and the reader you already like
RSS people care about portability because they have been burned before. OPML is the old, practical answer: export your subscription list, import it somewhere else, keep moving. Narr supports OPML import and export. The route code exposes /opml/import and /opml/export, creates folders and feeds from imported OPML, and exports subscriptions as subscriptions.opml. That sounds dry until you lose a reader account or migrate machines. Then it becomes the difference between freedom and tedious reconstruction.
Fever API support is the other important bridge. Narr's Fever documentation says the implementation is based on an existing Fever API spec and warns, honestly, that different server and client implementations can have compatibility problems because the original definition is not very clear. It lists tested apps including Reeder, ReadKit, Fluent Reader, Unread and Fiery Feeds. That is a thoughtful choice. Instead of forcing you to love Narr's own web UI, Narr can act as the backend for a reader app you already prefer.
The Fever code exposes groups, feeds, favicons, items, unread item IDs, saved item IDs, mark-as-read and saved/unsaved states. It is not glamorous, but it is exactly what makes a reader feel like a reader rather than a scraped web page. Read state matters. Folders matter. Favicons matter. A saved item matters. Nostr can learn a lot from this old RSS discipline: the reading environment should be calm, persistent and user-shaped.
The combination is unusually practical. You can feed Narr with old websites and Nostr authors. You can import old subscriptions. You can export them later. You can use the web interface, or point an external reader at the Fever endpoint. You can run the whole thing as a desktop app or as a small personal server. That is not a fashionable product pitch. It is better: it is a stack a serious reader can imagine living with.
The kind of reader who should care
Narr is for readers who do not want every piece of writing to become a social-media event. If you follow Nostr authors who publish NIP-23 articles, and you still have RSS feeds from blogs, newsletters, project pages, journals or weird small sites, Narr gives those worlds a shared room. You can treat a Nostr author like a feed source. You can keep read/unread state. You can export your subscriptions. You can decide whether the web UI is enough or whether Reeder, ReadKit or another Fever-capable client is the better front end.
The checks before serious use are ordinary but important. First, decide whether you are running it only on localhost or exposing it beyond your machine. If it is not just local, configure authentication and TLS thoughtfully. Second, back up the SQLite database if the read state and subscriptions matter to you. Third, test your Nostr sources. Nostr article discovery depends on profile resolution, relay availability and outbox hints; if an author publishes on relays Narr cannot reach, your reader will not summon those articles from nowhere.
Fourth, understand the shape of the Nostr bridge. Narr fetches long-form article events and turns them into feed items; it is not a replacement for a full Nostr client. It will not give you every reaction, reply, zap, repost or social context around an essay. That limitation is part of its virtue. You open Narr to read, not to perform.
The nicest thing about Narr is that it reminds you Nostr does not have to invent every interface from scratch. Some of the best network habits are old: feeds, folders, export files, local databases, desktop software, small servers. Narr gives NIP-23 articles a way to enter that older, saner reading culture. For long-form Nostr, that is a real contribution.
Sources worth opening
This article keeps claims close to the public project trail. Start with these pages when you want to verify the product yourself.
- Official project
- GitHub repository
- Project README
- Latest release checked: v0.3.3
- Go module dependencies
- Nostr worker source
- Server routes source
- Fever API support notes
- Build documentation
- NostrApps listing
- fiatjaf tools page
- Go package page
- NIP-23 long-form content
- NIP-54 wiki
- 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
- NIP-46 remote signing
- NIP-51 lists and mute lists
- NIP-56 reporting
