Nostr Experts Lists

This NIP defines two list event kinds for describing which Nostr users a person or client considers to be subject-matter experts:

• 12022: a replaceable Nostr Expert List owned by one user.
• 32022: an addressable Nostr Expert Pack that can be browsed, shared, copied, and remixed.

The primary use case is expert-driven curation. A client can use a user's expert list to decide whose NIP approvals, labels, reviews, follows, or other public signals should count more heavily in a local ranking or discovery algorithm.

This NIP does not define what makes someone an expert. It only defines how a user publishes the set of pubkeys they want a client to treat as experts for a given context.

Kind 12022: Nostr Expert List

Kind 12022 is a normal replaceable event. Each pubkey has at most one current expert list.

The list items are Nostr pubkeys stored as p tags. Clients MUST treat each p tag value as a lowercase hex-encoded public key, as defined by NIP-01.

Public expert lists store their members directly in the event tags array. Private expert lists use the same private-list method defined by NIP-51: list items are encoded as a JSON array shaped like the event tags array, encrypted to the author with NIP-44, and stored in content.

Public List

{
  "kind": 12022,
  "content": "",
  "tags": [
    ["p", "<expert-pubkey-1>"],
    ["p", "<expert-pubkey-2>"],
    ["p", "<expert-pubkey-3>"]
  ]
}

Private List

For a private list, content MUST be a NIP-44 ciphertext encrypted to the event author's own pubkey. The plaintext MUST be a JSON-encoded array of tag arrays:

[
  ["p", "<expert-pubkey-1>"],
  ["p", "<expert-pubkey-2>"],
  ["p", "<expert-pubkey-3>"]
]

The published event has no public p tags unless the author intentionally wants a mixed public/private list:

{
  "kind": 12022,
  "content": "<nip44-ciphertext>",
  "tags": []
}

Clients MAY support mixed lists where some p tags are public and additional p tags are encrypted in content, matching NIP-51 behavior. Clients reading their own list SHOULD merge public and decrypted private items and deduplicate pubkeys while preserving first-seen order where practical.

Tags

Querying a User's Expert List

{
  "kinds": [12022],
  "authors": ["<pubkey>"],
  "limit": 1
}

Clients MUST filter by authors when querying kind 12022, because the event represents a specific user's list. If multiple events are returned, clients SHOULD use the newest valid event.

Kind 32022: Nostr Expert Pack

Kind 32022 is an addressable event representing a named expert pack. Expert packs are public, shareable lists intended for browsing, discovery, and copying into a user's own kind 12022 list.

Expert packs are the social layer of expert lists. A user can publish a pack such as "Nostr Protocol Reviewers", "Relay Operators", or "Client Developers" so other users can inspect the included pubkeys and choose whether to copy all or part of the pack.

Each pack is identified by the tuple kind:pubkey:d, and can be referenced with an naddr.

Event Shape

{
  "kind": 32022,
  "content": "A curated list of people who understand Nostr protocol design and NIP review.",
  "tags": [
    ["d", "nostr-protocol-reviewers"],
    ["title", "Nostr Protocol Reviewers"],
    ["description", "People I trust for protocol-level Nostr review and implementation feedback."],
    ["p", "<expert-pubkey-1>"],
    ["p", "<expert-pubkey-2>"],
    ["p", "<expert-pubkey-3>"]
  ]
}

Tags

The content field MAY contain a longer freeform description of the pack. If both content and a description tag are present, clients SHOULD use the description tag for compact previews and content for the full detail page.

Querying Expert Packs

Recent expert packs:

{
  "kinds": [32022],
  "limit": 50
}

A specific pack, after decoding an naddr:

{
  "kinds": [32022],
  "authors": ["<pubkey>"],
  "#d": ["<identifier>"],
  "limit": 1
}

Clients MUST include authors when querying a specific addressable pack by d tag. The d tag alone is not a trust boundary, and any user can publish a pack with the same identifier.

Copying a Pack Into a User List

Copying a kind 32022 expert pack does not create a subscription relationship. It is a client-side operation that reads the pack's p tags and publishes a new kind 12022 event for the current user.

Clients SHOULD let users review the pubkeys before copying. Clients MAY support partial copying, deduplication against the user's existing kind 12022 list, and preserving the current public/private mode of that list.

If a user wants future updates from a pack author, that relationship should be represented separately; kind 12022 is a concrete list snapshot, not a dynamic reference to packs.

Validation

Clients SHOULD ignore invalid list items rather than rejecting the whole event. In particular:

• p tag values MUST be 32-byte lowercase hex public keys.
• Duplicate pubkeys SHOULD be treated as one item.
• For kind 12022, encrypted content that cannot be decrypted by the author should be treated as an

unreadable private portion of the list.

• For kind 32022, events without a d tag, title, or any valid p tag SHOULD NOT be displayed as

usable packs.

Privacy and Security Considerations

Public kind 12022 lists and all kind 32022 packs reveal whose expertise the author trusts. This may reveal social, political, professional, or moderation preferences.

Private kind 12022 lists hide their members from other users by encrypting the list to the author. Relays and observers can still see that the author published a kind 12022 event, its timestamp, and any public tags included on the event.

Clients MUST NOT attempt to decrypt another user's private kind 12022 list. A non-empty content field with no public p tags is enough to indicate that a private list exists, but not who is in it.

Expert designation is subjective. Clients SHOULD NOT present membership in an expert list or pack as an objective credential, endorsement by the protocol, or proof of trustworthiness.