{"id":"27f96121b53d5ef0519ee2dd22d7272cc22c76719c2a88b2b70b87a238e0c908","pubkey":"266815e0c9210dfa324c6cba3573b14bee49da4209a9456f9484e5106cd408a5","created_at":1782833758,"kind":30817,"tags":[["d","nostr-protocol-experts"],["title","Nostr Experts Lists"],["alt","Nostr Implementation Possibility: Nostr Experts Lists"],["k","12022","Trusted Experts"],["k","32033","Expert Packs"],["client","NostrHub"]],"content":"This NIP defines two list event kinds for describing which Nostr users a person or client considers\nto be subject-matter experts:\n\n- `12022`: a replaceable **Nostr Expert List** owned by one user.\n- `32022`: an addressable **Nostr Expert Pack** that can be browsed, shared, copied, and remixed.\n\nThe primary use case is expert-driven curation. A client can use a user's expert list to decide whose\nNIP approvals, labels, reviews, follows, or other public signals should count more heavily in a local\nranking or discovery algorithm.\n\nThis NIP does not define what makes someone an expert. It only defines how a user publishes the set of\npubkeys they want a client to treat as experts for a given context.\n\n## Kind `12022`: Nostr Expert List\n\nKind `12022` is a normal replaceable event. Each pubkey has at most one current expert list.\n\nThe list items are Nostr pubkeys stored as `p` tags. Clients MUST treat each `p` tag value as a\nlowercase hex-encoded public key, as defined by NIP-01.\n\nPublic expert lists store their members directly in the event `tags` array. Private expert lists use\nthe same private-list method defined by NIP-51: list items are encoded as a JSON array shaped like the\nevent `tags` array, encrypted to the author with NIP-44, and stored in `content`.\n\n### Public List\n\n```jsonc\n{\n  \"kind\": 12022,\n  \"content\": \"\",\n  \"tags\": [\n    [\"p\", \"<expert-pubkey-1>\"],\n    [\"p\", \"<expert-pubkey-2>\"],\n    [\"p\", \"<expert-pubkey-3>\"]\n  ]\n}\n```\n\n### Private List\n\nFor a private list, `content` MUST be a NIP-44 ciphertext encrypted to the event author's own pubkey.\nThe plaintext MUST be a JSON-encoded array of tag arrays:\n\n```jsonc\n[\n  [\"p\", \"<expert-pubkey-1>\"],\n  [\"p\", \"<expert-pubkey-2>\"],\n  [\"p\", \"<expert-pubkey-3>\"]\n]\n```\n\nThe published event has no public `p` tags unless the author intentionally wants a mixed public/private\nlist:\n\n```jsonc\n{\n  \"kind\": 12022,\n  \"content\": \"<nip44-ciphertext>\",\n  \"tags\": []\n}\n```\n\nClients MAY support mixed lists where some `p` tags are public and additional `p` tags are encrypted in\n`content`, matching NIP-51 behavior. Clients reading their own list SHOULD merge public and decrypted\nprivate items and deduplicate pubkeys while preserving first-seen order where practical.\n\n### Tags\n\n| Tag | Required | Repeatable | Description |\n| --- | -------- | ---------- | ----------- |\n| `p` | no | yes | Expert pubkey. Public list item. |\n| `client` | no | no | Publishing client name or identifier. |\n\n### Querying a User's Expert List\n\n```jsonc\n{\n  \"kinds\": [12022],\n  \"authors\": [\"<pubkey>\"],\n  \"limit\": 1\n}\n```\n\nClients MUST filter by `authors` when querying kind `12022`, because the event represents a specific\nuser's list. If multiple events are returned, clients SHOULD use the newest valid event.\n\n## Kind `32022`: Nostr Expert Pack\n\nKind `32022` is an addressable event representing a named expert pack. Expert packs are public,\nshareable lists intended for browsing, discovery, and copying into a user's own kind `12022` list.\n\nExpert packs are the social layer of expert lists. A user can publish a pack such as \"Nostr Protocol\nReviewers\", \"Relay Operators\", or \"Client Developers\" so other users can inspect the included pubkeys\nand choose whether to copy all or part of the pack.\n\nEach pack is identified by the tuple `kind:pubkey:d`, and can be referenced with an `naddr`.\n\n### Event Shape\n\n```jsonc\n{\n  \"kind\": 32022,\n  \"content\": \"A curated list of people who understand Nostr protocol design and NIP review.\",\n  \"tags\": [\n    [\"d\", \"nostr-protocol-reviewers\"],\n    [\"title\", \"Nostr Protocol Reviewers\"],\n    [\"description\", \"People I trust for protocol-level Nostr review and implementation feedback.\"],\n    [\"p\", \"<expert-pubkey-1>\"],\n    [\"p\", \"<expert-pubkey-2>\"],\n    [\"p\", \"<expert-pubkey-3>\"]\n  ]\n}\n```\n\n### Tags\n\n| Tag | Required | Repeatable | Description |\n| --- | -------- | ---------- | ----------- |\n| `d` | yes | no | Stable identifier for this pack under the author's pubkey. |\n| `title` | yes | no | Human-readable pack title. |\n| `description` | recommended | no | Short summary for directory and preview UIs. |\n| `p` | yes | yes | Expert pubkey included in the pack. |\n| `image` | no | no | Optional pack image URL. |\n\nThe `content` field MAY contain a longer freeform description of the pack. If both `content` and a\n`description` tag are present, clients SHOULD use the `description` tag for compact previews and\n`content` for the full detail page.\n\n### Querying Expert Packs\n\nRecent expert packs:\n\n```jsonc\n{\n  \"kinds\": [32022],\n  \"limit\": 50\n}\n```\n\nA specific pack, after decoding an `naddr`:\n\n```jsonc\n{\n  \"kinds\": [32022],\n  \"authors\": [\"<pubkey>\"],\n  \"#d\": [\"<identifier>\"],\n  \"limit\": 1\n}\n```\n\nClients MUST include `authors` when querying a specific addressable pack by `d` tag. The `d` tag alone\nis not a trust boundary, and any user can publish a pack with the same identifier.\n\n## Copying a Pack Into a User List\n\nCopying a kind `32022` expert pack does not create a subscription relationship. It is a client-side\noperation that reads the pack's `p` tags and publishes a new kind `12022` event for the current user.\n\nClients SHOULD let users review the pubkeys before copying. Clients MAY support partial copying,\ndeduplication against the user's existing kind `12022` list, and preserving the current public/private\nmode of that list.\n\nIf a user wants future updates from a pack author, that relationship should be represented separately;\nkind `12022` is a concrete list snapshot, not a dynamic reference to packs.\n\n## Validation\n\nClients SHOULD ignore invalid list items rather than rejecting the whole event. In particular:\n\n- `p` tag values MUST be 32-byte lowercase hex public keys.\n- Duplicate pubkeys SHOULD be treated as one item.\n- For kind `12022`, encrypted `content` that cannot be decrypted by the author should be treated as an\n  unreadable private portion of the list.\n- For kind `32022`, events without a `d` tag, title, or any valid `p` tag SHOULD NOT be displayed as\n  usable packs.\n\n## Privacy and Security Considerations\n\nPublic kind `12022` lists and all kind `32022` packs reveal whose expertise the author trusts. This may\nreveal social, political, professional, or moderation preferences.\n\nPrivate kind `12022` lists hide their members from other users by encrypting the list to the author.\nRelays and observers can still see that the author published a kind `12022` event, its timestamp, and\nany public tags included on the event.\n\nClients MUST NOT attempt to decrypt another user's private kind `12022` list. A non-empty `content`\nfield with no public `p` tags is enough to indicate that a private list exists, but not who is in it.\n\nExpert designation is subjective. Clients SHOULD NOT present membership in an expert list or pack as an\nobjective credential, endorsement by the protocol, or proof of trustworthiness.","sig":"e7b6805783b0489f38923fe9857e00bec32af48ed8a5b747f47407e9cd383f63ac4b12c53deff8d449057239c4b6af8159ba4e59d95cb034bd813436441044f3"}