Kind 30382: Pubkey Record

Overview

Pubkey Record events (kind 30382) provide a way for users to keep editable records and metadata about other users. These records can serve two primary purposes: personal note-taking about other pubkeys, and storing computed Web of Trust metrics from trusted service providers.

This kind enables users to maintain their own categorizations, notes, and metadata about other users in the network, while also supporting standardized metrics from reputation services. The addressable nature of these events means that each pubkey can have only one record per author, which is updated over time.

Specification

Property	Value
Kind Number	30382
Event Range	Addressable
Defined in	Record Events Proposal, Trusted Assertions Proposal

Content Format

The content field may be an empty string, or a NIP-44 encrypted tag list containing private tags that the user does not wish to reveal publicly.

Schema

""

or

{
  "encrypted": "base64-encoded-nip44-encrypted-data"
}

Tags

Tag Name	Description	Format	Required
d	Target user's pubkey	["d", "<pubkey>"]	Yes
n	Set name for categorization	["n", "<set-name>"]	No
summary	Brief description of the user	["summary", "This is my boss"]	No
rank	Web of Trust rank (0-100)	["rank", "89"]	No
followers	Follower count	["followers", "1234"]	No
first_created_at	First post timestamp	["first_created_at", "1609459200"]	No
post_cnt	Post count	["post_cnt", "567"]	No
reply_cnt	Reply count	["reply_cnt", "234"]	No
reactions_cnt	Reactions count	["reactions_cnt", "890"]	No
zap_amt_recd	Zap amount received (sats)	["zap_amt_recd", "100000"]	No
zap_amt_sent	Zap amount sent (sats)	["zap_amt_sent", "50000"]	No
zap_cnt_recd	Zap number received	["zap_cnt_recd", "45"]	No
zap_cnt_sent	Zap number sent	["zap_cnt_sent", "30"]	No
zap_avg_amt_day_recd	Avg zap amount/day received (sats)	["zap_avg_amt_day_recd", "500"]	No
zap_avg_amt_day_sent	Avg zap amount/day sent (sats)	["zap_avg_amt_day_sent", "200"]	No
reports_cnt_recd	Reports received	["reports_cnt_recd", "2"]	No
reports_cnt_sent	Reports sent	["reports_cnt_sent", "5"]	No
t	Common topics	["t", "bitcoin"]	No
active_hours_start	Generally active start (0-24, UTC)	["active_hours_start", "14"]	No
active_hours_end	Generally active end (0-24, UTC)	["active_hours_end", "22"]	No
p	Relay hint for the target pubkey	["p", "<pubkey>", "<relay-url>"]	No

Client Behavior

Clients should:

1. For Personal Records:

   • Allow users to create and update records about other users.
   • Support adding arbitrary tags to record personal notes and categorizations.
   • Support the n tag for organizing users into sets (e.g., "colleague", "friend", "family").
   • Display the most recent version when multiple versions exist.
   • Support NIP-44 encryption of private tags in the content field.

2. For Trusted Assertions:

   • Query trusted service providers (as declared in kind 10040 events) for assertion data.
   • Display computed metrics like rank, follower count, and activity statistics.
   • Update assertion data as service providers publish new calculations.
   • Allow users to choose which service providers to trust for different metrics.

3. General:

   • Properly handle the addressable event format (one record per target pubkey per author).
   • Support filtering and searching records by tags.

Relay Behavior

Relays should:

1. Store pubkey record events.
2. Support queries by d tag (target pubkey), author, or other tag parameters.
3. Implement proper handling of addressable events, ensuring only the most recent version per author/target pair is considered current.
4. Support REQ filters that allow clients to efficiently query records.

Use Cases

Personal Record Management:

• Maintaining private notes about other users.
• Categorizing contacts into groups (colleagues, friends, family).
• Tracking interaction history with specific users.
• Recording context about how you know someone.

Web of Trust Metrics:

• Displaying reputation scores from trusted service providers.
• Showing user activity statistics (posts, replies, reactions).
• Presenting zap statistics and economic activity.
• Highlighting common topics and interests.
• Displaying typical activity hours.

Set-Based Organization:

• Adding users to named sets for organization (using n tags).
• Creating custom categorizations beyond simple follow lists.
• Managing different relationship types.

Example

Personal Record Example

{
  "id": "a1b2c3d4e5f6...",
  "pubkey": "3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d",
  "created_at": 1675642635,
  "kind": 30382,
  "tags": [
    ["d", "e88a691e98d9987c964521dff60025f60700378a4879180dcbbb4a5027850411"],
    ["n", "colleague"],
    ["summary", "Met at Bitcoin conference 2024"]
  ],
  "content": "",
  "sig": "..."
}

Trusted Assertion Example

{
  "id": "b2c3d4e5f6a7...",
  "pubkey": "4fd5e210530e4f6b2cb083795834bfe5108324f1ed9f00ab73b9e8fcfe5f12fe",
  "created_at": 1675642635,
  "kind": 30382,
  "tags": [
    ["d", "e88a691e98d9987c964521dff60025f60700378a4879180dcbbb4a5027850411"],
    ["rank", "89"],
    ["followers", "1523"],
    ["post_cnt", "892"],
    ["zap_amt_recd", "250000"],
    ["t", "bitcoin"],
    ["t", "nostr"],
    ["active_hours_start", "14"],
    ["active_hours_end", "22"]
  ],
  "content": "",
  "sig": "..."
}

References

• Record Events Proposal (PR #1322)
• Trusted Assertions Proposal (PR #1534)
• Event Sets Proposal (PR #784)
• NIP-01: Basic Protocol
• NIP-44: Encrypted Payloads

Related Kinds

• Kind 30383: Event Record - Records about events
• Kind 30384: Addressable Event Record - Records about addressable events
• Kind 10040: Declaring Trusted Service Providers - Lists authorized assertion providers
• Kind 30061: Custom Sets - Tracks custom set names for organization

Notes

• This kind serves dual purposes: personal record-keeping and trusted assertions. The same event structure accommodates both use cases.
• Service providers publishing trusted assertions should use their own pubkey to sign these events, allowing users to identify the source of the metrics.
• Users can maintain their own personal records about pubkeys while also consuming assertion data from service providers by querying events from different authors.
• The n tag from the Event Sets proposal enables flexible categorization and set membership.
• Multiple n tags can be used to include a user in multiple sets simultaneously.
• Clients should distinguish between self-authored records (personal notes) and records from trusted service providers (assertions) in their UI.