Wochenrückblick: NIP-29-Gruppen erhalten Pinnen von Nachrichten, Untergruppen, Einladungen und ein Banner

Nachrichten-Pinning kommt zuerst (#2379)

Der früheste der fünf, gemergt am 2026-07-15, #2379 fügt NIP-29 das Pinnen von Nachrichten hinzu. Er führt eine Moderationsaktion update-pin-list zusammen mit einem neuen Event-Kind ein, kind:39005, um festzuhalten, welche Nachrichten die Admins einer Gruppe angepinnt haben. Das ist die konzeptionell kleinste Ergänzung der Woche, aber auch diejenige, auf die der letzte PR der Serie, #2416, zwei Tage später zurückgreift.

Ein Einladungscode-Format für Gruppenkennungen (#2380)

#2380 fügt ein Suffix-Format hinzu, mit dem eine Gruppenkennung einen Einladungscode tragen kann. Mit 8 hinzugefügten Zeilen gibt es NIP-29-Gruppen eine Möglichkeit auf Spezifikationsebene, eine Einladung als Teil der Kennung selbst zu verteilen, statt als Link außerhalb der Kennung.

Untergruppen: die größte Änderung der Woche (#2319)

#2319 ist strukturell die größte der fünf, mit 62 hinzugefügten Zeilen, und diejenige, die am meisten daran ändert, wie sich Gruppen zueinander verhalten. Sie fügt NIP-29 einen Abschnitt zu Untergruppen hinzu, der es erlaubt, Gruppen hierarchisch zu organisieren. Das geschieht ohne ein neues Event-Kind: Es werden das bestehende kind:39000 (Gruppenmetadaten) und kind:9002 (edit-metadata) wiederverwendet, ergänzt um zwei Tag-Namen, parent und child.

Ein parent-Tag im kind:39000-Event einer Gruppe verweist auf die d-Kennung der übergeordneten Gruppe. Fehlt das parent-Tag, ist die Gruppe eine Wurzel ohne übergeordnete Gruppe, und ein edit-metadata-Event ohne parent-Tag ist genau das, was eine Gruppe wieder zur Wurzel löst. Clients sollen den Gruppenbaum lokal aufbauen, indem sie kind:39000-Events lesen, statt einen eigenen Hierarchie-Endpunkt abzufragen.

Das Setzen, Ändern oder Zurücksetzen einer übergeordneten Gruppe geschieht über ein kind:9002-edit-metadata-Event. Der Relay ist dafür verantwortlich, beide Seiten der Beziehung synchron zu halten: Ändert sich die übergeordnete Gruppe, aktualisiert der Relay die child-Tags sowohl der alten als auch der neuen übergeordneten Gruppe in deren kind:39000-Events. Das kind:39000 der übergeordneten Gruppe muss jedes ihrer Kinder als geordnetes ["child", "<id>"]-Tag auflisten, und die Spezifikation lässt Relays Metadaten-Änderungen ablehnen, die ein bestehendes Kind stillschweigend entfernen würden. Da die Reihenfolge aus der Tag-Position stammt, können Admins die Reihenfolge ihrer Kinder ändern.

Die Beziehung wird vom Relay durchgesetzt, nicht zwischen Clients ausgehandelt. Ein kind:9002-Event, das ["parent", "X"] setzt, wird abgelehnt, sofern sein Autor nicht auch Admin der Gruppe X ist, gemäß der kind:39001-Admin-Liste dieser Gruppe. Da das Bearbeiten der untergeordneten Gruppe bereits Admin-Rechte für das Kind voraussetzt, müssen beide Seiten der Verbindung, übergeordnete und untergeordnete Gruppe, unabhängig voneinander zustimmen, bevor ein Relay sie akzeptiert. Die Spezifikation lässt Relays außerdem Zyklen ablehnen, einschließlich einer Gruppe, die sich selbst als eigene übergeordnete Gruppe angibt, und schließt damit die Art von fehlerhaftem Baum aus, die eine rein clientseitige Prüfung übersehen könnte.

Ein Banner-Tag für Gruppenmetadaten (#2383)

#2383 fügt dem kind:39000-Gruppenmetadaten-Event ein banner-Tag hinzu. Mit zwei hinzugefügten und einer entfernten Zeile ist es der kleinste Diff der fünf und gibt Gruppen einen Platz auf Spezifikationsebene, um ein Banner-Bild neben den bereits vorhandenen Metadaten wie Name und Profilbild anzugeben.

Die Pin-Liste lernt, auf adressierbare Events zu verweisen (#2416)

#2416, gemergt um 00:01:30 UTC am 17. Juli, greift die Pin-Liste auf, die #2379 zwei Tage zuvor eingeführt hatte. Er erweitert das Format so, dass die Liste zusätzlich a-Tags enthalten kann, die NIP-01-Konvention zum Verweisen auf adressierbare Events über Kind, Public Key und d-Kennung, zusätzlich zu den bereits unterstützten e-Tags für Verweise auf gewöhnliche, nicht adressierbare Events.

Was die Woche zusammenfasst

Keiner dieser fünf Pull Requests ist für sich genommen groß, und die Quellen sagen nicht, warum die Maintainer sie zusammen angegangen sind oder was als Nächstes kommt. Was sie zeigt, ist die Form der Arbeit: In drei Tagen erhielt NIP-29 eine Möglichkeit, Nachrichten anzupinnen, eine Möglichkeit, per Kennung einzuladen, eine Möglichkeit, Gruppen ineinander zu verschachteln, eine Möglichkeit, ein Banner festzulegen, und eine erweiterte Pin-Liste, die sich auf die erste Änderung zurückbezieht. Das ist eine Spezifikation, die aktiv die Funktionen füllt, die ein Gruppenchat-Protokoll braucht, sobald Menschen danach fragen.