Week in Review: NIP-29 Groups Gain Pinning, Subgroups, Invites and a Banner

Message pinning arrives first (#2379)

The earliest of the five, merged 2026-07-15, #2379 adds message pinning to NIP-29. It introduces an update-pin-list moderation action alongside a new event kind, kind:39005, for tracking which messages a group's admins have pinned. This is the smallest conceptual addition of the week, but it is also the one the last PR in the batch, #2416, comes back to extend two days later.

An invite code format for group identifiers (#2380)

#2380 adds a suffix format that lets a group identifier carry an invite code. At 8 added lines, it gives NIP-29 groups a spec-level way to distribute an invite as part of the identifier itself rather than as an out-of-band link.

Subgroups: the largest change of the week (#2319)

#2319 is the structurally largest of the five, at 62 added lines, and it is the one that does the most to change how groups relate to each other. It adds a Subgroups section to NIP-29, letting groups be organized hierarchically. It does this without introducing any new event kind: it reuses the existing kind:39000 (group metadata) and kind:9002 (edit-metadata) and adds two tag names, parent and child.

A parent tag on a group's kind:39000 event points at the parent group's d identifier. No parent tag means the group is a root with no parent, and an edit-metadata event submitted with no parent tag is how a group gets detached back to root. Clients are expected to build the group tree locally by reading kind:39000 events rather than querying a dedicated hierarchy endpoint.

Parenting, re-parenting, and promoting a group back to root all happen through a kind:9002 edit-metadata event. The relay is responsible for keeping both sides of the relationship in sync: when a group's parent changes, the relay updates the child tags on the old and new parent's kind:39000 events to match. The parent's kind:39000 must list every one of its children as an ordered ["child", "<id>"] tag, and the spec has relays reject metadata edits that would silently drop an existing child. Since order comes from tag position, admins can rearrange the listed order of their children.

The relationship is relay-enforced rather than negotiated between clients. A kind:9002 event that sets ["parent", "X"] is rejected unless its author is also an admin of group X, per that group's kind:39001 admin list. Because editing the child group already requires being an admin of the child, both the parent and the child side must independently consent to the link before a relay will honor it. The spec also has relays reject cycles, including a group listing itself as its own parent, closing off the kind of malformed tree a purely client-side check could miss.

A banner tag for group metadata (#2383)

#2383 adds a banner tag to the kind:39000 group metadata event. At two lines added and one removed, it is the smallest diff of the five, giving groups a spec-level place to declare a banner image alongside whatever metadata they already carry, such as name and picture.

The pin list learns to reference addressable events (#2416)

#2416, merged at 00:01:30 UTC on July 17, returns to the pin list that #2379 introduced two days earlier. It extends the format so the list can also hold a tags, the NIP-01 convention for referencing addressable events by kind, pubkey and d identifier, alongside the e tags it already supported for referencing regular, non-addressable events.

What the week adds up to

None of these five pull requests is large on its own, and the sources do not say why the maintainers took them up together or what happens next. What it does show is the shape of the work: in three days, NIP-29 gained a way to pin messages, a way to invite by identifier, a way to nest groups inside other groups, a way to set a banner, and a broadened pin list to tie back into the first change. That is a specification actively filling in the features a group chat protocol needs once people start asking for them.