Kind 30382: User Trusted Assertions

Overview

User Trusted Assertions (kind 30382) are addressable events published by trusted service providers to share computed Web of Trust metrics and statistics about Nostr users. These events allow clients to offload expensive Web of Trust calculations to specialized services while maintaining user choice in which providers to trust.

Service providers perform complex calculations on large volumes of events and publish the results as signed assertions that clients can consume. Each assertion targets a specific user (identified by their pubkey) and contains various metrics like follower counts, activity statistics, zap data, and reputation scores.

Specification

Property	Value
Kind Number	30382
Event Range	Addressable
Defined in	NIP-85: Trusted Assertions

Content Format

The content field is empty for trusted assertions.

Schema

""

Tags

Tag Name	Description	Format	Required
d	Target user's pubkey	["d", "<pubkey>"]	Yes
rank	User 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
e	Event reference with relay hint	["e", "<pubkey>", "<relay-url>"]	No
a	Addressable event reference with relay hint	["a", "<pubkey>", "<relay-url>"]	No

Client Behavior

Clients should:

1. Service Provider Discovery:

   • Query the user's kind 10040 events to discover authorized service providers.
   • Connect to the specified relay hints to fetch assertion data.
   • Allow users to configure which service providers they trust for different metrics.

2. Assertion Consumption:

   • Query trusted service providers for assertion data about users.
   • Display computed metrics like rank, follower count, and activity statistics.
   • Update assertion data as service providers publish new calculations.
   • Handle multiple service providers offering the same metrics with different algorithms.

3. Data Presentation:

   • Properly handle the addressable event format (one assertion per target pubkey per service provider).
   • Display metrics in user interfaces where appropriate (user profiles, lists, etc.).
   • Indicate the source of assertion data to maintain transparency.

Service Provider Behavior

Service providers should:

1. Algorithm Isolation:

   • Use different service keys for distinct algorithms.
   • Use separate keys per user for personalized algorithms.
   • Publish kind 0 metadata events for each service key explaining the algorithm.

2. Assertion Publishing:

   • Update trusted assertions only when contents actually change.
   • Use addressable events (one assertion per target pubkey per service).
   • Include relay hints using p, e, and a tags when appropriate.

3. Access Control:

   • May limit access to results by using paid relays.
   • Should update assertions as fast as new information arrives.

Relay Behavior

Relays should:

1. Store user trusted assertion events from service providers.
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 service provider/target pair is considered current.
4. Support REQ filters that allow clients to efficiently query assertions.

Use Cases

Web of Trust Calculations:

• Offloading expensive reputation calculations to specialized service providers.
• Computing follower counts with various filtering algorithms.
• Analyzing user activity patterns and engagement metrics.
• Calculating zap statistics and economic activity.

User Discovery and Ranking:

• Displaying reputation scores to help users discover quality accounts.
• Showing user activity statistics (posts, replies, reactions).
• Presenting economic activity through zap data.
• Highlighting common topics and interests.
• Displaying typical activity hours for interaction timing.

Algorithmic Diversity:

• Supporting multiple service providers with different algorithms.
• Enabling personalized Web of Trust calculations.
• Allowing users to choose providers that align with their preferences.

Example

User Trusted Assertion Example

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

References

• NIP-85: Trusted Assertions
• NIP-01: Basic Protocol

Related Kinds

• Kind 30383: Event Trusted Assertions - Assertions about individual events
• Kind 30384: Addressable Event Trusted Assertions - Assertions about addressable events
• Kind 30385: External Identifier Trusted Assertions - Assertions about NIP-73 identifiers
• Kind 10040: Trusted Service Providers - Lists authorized assertion providers

Notes

• Service providers must use different service keys for distinct algorithms, including separate keys per user for personalized algorithms.
• Service providers should only update assertions when the contents actually change to avoid unnecessary re-downloads.
• Clients should clearly indicate the source of assertion data to maintain transparency about which service provider generated the metrics.
• The same target pubkey can have multiple assertion events from different service providers, allowing users to compare different algorithmic approaches.