Nostr

1 Trajectory

Despite early buzz when Will Casarin launched Damus and Jack Dorsey perversely hyped it on Twitter, overall use seems to have plateaued. A 2025 review found roughly 21,000 total users and 3,700 daily active users. That’s serious growth from its 2021 origins, but tiny next to Mastodon, Bluesky, or Discord, where individual servers can have tens of thousands of users.

Possibly this is because most people don’t care about censorship resistance or confidentiality, and the ones who do cannot achieve critical mass. Or maybe abstruse crypto protocols are too hard to work with and the development cycle is just too boring to build hype?

There has been a huge increase in profiles with Lightning Network addresses, reflecting Nostr’s close ties to cryptocurrency and micropayments. This would, in theory, lead into a virtuous cycle of content creation feeding into more content creation. Indeed, long‑form posts and articles jumped by 800%.

It’s not massive though, is it? We are probably witnessing the classic cold start problem (a.k.a. the no-network effect): creators go where the audiences are, and audiences go where creators are. Copy‑pasting our posts to yet another microblogging app is a chore with little return. Additionally, the fear of being censored has waned since 2020; most people have moved on and simply don’t see the point. If censorship resistance isn’t a killer app, what is?

2 Lightning payments?

The Lightning Network is a “layer‑2” protocol that sits on top of Bitcoin and allows high speed, low‑cost transactions while maintaining Bitcoin’s security. Some Nostr clients support Lightning, which allows people to “zap” posts or profiles—sending small amounts of bitcoin as a tip—without leaving the app. Damus markets this as “Free speech meets free money”. Profiles can also include Lightning addresses and many clients now embed wallets or support services like Nostr Wallet Connect. This seems to be the deepest connection to cryptocurrency in this ecosystem.

3 Implementations

There is no single “killer app” for Nostr. Developers are still experimenting with the look and feel of their clients, and user interfaces range from bare‑bones feeds to Instagram‑style photo apps. Clients like Primal (Twitter‑like), Olas (Instagram‑like) and Yakihonne (Substack‑style) are all exploring different approaches. None of these apps feel like they have a compelling value proposition over Twitter, Instagram, or Substack unless you are really invested in the backend that makes it happen.

Early adopters often run several clients because each has strengths and weaknesses. Some apps favour mobile convenience, others focus on desktop or web, and most still require users to manage their own keys and relay lists.

But the overall feel remains that Nostr clients are for tinkerers and enthusiasts rather than mainstream users. If you’re willing to experiment, you can piece together a mid 2010s experience.

My research agent recommended the following clients for me to test, but I got worried I was yak shaving and stopped myself after the first two.

For more, see nostr.net (source: aljazceru/awesome-nostr). It’s a collection of projects and resources built on Nostr to help developers and users find new things.

4 Groups in Nostr

That is the thing I actually want. I don’t care about Instagram clones or whatever.

What I actually want is a way of organising a group where we don’t need to worry about central servers. Does Nostr support that? Sorta.

AFAICT Nostr itself is not “a group chat protocol” in the same clean way it is a pub/sub feed network; group chat is layered on top of it in some confusing, unconverged set of ways.

Nostr gives us primitives we can in principle build group chat with– identities, relays, signed events. That’s enough for public posts and also enough to transport private or group messages, but it does not by itself define a canonical “group chat” or “DMs”. In practice, that means clients can implement messaging in different ways, and the user experience depends heavily on which client and which messaging scheme they use.

NIP-29 is the “relay-based groups” approach. A special relay node hosts the group’s state: membership, moderation, visibility rules, and group metadata. A group is identified in practice by a relay plus a group id. The relay is not just a dumb mailbox — it has authority over who is in the group, decrees and enforces consistent state etc.

That gives us “forum-like” or “server-hosted group room” behaviour, but it is not the trustless encrypted group-messaging system that we signed up to Nostr for. The relay can enforce permissions and moderation, and clients reconstruct the group from the relay’s history and metadata.

Marmot is another way of doing groups, at a different layer of the protocol: that does give us end-to-end encrypted group messaging on Nostr, using “MLS”-style group key management on top of Nostr identity and relay transport.

It looks fragmented to me, i.e. not seamless because you may have to care about relays, client support, group compatibility, and whether the group is NIP-29-based or uses a different encrypted-messaging scheme. For groups, things are tricky because membership, discovery, moderation, and encryption are all separate design problems, and different Nostr clients solve them differently.