Kind 1 Replies Should Be Comments, Even Though It Breaks Things

Last night someone asked me why they weren't seeing replies everywhere anymore. Their feeds were "bonkers." The answer is a single number: 1111.

On Nostr, a reply to a blog post is a NIP-22 comment, kind 1111. So is a reply to a video, a picture, a livestream, or a git patch. A reply to a short text note, the thing most of us post every day, has always been another kind 1 note under NIP-10. Several clients have started replying to notes with kind 1111, and the clients that haven't caught up don't show those replies at all.

There's an open proposal to make this official: PR #2447, "NIP-10: kind 1 replies SHOULD be kind 1111." I support it, and I said so on the PR. The pushback is real, though, and some of it comes from people I respect a lot. So I went through the GitHub history, the client source code, and a day of relay data. Here's the case for it, the case against it, and why I still think it's worth breaking things for.

Where things stand today

The specs. In May 2023, Alex Gleason opened issue #523 asking for a way to fetch top-level notes without replies. Nostr filters can't express "events without an e tag," so a client can't ask for that. The issue is still open. In August 2026, PR #2358 removed the line in NIP-22 that said "Comments MUST NOT be used to reply to kind 1 notes." PR #2447 goes further: it says replies to kind 1 SHOULD be kind 1111, and it moves kind 1 replies into a "deprecated" section of NIP-10. It is a bigger change than one word.

The clients. I checked the source code of each client, not just what people say about them:

• Always reply with 1111: Ditto, Coracle, Snort, and the Mostr bridge (whenever it knows the parent note).
• Reply with 1111 depending on the root post: Amethyst does it when you reply directly to a root note posted from Amethyst. Jumble ImWald does it when the parent note came from a client on its list of 1111-capable apps. Otherwise both use kind 1.
• Show 1111 replies, but reply with kind 1: Jumble, YakiHonne web, and Primal's iOS app. Iris and Nostur show some of them.
• Don't show 1111 replies on notes at all: Damus, Primal web and Android, Nostrudel.

The relays. I pulled kind 1111 replies to kind 1 notes from relay.primal.net. The relay's 500-event cap hit in about 18 hours. Most came from Amethyst (211) and Ditto (181). In the same relay's kind 1 stream, about 17% of notes are replies, which works out to roughly 10,000 kind 1 replies over the same 18 hours. So 1111 is still somewhere around one reply in twenty. It's one relay and a rough sample, but it's enough to show where things stand: early, growing, and already big enough that people notice missing replies.

The case for 1111

You can finally filter. Under NIP-22, kind 1 holds top-level notes and kind 1111 holds replies. "Notes only" becomes kinds: [1]. "Notes and replies" becomes kinds: [1, 1111], still one subscription. "Replies only" becomes possible. Gleason put it plainly in #2250: "I want to filter my feed so it shows replies only. Is that so much to ask?" Today the answer is yes, it is too much to ask, and #523 has been open for three years because of it.

Threads are easier to load. Every 1111 carries its root in the uppercase E, K and P tags. The whole conversation under a note, at any depth, is one query: {"kinds": [1111], "#E": ["<root id>"]}. With kind 1, markers are optional, positional e tags from the early days still exist, and deep replies often point only at their parent. Every client has its own pile of guesses for rebuilding a thread.

One threading model for everything. NIP-10 already says "Kind 1 replies MUST NOT be used to reply to other kinds, use NIP-22 instead." Kind 1 is the last kind on Nostr that replies with itself. If everything uses 1111, a client writes one thread component and it works for notes, articles, videos and whatever kind gets invented next year.

Conversations stop being split by app. When a friend comments on a video or an article, that comment is a kind 1111 text event. A text-first client can show it with a link to the thing being discussed. It doesn't need to render video or build a blogging UI. One reply kind means every app that shows text can show the whole conversation layer of Nostr. A comment from someone you follow is one of the best ways to discover people and content, and today most clients drop most of them.

The case against 1111

This is where I want to be fair, because the people raising these points know what they're talking about.

It breaks clients that aren't being actively developed. When Vitor said "Let's move kind:1 replies to become root only. When can we start?" in May 2025, staab replied: "Guys, are we really demonstrating that the level of discipline we have for backwards compatibility is 0? I'd like to move too, but it's a pretty big screw you to anyone who isn't actively developing their client." (source). He's right. Some clients haven't been updated in months. Their users will miss replies, and they won't know why.

