Kind 30384: Addressable Event Trusted Assertions

Overview

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

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

Specification

Property	Value
Kind Number	30384
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 address	["d", "<event_address>"]	Yes
rank	Address rank (0-100)	["rank", "88"]	No
comment_cnt	Address comment count	["comment_cnt", "125"]	No
quote_cnt	Address quote count	["quote_cnt", "45"]	No
repost_cnt	Address repost count	["repost_cnt", "67"]	No
reaction_cnt	Address reaction count	["reaction_cnt", "523"]	No
zap_cnt	Address zap count	["zap_cnt", "89"]	No
zap_amount	Address zap amount (sats)	["zap_amount", "250000"]	No
p	Relay hint for the target address	["p", "<event_address>", "<relay-url>"]	No
e	Event reference with relay hint	["e", "<event_address>", "<relay-url>"]	No
a	Addressable event reference with relay hint	["a", "<event_address>", "<relay-url>"]	No

Client Behavior

Clients should:

1. Service Provider Discovery:

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

2. Assertion Consumption:

   • Query trusted service providers for assertion data about addressable events.
   • Display computed metrics aggregated across all versions of the addressable event.
   • 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 address per service provider).
   • Display metrics in user interfaces where appropriate (content feeds, article 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 address 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 addressable event trusted assertion events from service providers.
2. Support queries by d tag (target event address), 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

Addressable Content Analysis:

• Offloading expensive engagement calculations for addressable events to specialized service providers.
• Computing interaction counts across all versions of addressable events (articles, repositories, etc.).
• Analyzing zap statistics and economic activity for addressable content.
• Calculating popularity and ranking scores aggregated across event versions.

Content Discovery and Ranking:

• Displaying popularity scores to help users discover quality addressable content.
• Showing engagement statistics aggregated across all versions.
• Presenting economic activity through cumulative zap data.
• Ranking addressable events by computed engagement metrics.

Algorithmic Diversity:

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

Example

Addressable Event Trusted Assertion Example

{
  "id": "f4a5b6c7d8e9...",
  "pubkey": "4fd5e210530e4f6b2cb083795834bfe5108324f1ed9f00ab73b9e8fcfe5f12fe",
  "created_at": 1675642635,
  "kind": 30384,
  "tags": [
    ["d", "30023:a695f6b60119d9521934a691347d9f78e8770b56da16bb255ee286ddf9fda919:my-article"],
    ["rank", "94"],
    ["comment_cnt", "234"],
    ["quote_cnt", "67"],
    ["repost_cnt", "89"],
    ["reaction_cnt", "1205"],
    ["zap_cnt", "156"],
    ["zap_amount", "500000"]
  ],
  "content": "",
  "sig": "..."
}

References

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

Related Kinds

• Kind 30382: User Trusted Assertions - Assertions about users
• Kind 30383: Event Trusted Assertions - Assertions about individual 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 addressable event can have multiple assertion events from different service providers, allowing users to compare different algorithmic approaches to engagement metrics.
• Metrics stored in kind 30384 events typically represent aggregated data across all versions of the addressable event, not just the latest version.
• The d tag value uses the format <kind>:<pubkey>:<d-identifier>, which uniquely identifies an addressable event coordinate.