Nostr’s Relay Groups Gain Subgroups and Message Pinning

Nostr’s relay-based group standard, NIP-29, has gained two building blocks familiar to users of conventional community platforms: nested spaces and pinned context.

On July 16, the NIPs repository merged the subgroup specification. A group can now declare a parent and children in its metadata, allowing clients to assemble a hierarchy on a single relay. In practical terms, a community could present distinct rooms for topics, projects, or local chapters without making them appear as entirely unrelated groups.

The design is deliberately narrow. A subgroup remains a normal NIP-29 group with its own metadata, moderation events, and group identifier. Membership does not cascade from a parent into its children, and an administrator of a parent has no automatic authority in a subgroup. That separation matters for communities that use smaller rooms for sensitive discussions, contributor coordination, or gated access.

Message pinning arrived through a July 15 merge. The standard adds a moderator action, kind:9010, that submits the complete ordered pin list, and a relay-generated kind:39005 event that mirrors the latest accepted list. One update can therefore pin, unpin, reorder, or clear content. A July 17 follow-up also permits addressable events in the list, so pins are not limited to ordinary message IDs.

For builders, the important change is not a new social app but a more explicit interoperability target. A relay that supports subgroups should advertise that capability through its NIP-11 information document. Clients can then render a community tree and, where supported, expose the relay’s pinned context instead of inventing incompatible local conventions.

Two limits are material. First, NIP-29 is a draft, optional standard; relays and clients can choose not to support the new subgroup and pinning behavior. Second, NIP-29 relies on a hosting relay to enforce membership and moderation; a relay-based group is not trustless, and migration or forking can create competing group histories.

That makes this a useful protocol advance, not a guarantee of a uniform user experience. Teams adopting it should test the specific relay and client combination they intend to use, clearly show the hosting relay, and avoid implying that membership or moderator powers automatically carry across a community tree.