content: Plaintext. Bech32 references (npub1..., note1...) rendered as links by clients.
Kind 1 is the primary social post – a short text note equivalent to a tweet or Mastodon post. Content is plaintext with optional NIP-10 threading tags (e and p tags for replies). Kind 1 events are regular – all historical events are kept by relays. The most common event kind in the Nostr network.
Details
Kind 1 is the workhorse of the Nostr protocol. Almost all social content – posts, replies, threads – uses kind 1.
Content: plaintext, but clients render inline URLs and npub/note bech32 references as links. Line breaks are preserved.
NIP-10 threading tags: ["e", "event-id"] – reply to or mention of an event ["e", "event-id", "relay-url", "reply"] – reply to specific event (NIP-10 marker) ["e", "event-id", "relay-url", "root"] – root of thread (NIP-10 marker) ["p", "pubkey"] – mention of a user
NIP-10 markers ('root', 'reply', 'mention') added in NIP-10 to clarify event relationships. Without markers, the threading model was ambiguous. With markers, clients can correctly reconstruct threads.
Regular events: kind 1 is a 'regular' event – all past kind 1 events are preserved. Relays do not replace old kind 1 events. This is unlike kind 0 (metadata) which is replaceable.
Character limits: Nostr has no protocol-level character limit. Relay-level limits vary. Most relays accept up to 64KB content. Clients typically impose their own display limits.
Required Event Fields
Examples
{
"kind": 1,
"pubkey": "hex-pubkey",
"created_at": 1700000000,
"tags": [],
"content": "Hello Nostr! This is my first note.",
"id": "sha256...",
"sig": "schnorr..."
}{
"kind": 1,
"tags": [
["e", "root-event-id", "wss://relay.damus.io", "root"],
["e", "parent-event-id", "wss://relay.damus.io", "reply"],
["p", "original-author-pubkey"]
],
"content": "Replying to your note about Nostr!",
"id": "...",
"sig": "..."
}