Kind 30383: Event Trusted Assertions

Overview

Event Trusted Assertions (kind 30383) are addressable events published by trusted service providers to share computed metrics and statistics about individual Nostr events. These events allow clients to offload expensive engagement and popularity calculations to specialized services while maintaining user choice in which providers to trust.

Service providers perform complex calculations on event interaction data and publish the results as signed assertions that clients can consume. Each assertion targets a specific event (identified by its event ID) and contains various metrics like comment counts, reaction counts, zap statistics, and ranking scores.

Specification

Property	Value
Kind Number	30383
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 event ID	["d", "<event_id>"]	Yes
rank	Event rank (0-100)	["rank", "85"]	No
comment_cnt	Event comment count	["comment_cnt", "42"]	No
quote_cnt	Event quote count	["quote_cnt", "15"]	No
repost_cnt	Event repost count	["repost_cnt", "28"]	No
reaction_cnt	Event reaction count	["reaction_cnt", "156"]	No
zap_cnt	Event zap count	["zap_cnt", "23"]	No
zap_amount	Event zap amount (sats)	["zap_amount", "50000"]	No
p	Relay hint for the target event	["p", "<event_id>", "<relay-url>"]	No
e	Event reference with relay hint	["e", "<event_id>", "<relay-url>"]	No
a	Addressable event reference with relay hint	["a", "<event_id>", "<relay-url>"]	No

Client Behavior

Clients should:

1. Service Provider Discovery:

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

2. Assertion Consumption:

   • Query trusted service providers for assertion data about events.
   • Display computed metrics like engagement counts, popularity scores, and rankings.
   • 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 event per service provider).
   • Display metrics in user interfaces where appropriate (event feeds, threads, 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 event 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 event trusted assertion events from service providers.
2. Support queries by d tag (target event ID), 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

Event Engagement Analysis:

• Offloading expensive engagement calculations to specialized service providers.
• Computing interaction counts (comments, quotes, reposts, reactions).
• Analyzing zap statistics and economic activity for events.
• Calculating popularity and ranking scores.

Content Discovery and Ranking:

• Displaying event popularity scores to help users discover quality content.
• Showing engagement statistics to indicate community interest.
• Presenting economic activity through zap data.
• Ranking events by computed engagement metrics.

Algorithmic Diversity:

• Supporting multiple service providers with different engagement calculation algorithms.
• Enabling personalized event ranking based on user preferences.
• Allowing users to choose providers that align with their content discovery preferences.

Example

Event Trusted Assertion Example

{
  "id": "d2e3f4a5b6c7...",
  "pubkey": "4fd5e210530e4f6b2cb083795834bfe5108324f1ed9f00ab73b9e8fcfe5f12fe",
  "created_at": 1675642635,
  "kind": 30383,
  "tags": [
    ["d", "b3e392b11f5d4f28321cedd09303a748acfd0487aea5a7450b3481c60b6e4f87"],
    ["rank", "92"],
    ["comment_cnt", "67"],
    ["quote_cnt", "23"],
    ["repost_cnt", "45"],
    ["reaction_cnt", "234"],
    ["zap_cnt", "56"],
    ["zap_amount", "125000"]
  ],
  "content": "",
  "sig": "..."
}

References

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

Related Kinds

• Kind 30382: User Trusted Assertions - Assertions about users
• 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 event can have multiple assertion events from different service providers, allowing users to compare different algorithmic approaches to engagement metrics.