Kind 0: User Metadata

Overview

Kind 0 events represent user metadata in the Nostr protocol. These events contain profile information for Nostr users, allowing them to share details about themselves with the network.

Specification

Property	Value
Kind Number	0
Event Range	Replaceable
Defined in	NIP-01, NIP-05, NIP-24, NIP-57

Content Format

The content field must be a stringified JSON object containing user profile information.

Schema

{
  "name": "<nickname or full name>",
  "about": "<short bio>",
  "picture": "<URL of profile picture>",
  "display_name": "<alternative, bigger name with richer characters>",
  "website": "<web URL related to the event author>",
  "banner": "<URL to a wide (~1024x768) picture for profile background>",
  "nip05": "<internet identifier in the format [email protected]>",
  "bot": true,
  "birthday": {
    "year": 1990,
    "month": 1,
    "day": 1
  },
  "lud06": "<LNURL pay request (bech32-encoded)>",
  "lud16": "<Lightning Address>"
}

Tags

Kind 0 events typically do not require specific tags, though custom tags may be added.

Client Behavior

Clients should:

• Parse the JSON content to display user profiles.
• Store and cache user metadata for known users.
• Update cached metadata when newer events are received.
• Use fallback mechanisms when specific fields are missing.

Relay Behavior

Relays should:

• Only store the latest kind 0 event for each pubkey.
• Older versions of kind 0 events for the same pubkey may be discarded.
• When answering requests for kind 0 events, return only the latest one even if multiple versions are stored.

Use Cases

• Setting up a user profile.
• Updating profile information.
• Sharing contact details.
• Building user directories.
• Creating discoverable user information.

Example

Basic Example

{
  "id": "fa5ed84fc8eeb959fd39ad8e48388cfc33075991ef8e50064cfcecfd918bb91b",
  "pubkey": "79dff8f82963424e0bb02708a22e44b4980893e3a4be0fa3cb60a43b946764e3",
  "created_at": 1672068534,
  "kind": 0,
  "tags": [],
  "content": "{\"name\":\"Alex\",\"about\":\"Nostr enthusiast\",\"picture\":\"https://example.com/profile.jpg\"}",
  "sig": "55c7e9ab1f5c499b984ca78a53a63158771cf9dd516377c7a9726511afcb858144eac63394262d44c5135b9e3c19733835a5d397a725c6aedf73b3895423cda0"
}

Example with NIP-24 Fields

{
  "id": "fa5ed84fc8eeb959fd39ad8e48388cfc33075991ef8e50064cfcecfd918bb91b",
  "pubkey": "79dff8f82963424e0bb02708a22e44b4980893e3a4be0fa3cb60a43b946764e3",
  "created_at": 1672068534,
  "kind": 0,
  "tags": [],
  "content": "{\"name\":\"Alex\",\"about\":\"Nostr enthusiast\",\"picture\":\"https://example.com/profile.jpg\",\"display_name\":\"Alexander Smith\",\"website\":\"https://example.com\",\"banner\":\"https://example.com/banner.jpg\",\"nip05\":\"[email protected]\",\"bot\":false,\"birthday\":{\"year\":1990,\"month\":1,\"day\":1},\"lud06\":\"lnurl1dp68gurn8ghj7um5v93kketj9ehx2amn9uh8wetvdskkkmn0wahz7mrww4excup0dajx2mrv92x9xp\",\"lud16\":\"[email protected]\"}",
  "sig": "55c7e9ab1f5c499b984ca78a53a63158771cf9dd516377c7a9726511afcb858144eac63394262d44c5135b9e3c19733835a5d397a725c6aedf73b3895423cda0"
}

References

• NIP-01: Basic protocol flow description
• NIP-05: Mapping Nostr keys to DNS-based internet identifiers
• NIP-24: Extra metadata fields
• NIP-57: Lightning Zaps

Related Kinds

• Kind 3: Contacts List
• Kind 10000+: Similar replaceable event kinds

Notes

While the basic fields (name, about, picture) are standard, applications may support additional fields from NIP-24 or custom fields for specialized use cases.

NIP-24 Fields

The following additional fields are defined in NIP-24:

• display_name: An alternative, bigger name with richer characters than name. The name field should always be set regardless of the presence of display_name.
• website: A web URL related in any way to the event author.
• banner: An URL to a wide (~1024x768) picture to be optionally displayed in the background of a profile screen.
• bot: A boolean to clarify that the content is entirely or partially the result of automation, such as with chatbots or newsfeeds.
• birthday: An object representing the author's birth date. The format is { "year": number, "month": number, "day": number }. Each field MAY be omitted.

NIP-05 Fields

The following field is defined in NIP-05 for mapping Nostr keys to DNS-based internet identifiers:

• nip05: An internet identifier in the format [email protected]. This allows clients to verify that a user controls both the Nostr key and the domain name. Clients can verify this by making a GET request to https://<domain>/.well-known/nostr.json?name=<username> and checking if the returned JSON contains the user's public key.

Special case: The identifier _@domain can be used as a "root" identifier, and clients may display it as just domain.

NIP-57 Fields

The following additional fields are defined in NIP-57 for Lightning Zaps:

• lud06: A bech32-encoded LNURL pay request URL. This is used by clients to request a Lightning invoice for sending zaps.
• lud16: A Lightning Address (in the format [email protected]). This is an alternative to lud06 that clients can use to generate a Lightning invoice for sending zaps.

Deprecated Fields

The following fields are deprecated according to NIP-24 and should be ignored or removed when found:

• displayName: Use display_name instead.
• username: Use name instead.