Skip to content

Kind 30384: Addressable Event Record

Overview

Addressable Event Record events (kind 30384) provide a way to keep editable records and metadata about addressable events (parameterized replaceable events). Unlike kind 30383 which tracks individual event versions, this kind tracks all versions of an addressable event using its address coordinate.

This kind is primarily used for storing computed metrics from trusted service providers, allowing aggregation of engagement data across all versions of an addressable event. For example, an article (kind 30023) might be updated multiple times, but this record can maintain cumulative statistics across all versions.

Specification

PropertyValue
Kind Number30384
Event RangeAddressable
Defined inTrusted 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

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

Tags

Tag NameDescriptionFormatRequired
dTarget event address["d", "<kind>:<pubkey>:<d-identifier>"]Yes
nSet name for categorization["n", "<set-name>"]No
rankAddress rank (0-100)["rank", "88"]No
comment_cntComment count across all versions["comment_cnt", "125"]No
quote_cntQuote count across all versions["quote_cnt", "45"]No
repost_cntRepost count across all versions["repost_cnt", "67"]No
reaction_cntReaction count across all versions["reaction_cnt", "523"]No
zap_cntZap count across all versions["zap_cnt", "89"]No
zap_amountTotal zap amount across all versions (sats)["zap_amount", "250000"]No
aRelay hint for the target addressable event["a", "<kind>:<pubkey>:<d-identifier>", "<relay-url>"]No

Client Behavior

Clients should:

  1. For Personal Records:

    • Allow users to create and update records about addressable events.
    • Support adding arbitrary tags to record personal notes and categorizations.
    • Support the n tag for organizing addressable events into sets.
    • 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 aggregated across all versions of the addressable event.
    • 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 address per author).
    • Parse the d tag to extract the kind, pubkey, and identifier of the target addressable event.
    • Support filtering and searching records by tags.
    • Understand that metrics represent cumulative data across all versions of the addressable event.

Relay Behavior

Relays should:

  1. Store addressable event record events.
  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 author/target pair is considered current.
  4. Support REQ filters that allow clients to efficiently query records.

Use Cases

Aggregated Metrics for Content:

  • Displaying total engagement for articles across all revisions.
  • Showing cumulative popularity scores for long-form content.
  • Tracking total zaps received for an addressable event over its lifetime.
  • Ranking addressable events by aggregated metrics.

Content Discovery:

  • Identifying popular articles or content based on trusted metrics.
  • Filtering addressable events by engagement thresholds.
  • Discovering trending addressable content.

Set-Based Organization:

  • Adding addressable events to named sets for organization (using n tags).
  • Creating custom collections of addressable events.
  • Managing different categories of content.

Example

Trusted Assertion Example (Article Metrics)

json
{
  "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"],
    ["a", "30023:a695f6b60119d9521934a691347d9f78e8770b56da16bb255ee286ddf9fda919:my-article", "wss://relay.nostr.org"]
  ],
  "content": "",
  "sig": "..."
}

Personal Record Example (Content Organization)

json
{
  "id": "a5b6c7d8e9f0...",
  "pubkey": "3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d",
  "created_at": 1675642635,
  "kind": 30384,
  "tags": [
    ["d", "30023:a695f6b60119d9521934a691347d9f78e8770b56da16bb255ee286ddf9fda919:bitcoin-guide"],
    ["n", "technical-resources"],
    ["n", "bitcoin"]
  ],
  "content": "",
  "sig": "..."
}

Repository Metrics Example

json
{
  "id": "b6c7d8e9f0a1...",
  "pubkey": "4fd5e210530e4f6b2cb083795834bfe5108324f1ed9f00ab73b9e8fcfe5f12fe",
  "created_at": 1675642635,
  "kind": 30384,
  "tags": [
    ["d", "30617:e88a691e98d9987c964521dff60025f60700378a4879180dcbbb4a5027850411:nostr-client"],
    ["rank", "87"],
    ["comment_cnt", "45"],
    ["zap_cnt", "78"],
    ["zap_amount", "350000"]
  ],
  "content": "",
  "sig": "..."
}

References

Notes

  • This kind is specifically designed for addressable events (parameterized replaceable events in the 30000-39999 range).
  • The d tag value uses the format <kind>:<pubkey>:<d-identifier>, which uniquely identifies an addressable event coordinate.
  • Metrics stored in kind 30384 events typically represent aggregated data across all versions of the addressable event, not just the latest version.
  • This is particularly useful for content like articles (kind 30023) that may be edited multiple times - the cumulative engagement matters more than per-version metrics.
  • 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 addressable events 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 an addressable event in multiple sets simultaneously.
  • Clients should distinguish between self-authored records (personal organization) and records from trusted service providers (assertions) in their UI.
  • The address format allows for easy parsing and reconstruction of NIP-19 naddr entities for sharing and linking.