CraysIris
Iris is an offline-first Nostr client from Martti Malmi and irislib, built around local storage, social graph filtering, secure messaging, Cashu payments and web-to-desktop portability.
The friendly door that grew up
Iris has always had a useful ambition: make Nostr feel like something a normal person can open without first memorizing relay gossip, event kinds and key custody arguments. That sounds small until you try to bring someone into Nostr. A lot of clients explain the protocol by making the user stare directly at it. Iris tries to do the opposite. It gives you a social app first, then lets the protocol show up where it matters: identity, follows, posts, messages, relays, usernames and payments.
The old catalog sentence called Iris a simple and fast web client. That was not completely wrong, but it is now far too thin. The current `irislib/iris-client` README calls Iris a highly performant, normie-friendly, offline-first Nostr web client that is not dependent on a single relay or server. It also names a Cashu wallet, secure DMs and social graph based content filtering. That is a different product shape. You are not just reading a feed. You are using a Nostr home base that wants to carry your social graph, your messages and some money movement without asking one company to be the center of your online life.
There is also a project history hidden in the sources. The older `irislib/iris-messenger` repository still describes Iris as a Nostr Android, iOS and web client with standalone desktop and Docker versions, but its README now points readers to `irislib/iris-client` as the current source for iris.to. The new repository was created in October 2024, is written mostly in TypeScript, carries an MIT license and was still active in 2026. As of June 6, 2026, GitHub showed 68 stars, 18 forks, 18 open issues, a latest push on May 8, 2026 and a latest stable app release named `app-v2.3.1` from November 3, 2025.
The person named in the current package metadata is Martti Malmi, better known in Bitcoin history as Sirius. That matters because Iris is not a random white-label social web shell. It comes from someone who has spent years around open networks, cryptographic identity and the awkward human work of making that stuff usable. The public GitHub organization is `irislib`; the project also points its main development trail to decentralized git at `git.iris.to`, using an `htree://` address. Even the source hosting choice is part of the story: Iris is a Nostr client that is trying to live closer to Nostr-shaped infrastructure.
Local-first is the point
If you only test Iris by asking whether the timeline scrolls quickly, you miss the more interesting bet. Iris is trying to make the local device important again. The FAQ talks about local storage, cached profiles, follows and recent notes. The repository depends on Dexie and localForage, two libraries used for browser-side storage. The README calls the app offline-first. Put those together and you get a clear design instinct: do not treat the browser as a thin window into a platform database. Treat it as a place where the user can keep enough state to keep moving.
That is not a magical promise. Nostr still needs relays. Search still depends on relays that support search. A follower count can vary because it is reconstructed from following lists found across relays, not read from one central counter. A delete request is still a request; on Nostr, other clients and relays have to honor it. Iris does not pretend those rough edges disappear. The FAQ is unusually honest about them. It tells you that IP addresses can be exposed to relays, that DMs reveal sender, recipient and timestamp even when the message content is encrypted, and that image loading is proxied to reduce IP leakage except for whitelisted services such as imgur.com and nostr.build.
That honesty is useful. It gives the reader a better frame for judging Iris. This is not a sealed social network where the platform can say, "trust us, everything is handled." It is a client operating in an open network. The client can cache, filter, sign, encrypt, render and publish. It cannot turn every relay into a privacy tool. It cannot make every third-party client delete a note. It cannot make a public graph behave like a private chat. A good Nostr client has to teach those boundaries without making the whole experience feel like a lecture. Iris gets closer than many because it hides some complexity in the interface but leaves enough warning labels in the docs for people who care to look.
Social graph, wallet and messages
The phrase "social graph based content filtering" sounds dry, but it is one of the most important things a Nostr client can do. On a centralized network, ranking is usually owned by the platform. On Nostr, your follows are portable, public or private depending on the event type, and readable by more than one app. Iris uses that graph to shape what you see. The FAQ says follower counts are built from following lists found on relays, and the interface uses social context around follows. In plain language: Iris is trying to make your network of people useful without converting it into someone else's locked database.
Then there is the Cashu piece. Cashu is an ecash system for Bitcoin payments that focuses on privacy and mint-issued tokens. Iris includes `@cashu/cashu-ts` in its dependencies and the README names a Cashu wallet as a first-class feature. That puts Iris in a different lane from clients that only show Lightning zaps as a reaction button. The Nostr world has a habit of gluing money onto social actions. Iris goes further by making private digital cash part of the app stack. For a reader, the practical question is not "does this sound futuristic?" The question is whether a social client can make small payments feel native without turning the whole product into a wallet app. Iris is one of the projects taking that question seriously.
Private messaging is another place where the details matter. The project describes secure DMs, and the package includes `nostr-double-ratchet` alongside `nostr-tools`, `nostr-wasm`, `@noble/curves` and `@noble/hashes`. The FAQ also keeps the privacy line sober: only the message content is encrypted on Nostr, while metadata such as sender, recipient and timestamp remains visible. That one sentence is worth more than a page of security theater. If you use Iris for sensitive communication, understand what is hidden and what is not. If you use it for everyday Nostr messages, Iris is doing the right thing by making encryption part of the product without pretending metadata has vanished.
The app also supports NIP-05 style identity in a very user-facing way. The FAQ describes `username@iris.to` identifiers, search with NIP-05 names, and profile URLs that can resolve by username or identifier. That is important onboarding work. A public key is a real identity, but it is not a pleasant business card. Iris helps the reader move between human names and cryptographic names. That bridge is exactly where mainstream Nostr either becomes friendly or stays a hobby shelf.
The code tells a bigger story
The current Iris repo is a Vite and React application with TypeScript, Tailwind-related tooling, a service worker, workers, stores, contexts, pages, navigation and test files. The dependency list is revealing. `nostr-tools`, `nostr-wasm` and `nostr-social-graph` tell you where the Nostr work lives. `@cashu/cashu-ts` points to wallet support. `dexie` and `localforage` point to local storage. `vite-plugin-pwa`, Workbox packages and service worker files point to the progressive web app side. `hls.js`, `blurhash`, `leaflet`, `qrcode`, `emoji-mart` and `markdown-to-jsx` hint at the breadth of the interface: media playback, image placeholders, maps, QR flows, emoji and rich text rendering are all in scope.
The README says Iris can be packaged as a Tauri app for desktop, Android and iOS. The GitHub release page backs up the desktop part with installers and packages for Windows, macOS and Linux: MSI and EXE for Windows, DMG builds for macOS on both Intel and Apple Silicon, plus AppImage, Debian and RPM packages for Linux. That means iris.to is the visible front door, but the project is not treating the browser as the only place Iris should live.
The development commands are also worth noticing. The repo uses pnpm, Vite, TypeScript builds, linting, type checking, Playwright tests, performance tests, Lighthouse scripts and a local dev relay command. That is the shape of a serious client, not a weekend landing page. It does not guarantee that every feature is finished or that every privacy promise is perfect. It does mean the project is carrying real app machinery: build discipline, test surfaces, release artifacts and a source trail that can be inspected.
Iris also has a small but fascinating infrastructure wrinkle: the GitHub README says main development is on decentralized git at `git.iris.to`, and the package metadata lists the repository, homepage and issue tracker there rather than on GitHub. GitHub remains a convenient mirror and release surface. The primary trail points toward an Iris-hosted, Nostr-adjacent code flow. For a Nostr app, that is more than aesthetic. It says the project is trying to move not only posts and profiles, but also parts of development culture, toward more portable systems.
The key question
The biggest Iris question is the same question every web Nostr client has to face: how will you handle your key? The FAQ says you can log in with an nsec, an npub for read-only use, or an extension such as Alby or nos2x through `window.nostr`. It also warns that if you lose your private key, the account is gone, and that a hacked server, DNS compromise or XSS bug could serve malicious code that steals a private key. That is not a footnote. That is the adult part of the app.
For most readers, the cleaner habit is to use an external signer when possible. Let Iris be the client. Let a signer hold the signing power. If you are only exploring, an npub login lets you view without changing anything. If you enter an nsec into any web app, you are taking on a different risk. Iris deserves credit for documenting the risk clearly. You still have to act on it.
So who should use Iris? Use it if you want a web-first Nostr client that feels approachable but is not shallow. Use it if you care about feeds shaped by your social graph, usernames that humans can say out loud, a client that can cache enough to feel less fragile, and an app that experiments with Cashu rather than treating value as a sticker on posts. Use it if you want to see what happens when a Nostr client grows from "simple web client" into a fuller social system.
Do not use Iris because the word decentralized sounds virtuous. Open it because it is trying to solve a real reader problem: how do you make an open social network feel like a place you can actually live in for a while? That is the interesting version of Iris. Not the icon. Not the catalog sentence. The app that says your social graph should travel with you, your client should not depend on one relay, your messages deserve better handling, and your browser can be more than a window into somebody else's server.
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.
- Iris official web app
- irislib/iris-client on GitHub
- Current Iris README
- Iris package metadata and dependencies
- Iris App v2.3.1 release
- Iris FAQ
- Older iris-messenger repository pointing to the current source
- irislib GitHub organization
- Cashu project background
- NostrApps listing for Iris
- 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
- NIP-46 remote signing
- NIP-51 lists and mute lists
- NIP-56 reporting
- NIP-57 lightning zaps
- NIP-65 relay list metadata
