Kind 30385: External Identifier Trusted Assertions

Overview

External Identifier Trusted Assertions (kind 30385) are addressable events published by trusted service providers to share computed metrics and statistics about external entities identified through NIP-73 identifiers. These events allow clients to offload expensive reputation and assessment calculations to specialized services while maintaining user choice in which providers to trust.

Service providers perform calculations on external entity data (such as books, locations, movies, websites, hashtags) and publish the results as signed assertions that clients can consume. Each assertion targets a specific external entity identified by a NIP-73 i tag value and contains various metrics like ranking scores, comment counts, and reaction counts.

Specification

Property	Value
Kind Number	30385
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	NIP-73 identifier	["d", "<i-tag>"]	Yes
k	NIP-73 kind tag	["k", "<kind>"]	Yes
rank	Rank (0-100)	["rank", "85"]	No
comment_cnt	Comment count	["comment_cnt", "42"]	No
reaction_cnt	Reaction count	["reaction_cnt", "156"]	No
p	Relay hint for the identifier	["p", "<i-tag>", "<relay-url>"]	No
e	Event reference with relay hint	["e", "<i-tag>", "<relay-url>"]	No
a	Addressable event reference with relay hint	["a", "<i-tag>", "<relay-url>"]	No

Client Behavior

Clients should:

1. Service Provider Discovery:

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

2. Assertion Consumption:

   • Query trusted service providers for assertion data about external identifiers.
   • Display computed metrics like ranking scores, comment counts, and reaction counts.
   • 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 identifier per service provider).
   • Display metrics in user interfaces where appropriate (external links, reference 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 identifier per service).
   • Include NIP-73 k tags to specify the external identifier type.
   • 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 external identifier trusted assertion events from service providers.
2. Support queries by d tag (target identifier), 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

External Entity Assessment:

• Offloading expensive reputation calculations for external entities to specialized service providers.
• Computing interaction counts for books, websites, locations, and other external resources.
• Analyzing community sentiment about external entities.
• Calculating popularity and ranking scores for external content.

Content Discovery and Trust:

• Displaying reputation scores to help users evaluate external resources.
• Showing community engagement metrics for external entities.
• Providing trust indicators for external links and references.
• Ranking external entities by computed metrics.

Algorithmic Diversity:

• Supporting multiple service providers with different external entity assessment algorithms.
• Enabling personalized ranking based on user preferences.
• Allowing users to choose providers that align with their evaluation criteria.

Example

External Identifier Trusted Assertion Example

{
  "id": "f5a6b7c8d9e0...",
  "pubkey": "4fd5e210530e4f6b2cb083795834bfe5108324f1ed9f00ab73b9e8fcfe5f12fe",
  "created_at": 1675642635,
  "kind": 30385,
  "tags": [
    ["d", "isbn:978-0-321-35668-3"],
    ["k", "book"],
    ["rank", "92"],
    ["comment_cnt", "45"],
    ["reaction_cnt", "234"]
  ],
  "content": "",
  "sig": "..."
}

References

• NIP-85: Trusted Assertions
• NIP-73: External Identifiers
• NIP-01: Basic Protocol

Related Kinds

• Kind 30382: User Trusted Assertions - Assertions about users
• Kind 30383: Event Trusted Assertions - Assertions about individual events
• Kind 30384: Addressable Event Trusted Assertions - Assertions about addressable events
• 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.
• NIP-73 k tags should be added to the event to specify the type of external identifier being assessed.
• The same target external identifier can have multiple assertion events from different service providers, allowing users to compare different algorithmic approaches.