Gossip: a desktop nostr client that follows people across relays

The problem: social media where you hold the account

Nostr is an open social media protocol empowering lots of software such as this client. The documentation describes the experience as kind of like Twitter except that you control your own account, and you can post to many different independent places called relays. Nostr stands for Notes and Other Stuff Transmitted by Relays.

That is a small protocol with large consequences. There is no account to register and no server to hold your key, and a post is signed by you and handed to whichever relays accept it. The trade is that nothing in the protocol guarantees delivery, and a client has to work out where the content you want actually is.

Gossip is a desktop client for nostr, and the documentation is quick to place it: people are finding many additional uses for nostr that go far beyond micro-blogging or chatting, but this client is focused on those.

The audience is therefore people who want the micro-blogging and chat use case, on a desktop, with a client that has opinions about how a feed should be assembled and about what a client should and should not load into memory. The project is MIT licensed, with the licence text in LICENSE.txt, the repository is not archived, and the last push was on 2026-10-17. The published releases are v0.14.0 from 2025-03-16, v0.13.0 from 2024-12-20 and v0.12.0 from 2024-09-30.

The Gossip Model: following people, not reading a feed

The first of the points of difference is the relay selection strategy, and it is the one the project is named after.

Gossip never used a simple list of relays. From day one it tried to find posts of the people that you follow wherever they are most likely to be, based on those people's relay lists as well as half a dozen other heuristics. Today multiple clients use a similar model, focused around NIP-65.

The mechanics are worth spelling out because they are unusual. Gossip connects to all the relays necessary to cover everybody you follow, while also trying to listen to the minimum number of relays necessary to do that, which matters because there is overlap between relays and because people generally post to multiple relays. It also dynamically adjusts to relays being down or disconnecting.

So the model is a set calculation rather than a subscription list. You follow people; the client works out the smallest set of relays that plausibly covers those people; it connects to that set, and it reconnects as the set changes or as relays fail. The cost is that the client has to know, and read, the relay lists of everyone you follow, and the benefit is that you are not silently missing posts because the person you follow happens to post somewhere you were not subscribed.

For a user, that is the difference between a feed that feels alive and one that feels half empty, and it is also the difference between a client that has to be reconfigured every time you follow somebody new and one that does not.

Key handling and the refusal to ship a browser engine

The second point of difference is the security posture, and it comes in two parts.

The first is key handling. Gossip handles private keys as securely as reasonable, short of hardware tokens, keeping them encrypted under a passphrase on disk, requiring that passphrase on startup, and zeroing memory before freeing it. The documentation adds that this should not really be a point of difference, but few other clients bother. The zeroize crate in the dependency list is the mechanism behind the memory clearing, and requiring the passphrase at startup means the key is not sitting decrypted in memory while the application is idle.

The second is the refusal to use web technologies. Gossip avoids them, other than the HTTP GET and WebSockets that nostr itself requires. The argument is that the web stack is huge, complex and probably full of undiscovered vulnerabilities, presenting as a huge attack surface, and that this includes JavaScript, the many and ever-expanding set of web technologies built into browsers and accessible through JavaScript, and even HTML parsing, rendering and CSS.

The documentation is careful to argue that this is not pedantic. People have already had their private key stolen from other nostr clients. Gossip uses simple OpenGL-style rendering instead, and the documentation concedes the trade: it is not as pretty, but it gets the job done.

The performance claim follows from the same decisions, using the LMDB database, the Rust language and coding architectures with performance always in mind, with the observation that unless you have quite old hardware, the network speed will probably be your bottleneck. The user control story is 70 different settings at the time of writing, with a reasonable default chosen where the right value is uncertain and a mechanism provided to change it.

Moderation and curation that live in the client

The documentation describes several mechanisms for moderating and curating what you see, and notes that some leverage the work of other people such as community moderators, friends and relay operators, while others put you in charge, and that in the latter case you will be seeing the content in order to moderate it, so the client does not completely insulate you from the content.

The mechanisms are concrete. Lists let you define lists of people and view only what those people have posted, rather than global content. Muting works on individual people, and the mute list can be shared with other clients you use. Thread dismissal hides a post and all the replies to it, although that is temporary until the client restarts. Content warnings are shown and you must approve to see the content, and you can also place content warnings on your own posts.

The two more interesting ones are the spam filtering script and the SpamSafe relay designation. Gossip provides a hook to filter posts via a script that you can program to do whatever you want, and the repository ships a filter.example.rhai with a configuration document. And when the SpamSafe setting is enabled, notes from unknown persons are only fetched from relays that you have marked as SpamSafe, which turns the relay list into a moderation control rather than a routing detail.

The last one is the ephemeral relay feeds. Global relay feeds are ephemeral and the content disappears when you quit Gossip, and neither the notes nor the media are saved permanently to your computer.

