NIP-29 definiert relay-basierte Gruppen, in denen ein Relay Mitgliedschaft, Berechtigungen und Nachrichtensichtbarkeit verwaltet.

Funktionsweise

Gruppen werden über einen Relay-Host plus Gruppen-ID adressiert, und das Relay ist die Autorität für Mitgliedschaft und Moderation. Von Nutzern erzeugte Events, die in eine Gruppe gesendet werden, tragen ein h-Tag mit der Gruppen-ID. Vom Relay erzeugte Metadaten nutzen addressable Events, die mit dem eigenen Schlüssel des Relays signiert sind.

Das zentrale Metadaten-Event ist kind 39000, während kinds 39001 bis 39003 Admins, Mitglieder und unterstützte Rollen beschreiben. Moderationsaktionen laufen über Events der 9000er-Serie wie put-user, remove-user, edit-metadata und create-invite.

Zugriffsmodell

  • private: Nur Mitglieder können Gruppennachrichten lesen
  • closed: Join-Requests werden ignoriert, sofern das Relay kein Invite-Code-Handling nutzt
  • hidden: Das Relay verbirgt Gruppenmetadaten vor Nichtmitgliedern und macht die Gruppe dadurch unauffindbar
  • restricted: Nur Mitglieder dürfen Nachrichten in die Gruppe schreiben

Diese Tags sind unabhängig voneinander. Eine Gruppe kann für alle lesbar, aber nur für Mitglieder beschreibbar sein, oder für Nichtmitglieder vollständig verborgen bleiben. Diese Trennung ist wichtig, weil Clients “private” nicht als pauschale Kurzform für alle Zugriffsregeln behandeln sollten.

Vertrauensmodell

NIP-29 ist kein trustless Gruppenprotokoll. Das hostende Relay entscheidet, welche Moderations-Events gültig sind, welche Rollen existieren, ob Mitgliederlisten sichtbar sind und ob alte oder aus dem Kontext gerissene Nachrichten akzeptiert werden. Ein Client kann Signaturen und Timeline-Referenzen prüfen, verlässt sich aber weiterhin auf die Relay-Policy für den tatsächlichen Zustand der Gruppe.

Das macht Migration und Forking möglich, aber nicht automatisch. Dieselbe Gruppen-ID kann auf verschiedenen Relays mit unterschiedlicher Historie oder unterschiedlichen Regeln existieren. In der Praxis ist die Relay-URL also Teil der Gruppenidentität.

Nützliche Implementierungshinweise

  • Clients sollten die Relay-URL als Schlüssel des Gruppenhosts behandeln. Eine Klarstellung im Januar 2026 machte das in der Spezifikation explizit und entfernte Mehrdeutigkeit gegenüber der Nutzung eines pubkey.
  • Gruppenstatus wird aus der Moderationshistorie rekonstruiert, während Events der 39000er-Serie informative Snapshots dieses Zustands sind.
  • Timeline-previous-Referenzen sind da, um aus-dem-Kontext-gerissene Rebroadcasts über Relay-Forks hinweg zu verhindern, nicht nur, um UI-Threading zu verbessern.

Jüngste Spezifikationsarbeit

  • PR #2310 und hodlbods Flotilla-1.7.3/1.7.4-Release-Notes schlagen kind-9-Wrapping für Nicht-Chat-Inhaltstypen vor, etwa Kalender-Events, Polls und andere Payloads, damit der Raumkontext erhalten bleibt, wenn diese Objekte in eine Gruppe gesendet werden.
  • PR #2319 erweitert die Spezifikation um eine Subgroup-Hierarchie, sodass eine einzelne Gruppe mehrere parallele Channels hosten kann, ohne unabhängige Gruppen auf demselben Relay anzulegen. Die Subgroup-ID nutzt das bestehende h-Tag mit, wodurch Single-h-Tag-Nachrichten für ältere Clients erhalten bleiben.
  • PR #2316 definiert explizite Berechtigungen auf dem kind-39003-Rollen-Event, sodass jede Rolle zu einer benannten Menge erlaubter Operationen wird, darunter invite, add-user, remove-user, edit-metadata, delete-event und add-permission, optional mit zeitgebundener Ablaufzeit.

Implementierungen

  • Flotilla ist hodlbods primärer NIP-29-Client. 1.7.3 und 1.7.4 lieferten kind-9-Wrapping, Polls, NIP-46-Login via Aegis-URL-Scheme, native Share-Unterstützung für Space-Invites, Raum-Erwähnungen, Bild-Einfügen aus der mobilen Zwischenablage, Drafts und Video in Calls.
  • Wisp fügte NIP-29-Gruppenkonfiguration für Flags, Invites, Rollen und AUTH-Prompts in PR #471 hinzu und härtete die AUTH-Sequenz vor Gruppen-Events 9021, 9007 und 9009 in PR #478.

Primärquellen:

Erwähnt in:

Siehe auch: