NIP-32 definiert einen Standard für das Anhängen von Labels an Nostr-Events, Benutzer und andere Entitäten. Labels bieten strukturierte Metadaten, die Clients für Kategorisierung, Inhaltswarnungen, Reputationssysteme und Moderation verwenden können.

Funktionsweise

Labels verwenden kind 1985 Events mit einem L-Tag, das den Label-Namespace definiert, und l-Tags, die spezifische Labels innerhalb dieses Namespace anwenden. Die gelabelte Entität wird durch Standard-Tags wie e (Events), p (pubkeys) oder r (Relay-URLs) referenziert.

{
  "kind": 1985,
  "tags": [
    ["L", "content-warning"],
    ["l", "nsfw", "content-warning"],
    ["e", "<event_id>"]
  ],
  "content": "Enthält explizite Bilder"
}

Das Namespace-System verhindert Label-Kollisionen. Ein „spam"-Label im „ugc-moderation"-Namespace hat andere Semantik als „spam" im „relay-report"-Namespace. Dies ermöglicht das Koexistieren mehrerer Label-Systeme ohne Interferenz.

Anwendungsfälle

Inhaltsmoderierungssysteme verwenden Labels, um Spam, illegale Inhalte oder Richtlinienverstöße zu markieren. Reputationssysteme fügen Vertrauenswerte oder Verifizierungsstatus an pubkeys an. Medienplattformen wenden Inhaltswarnungen an (NSFW, Gewalt, Spoiler). Relay-Betreiber verwenden Labels für Einsprüche und Streitbeilegung.

Der Trusted Relay Assertions-Vorschlag verwendet NIP-32-Labels für Relay-Einsprüche. Wenn Betreiber Vertrauenswerte anfechten, veröffentlichen sie kind 1985 Events mit L = relay-appeal und Label-Typen wie „spam", „censorship" oder „score".

Client-Implementierungen variieren darin, wie sie Labels konsumieren. Einige Clients behandeln Labels von gefolgten Benutzern als Empfehlungen, während andere spezialisierte Labeling-Dienste abfragen. Das dezentralisierte Design lässt Benutzer wählen, welchen Labelern sie vertrauen.

Primärquellen:

Erwähnt in:

Siehe auch: