Skip to content

Kind 1: Short Text Note

Overview

Kind 1 is a basic text note in the Nostr protocol, serving as the foundation for social media-style text posts. It enables users to publish plain text content, reply to other posts, create threaded conversations, and mention or quote other events. This kind is fundamental to social communication on the Nostr network.

Specification

PropertyValue
Kind Number1
Event RangeRegular
Defined inNIP-10

Content Format

The content field contains human-readable plaintext. Markup languages such as markdown and HTML SHOULD NOT be used according to the NIP-10 specification. The content can include references to other events, users, or external resources.

Text Note References (NIP-27)

Inline references to other events and profiles in the content field should use NIP-21 codes:

  • Profile mentions: nostr:nprofile1... or nostr:npub1...
  • Event references: nostr:note1... or nostr:nevent1...

When a client processes an event with such references:

  1. The client should parse the content field and identify nostr: URLs
  2. For profile mentions, the client should display the mention in a user-friendly way (e.g., replacing nostr:nprofile1... with @username and making it clickable)
  3. For event references, the client may display a preview of the referenced event

Including corresponding tags is optional:

  • Add a p tag if you want to notify the mentioned user
  • Add an e or q tag if you want the referenced event to recognize the mention as a reply or quote

Tags

Tag NameDescriptionFormatRequired
eReferenced event (preferred with marker)["e", "<event-id>", "<relay-url>", "<marker>", "<pubkey>"]No
pReferenced profiles["p", "<pubkey>", "<relay-url>"]No
qQuoted event["q", "<event-id or event-address>", "<relay-url>", "<pubkey-if-a-regular-event>"]No

e Tag Details

The e tag is used to reference other events, particularly for creating threaded conversations:

  • <event-id>: The ID of the referenced event
  • <relay-url>: A recommended relay URL where the event can be found (optional)
  • <marker>: Optional marker that can be either "root" or "reply"
    • "root": Indicates the original post in a thread
    • "reply": Indicates the direct parent post being replied to
  • <pubkey>: Optional field for the pubkey of the author of the referenced event

e tags SHOULD be sorted in chronological order from root to direct parent in a conversation thread.

p Tag Details

The p tag contains public keys of users relevant to the note:

  • When replying to an event, the p tags should include all p tags from the original event plus the pubkey of the author of the event being replied to.
  • This ensures proper notification routing in the Nostr network.

q Tag Details

The q tag is used when citing events in the content with NIP-21:

  • Authors of events referenced in e and q tags SHOULD be added as p tags to notify them of the reply or quote.

Client Behavior

Clients SHOULD:

  1. Display kind 1 events as text posts in a social media-like format.
  2. Render threaded conversations by following the e tags with proper indentation.
  3. Notify users when they're mentioned via a p tag.
  4. Use the relay hints in tags to find related events when building threads.
  5. Support both the preferred marked e tags and the deprecated positional e tags for compatibility.

NIP-27 Text Note Reference Handling

For text note references (NIP-27), clients SHOULD:

  1. Parse nostr: URLs in the content field when displaying notes.
  2. Replace profile references (nostr:nprofile1... or nostr:npub1...) with user-friendly displays like @username.
  3. For profile mentions:
    • Extract the pubkey from the NIP-19 code
    • Fetch the profile information if not already cached
    • Display the mention as a clickable link to the user profile
  4. For event references:
    • Extract the event ID from the NIP-19 code
    • Optionally show a preview of the referenced event content
    • Provide a clickable link to view the full referenced event
  5. Support autocomplete functionality for mentions when users type @ (optional but recommended)

Relay Behavior

Relays SHOULD:

  1. Store kind 1 events as they are regular events.
  2. Index the events by their tags to enable efficient querying.
  3. Allow clients to query for events based on e and p tags to construct threads.

Use Cases

  • Social media posts and status updates.
  • Comments and replies to other posts.
  • Threaded conversations.
  • Public discussions.
  • Direct responses to other users.

Examples

Basic Reply Example

json
{
  "id": "4376c65d2f232afbe9b882a35baa4f6fe8667c4e684749af565f981833ed6a65",
  "pubkey": "6e468422dfb74a5738702a8823b9b28168abab8655faacb6853cd0ee15deee93",
  "created_at": 1673347337,
  "kind": 1,
  "tags": [
    ["e", "3da979448d9ba263864c4d6f14984c423a3838364ec255f03c7904b1ae77f206", "wss://relay.example.com", "root"],
    ["e", "8e05d0960271a9c2980a3ecedcdf545584f9c808c9cfb93c2623a59249c6e4ef", "wss://relay.example.com", "reply"],
    ["p", "a696c45fdc0c8f64b8f07d05b41d107f1fa667436267876c9c1d3be86f9a3c41"]
  ],
  "content": "This is a reply to a thread started by @npub1aaaa... I agree with your points about Nostr!",
  "sig": "908a15e46fb4d8675bab026fc230a0e3542bfade63da02d542fb78b2a8513fcd0092619a2c8c1221e581946e0191f2af505dfdf8657a414dbca329186f009262"
}

Example with NIP-27 Text Note References

json
{
  "id": "f39e9b451a73d62abc5016cffdd294b1a904e2f34536a208874fe5e22bbd47cf",
  "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
  "created_at": 1679790774,
  "kind": 1,
  "tags": [
    [
      "p",
      "2c7cc62a697ea3a7826521f3fd34f0cb273693cbe5e9310f35449f43622a5cdc"
    ]
  ],
  "content": "Hello nostr:nprofile1qqszclxx9f5haga8sfjjrulaxncvkfekj097t6f3pu65f86rvg49ehqj6f9dh! I'm also referencing this post: nostr:note1q6me9xqe3g80h98gutd3rd27xvyam9d45qxsz8pst73jjlk3xwnszkrns5.",
  "sig": "f8c8bab1b90cc3d2ae1ad999e6af8af449ad8bb4edf64807386493163e29162b5852a796a8f474d6b1001cddbaac0de4392838574f5366f03cc94cf5dfb43f4d"
}

References

Notes

  1. The original positional e tag scheme is deprecated but still supported for backward compatibility.
  2. When creating a direct reply to the root of a thread, only the "root" marker should be used.
  3. While the specification recommends against using markdown or HTML, many clients do render certain markdown-like syntax (such as links, bold, etc.) for better readability.
  4. The regular event range (kind 1) means that relays are expected to store these events permanently.