One gap is acknowledged openly. The author intends gossip to support one of the multiple competing standards for labelling and reporting content, with the options currently being NIP-32, NIP-56 and NIP-72, but none of these are defined well enough to be useful yet, and the goal of subscribing to a set of moderators you trust is left as a future intention.

The repository is idle, and the fork is the live one

The first section of the project documentation is the one every prospective user should read, and it is not a status update in the usual sense.

The repository is idle. The author says he has not had time to spend on nostr development for many months, and that the repository has become idle.

He then points elsewhere. YGGverse has continued development on a fork, which he approves of but cannot vouch for since he has not had time to look at it. As far as he knows it is the only active and continuing development on gossip. The fork's author cannot promise to continue developing it, maintaining it or providing support, but it has more features than the original repository. So go and have a look.

That is a more useful statement than a maintenance badge, because it names a specific fork and it says exactly what the author does and does not stand behind. The approval is of the fork as a direction, and the refusal to vouch for it is about the fact that the author has not read the code. If you are evaluating gossip, the fork is the artefact with a future, and this repository is the reference implementation with a documented history and a design rationale.

The dates are consistent with that reading. The last release here is v0.14.0 from March 2025, while the last push was in October 2026, which is consistent with someone tidying up rather than releasing.

For anyone tempted to build on this code, the sensible move is to read the fork, not the original, and to keep the design rationale in this repository as the reference for why the client works the way it does.

The Rust workspace, the patched dependencies and the split backend

The repository layout shows the shape of the project. The workspace members are gossip-lib, gossip-bin and gossip-cache, and the directories add gossip-gtk, a fonts directory, a logo directory, assets, a packaging directory, a build.sh, a flake.nix for Nix builds, a .cargo directory and a .dockerignore.

The dependency list is where the interesting choices are. There is bech32 for the key and identifier encoding that nostr uses, blurhash and image for handling images, nostr-types pulled from a git repository at a pinned revision with the speedy, client and nip46 features, tokio with the full and tracing features, serde and serde_json and speedy for the two serialisation stacks, url, paste, tracing and zeroize.

Two details deserve attention. The nostr-types dependency is not a crates.io release but a git reference at a fixed revision, which means the protocol types are pinned to a specific commit of a personal repository. And the manifest patches egui and eframe from crates.io with forks hosted by the same author, at pinned revisions. Both are ordinary things to do in a project that depends on unreleased protocol work, and both are the kind of thing to check when you audit a dependency list.

The profiles are tuned with the same care. The dev profile sets opt-level 1 for the workspace crates to keep compiles fast, while dependencies are compiled at opt-level 2 because they rarely recompile, and scrypt gets opt-level 3 with debug assertions and overflow checks off, with a comment explaining that scrypt needs optimization or it takes too long.

The contribution note explains the crate split: the project was split into two crates, lib and bin, to make it easier to build a different UI onto the backend. That is an invitation, and the documentation says anyone interested in replacing the GUI with something much better, or keeping it as egui but making it much better, would be greatly appreciated.

Where Gossip is the wrong tool

The client is a good fit for one specific person and a poor fit for several others.

It fits someone who wants a desktop nostr client, cares about the key handling story and about not running a browser engine, and is willing to read a client that is not a polished product. The privacy options point the same way: use it over Tor, and the documentation recommends QubesOS, Whonix, Tails or torsocks, and Gossip supports native TLS certificates so you can configure trust for .onion sites, with options not to load avatars or images and not necessarily to share who you follow.

It does not fit someone who wants a mobile client, since it is designed to run on desktop computers on Windows, macOS and Linux. It does not fit someone who wants a full moderation and reporting stack today, because the labelling and reporting standards are not yet defined well enough to be useful. And it does not fit someone who needs a maintained project with a support commitment, which is the plain content of the idle notice.

The practical reading is that Gossip is now a well documented design reference with a usable implementation, and the live work is elsewhere. If your interest is in the ideas, the documentation here is the better source, because the author explains the reasoning. If your interest is in running a client today, look at the fork. If your interest is in the code, the split into a library and a binary means you can build a different interface onto the backend without rewriting the protocol handling.

Editorial conclusion

Adopt Gossip if you want a desktop nostr client with a stated position on key safety, on not shipping a browser engine, and on how a feed should be assembled, and if you are prepared to read the code rather than expect a polished product. Do not adopt it expecting an actively maintained client, because the author states the repository is idle and points to a fork he cannot vouch for. Before you build on it, read the installation and usage document, check the NIP support list against the protocol features you need, and treat the YGGverse fork rather than this repository as the thing to evaluate.

Frequently asked questions

Official sources

1. Issues
2. mikedilger/gossip on GitHub
3. README
4. Releases