Developers who want to move are waiting on the big clients. Dr. The Daniel, who builds Sidecar, said it plainly last night: "What's stopping me from defaulting to kind1111 for all replies right now is knowing how long it will take for Damus and Primal (among others) to come around. I don't want my users' replies to not be seen by more than half of the clients." (note). Damus has no kind 1111 support at all, and its issues for NIP-22 threads were closed as not planned in February.

Clients have to support kind 1 replies anyway. Semisol asked: "Why break backwards compatibility? If clients have to show kind 1 replies anyway, why use 1111?" (note). Years of kind 1 replies already exist on relays and will never change. Any client that shows old threads has to read NIP-10 forever. During the transition, every client carries both code paths.

Not everyone wants a single answer. On PR #2447, arthurfranca argued for keeping both: kind 1 when you want a reply to also show up in your followers' feeds, kind 1111 when you don't. His summary: "supporting both kind:1 and kind:1111 replies forever is the way."

The relay-side fix was rejected. The other way to solve #523 is to give relays "absence" filters. fiatjaf rejected that in 2025, and I think he was right: "Indexing for absence of arbitrary tags is probably impossible to do so any such change would create unnecessary brutal inefficiency for relays."

Why I think it's worth breaking

That last quote matters, because of what fiatjaf said next in the same comment: "The best thing we can do (and that we're slowly doing, I think) is to move replies to kind:1111 and leave kind:1 for just root posts" (source). Back in 2023 he wrote: "in retrospect I also think it would have been better to use a different kind for replies, but I wouldn't want to change that at this point" (source). The creator of the protocol thinks kind 1 replies were a mistake. The debate has always been about when and how to fix it.

The break is already happening. Ditto, Coracle, Snort and Mostr publish 1111 replies to notes today, and Amethyst does it for its own threads. Merging #2447 or not, those replies exist and some clients can't see them. Leaving the spec as it is doesn't avoid the split. It just means the specs describe a network that no longer exists.

Fixing it is mostly a rendering job. For a client that doesn't show 1111 yet, the most important step is to fetch #E for kind 1111 alongside kind 1 replies and show them in the thread. Primal's iOS app already does this. The work is real for some codebases, but it's additive. Nothing about reading kind 1 stops working.

Nostr has done this before. NIP-04 DMs are marked "unrecommended: deprecated in favor of NIP-17." That broke DMs between clients for a while, and it was the right call because NIP-04 leaked metadata. Positional e tags were deprecated in favor of marked tags. NIP-65 outbox relays had the same "nobody will move first" problem for years. Each time, someone moved first, the rest caught up, and the protocol got better. Waiting until every client is ready means waiting forever, because some of them will never update.

The end state is better for everyone. Semisol's question has a real answer. The payoff isn't during the transition, where everyone carries both paths. It's after: when new replies are 1111, kind 1 means "a note," filters can say what clients mean, and every app shares one conversation layer. Old kind 1 threads stay readable forever, just like old NIP-04 DMs.

How to break it well

Breaking user space is bad. Ignoring it is bad too. What I'd like to see is a deliberate transition, not a flag day:

1. Render first, everywhere. Every client should show kind 1111 replies under kind 1 notes, fetched by the uppercase #E tag so deep replies aren't missed. This step breaks nothing and fixes the "missing replies" problem for users right away. It's the most useful thing Damus, Primal web and Android, and Nostrudel could do this month.
2. Publish 1111 carefully during the transition. Amethyst and Jumble ImWald show a good way to do it: reply with 1111 when the thread started in a client that can show it, and fall back to kind 1 otherwise. My own preference is to default to 1111 for direct replies to a note, and to keep using kind 1 when replying inside an existing kind 1 thread.
3. Keep reading kind 1 replies forever. Deprecated means "don't write it," not "don't read it."
4. Merge #2447 with that guidance in it. The PR already says legacy clients "may still produce" kind 1 replies and modern clients "may wish to query and display them." Spelling out render-first and a fallback rule would answer most of the objections above.

If you build a Nostr client, please weigh in on #2447, especially if you disagree. If you maintain Damus or Primal: start with rendering. It costs you very little, and your users stop missing replies from the rest of the network.

Nostr's promise is that the conversation doesn't belong to any one app. Right now the conversation is split by kind. Let's fix it on purpose, with a plan, together. Let's unite the clans. 🫂🤙🏻💜