Nostr mute lists: block spam once, everywhere

How NIP-51 mute lists (kind 10000) sync across clients, public vs private mutes, why mutes don't sync, and trust-based spam filters.

Penny

31. Oktober 2026October 31, 2026 · 4 Min. Lesezeit4 min read

Nostr mute lists: block spam once, everywhere

Spam and reply-guys are part of any open network, and Nostr is no exception. The good news: on Nostr, a mute isn't a setting buried in one app. It's a signed event that lives on relays, so when you mute someone in one client, every other client that reads your mute list respects it too. Here's how it works, where it breaks, and how to set it up so it actually follows you.

The mute list is an event (kind 10000)#

NIP-51 defines "lists" as Nostr events. Your mute list is kind 10000, a replaceable event: there's only ever one current version per key, and each update replaces the previous one. It can hold four kinds of entries:

Because it's a normal signed event, any client can load it from your relays. Mute a spammer in Amethyst on your phone and the same account disappears in a web client later, as long as both clients find the event.

Public vs private mutes#

A mute list has two parts:

If you'd rather not broadcast who you muted, choose the "private" option when your client offers one. Not every client does; some write everything as public tags.

Why your mutes sometimes "don't sync"#

  1. The list only lives on a few relays. If the client you muted from wrote kind 10000 to relays your other client doesn't read, the second client never sees it. Fix: make sure your relay list (kind 10002, see my outbox-model guide) includes a couple of large relays, then re-save the mute list (mute and unmute someone) so it gets republished.
  2. Overwrites. Kind 10000 is replaceable. If an old client has a stale copy and you mute someone there, it can publish its old list plus one entry and wipe mutes you added elsewhere. After switching apps, check that your mute count looks right before muting anything new.
  3. Unsupported entry types. Some clients honor muted pubkeys but ignore muted words or hashtags, or can't decrypt private entries. The mutes aren't gone; that client just can't use them.
  4. Remote signers. With a NIP-46 signer or a browser extension, the client has to ask the signer to decrypt your private mutes. If the signer refuses or is offline, private mutes silently stop working in that session.

Beyond manual mutes: trust-based filtering#

Manual muting doesn't scale against throwaway spam accounts. Many clients now offer filters based on your social graph:

These complement your mute list. Your kind 10000 still matters: it's what other clients and trust services read.

Checklist#

  1. Mute a few obvious spammers in your main client, then open a second client and confirm they're muted there too.
  2. If not: check your relay list, add one or two big relays, re-save the mute list.
  3. Use private mutes for people (as opposed to bots) if your client supports them.
  4. Add muted words sparingly. Broad words hide more than you expect.
  5. Turn on follows-of-follows (or web-of-trust) notification filtering if your client has it.
  6. After switching clients, check your mute count first, so a stale copy doesn't overwrite your list.

Related: my guides on switching clients, the outbox model and the Nostr privacy checklist.

Found this useful? Zaps welcome. My Lightning address is in my profile.

#nostr#privacy#spam

Written by

Comments

No comments yet. Start the conversation.

Contents

5 sections

  1. The mute list is an event (kind 10000)
  2. Public vs private mutes
  3. Why your mutes sometimes "don't sync"
  4. Beyond manual mutes: trust-based filtering
  5. Checklist