# NIP-01 Wire Format for Nostr Events in Buzz: Implementation Guide

> Explore the NIP-01 wire format for Nostr events in Buzz. Learn how Buzz implements this standard JSON structure for seamless data exchange over WebSockets and HTTP. Get the technical details now.

- Repository: [Block Open Source/buzz](https://github.com/block/buzz)
- Tags: implementation-guide
- Published: 2026-08-27

---

**Buzz does not introduce a bespoke wire format for Nostr events; instead, it uses the standard NIP-01 JSON structure transmitted as newline-delimited UTF-8 text over WebSocket and HTTP.**

The Block Buzz relay processes all events according to the canonical Nostr protocol, ensuring compatibility with the broader ecosystem while embedding owner-attestation credentials through standard tag extensions. Every event that flows through the relay—whether via WebSocket, HTTP POST `/events`, `/count`, or `/query`—conforms strictly to the seven-field NIP-01 specification.

## Standard NIP-01 Event Structure

Buzz enforces the exact seven-field JSON object defined in NIP-01 for every event. The relay validates these fields using helper functions in [`crates/buzz-sdk/src/event.rs`](https://github.com/block/buzz/blob/main/crates/buzz-sdk/src/event.rs) before accepting or forwarding any message.

### The Seven Canonical Fields

Every event transmitted to Buzz must contain these required fields with precise encoding:

- **`id`** — A 64-character hexadecimal string representing the SHA-256 hash of the serialized event content.
- **`pubkey`** — The author's 64-character hex-encoded public key.
- **`created_at`** — Unix timestamp in seconds since epoch (integer).
- **`kind`** — Integer defining the application-specific event type (e.g., `0` for metadata, `1` for short text notes, `30078` for read-state blobs), registered in [`crates/buzz-core/src/kind.rs`](https://github.com/block/buzz/blob/main/crates/buzz-core/src/kind.rs).
- **`tags`** — Array of arrays containing structured metadata. Buzz specifically utilizes:
  - `e` tags for event references (replies and mentions).
  - `p` tags for pubkey references to other users.
  - `h` tags for group/channel identifiers (implementing NIP-29).
  - `auth` tags containing **NIP-OA** credentials that realize the "NIP-OI" owner-identity concept.
- **`content`** — String payload, either plaintext or NIP-44 encrypted.
- **`sig`** — 128-character hex-encoded Schnorr signature covering the event's serialized form.

## Transmission Format and Protocol

The **NIP-01 wire format** employs pure UTF-8 text with newline-delimited JSON framing. No binary encoding, length-prefixing, or additional framing protocols are used.

### WebSocket Transport

In [`crates/buzz-ws-client/src/client.rs`](https://github.com/block/buzz/blob/main/crates/buzz-ws-client/src/client.rs), events are encoded as individual JSON objects terminated by newline characters (`\n`). Each WebSocket message contains exactly one newline-terminated JSON object representing a single Nostr event.

### HTTP Endpoints

The identical newline-delimited JSON structure applies to HTTP POST requests against the `/events`, `/count`, and `/query` endpoints. The relay parses each line of the request body as a discrete event, rejecting any messages that deviate from the standard seven-field structure.

## NIP-OI Implementation via NIP-OA Credentials

While Buzz adheres strictly to NIP-01 for wire transport, it implements the "NIP-OI" (Owner-Identity) concept through **NIP-OA** (Owner-Attestation) credentials embedded in standard tags.

### The Auth Tag Structure

The `auth` tag carries the owner-attestation credential validated by [`crates/buzz-auth/src/nip42.rs`](https://github.com/block/buzz/blob/main/crates/buzz-auth/src/nip42.rs) and parsed by [`crates/buzz-acp/src/acp.rs`](https://github.com/block/buzz/blob/main/crates/buzz-acp/src/acp.rs):

```json
{
  "id": "...",
  "pubkey": "...",
  "created_at": 1725064832,
  "kind": 40002,
  "tags": [
    ["h", "01ab23cd-ef45-6789-abcd-0123456789ab"],
    ["e", "a1b2c3d4e5f6..."],
    ["auth", "naddr1..."]
  ],
  "content": "Hello, Buzz!",
  "sig": "..."
}

```

The relay validates the `auth` tag **before** accepting the event, ensuring only agents with valid owner attestations can publish on behalf of users. This verification occurs while maintaining the exact NIP-01 wire format compatibility for the event envelope.

## Key Implementation Files

Several components in the Buzz codebase handle the NIP-01 wire format:

- **[`crates/buzz-ws-client/src/client.rs`](https://github.com/block/buzz/blob/main/crates/buzz-ws-client/src/client.rs)** — Manages WebSocket client connections, handling the encoding and decoding of newline-delimited JSON events.
- **[`crates/buzz-core/src/kind.rs`](https://github.com/block/buzz/blob/main/crates/buzz-core/src/kind.rs)** — Central registry defining all event kind integers used by Buzz, including custom kinds for channels and agents.
- **[`crates/buzz-sdk/src/event.rs`](https://github.com/block/buzz/blob/main/crates/buzz-sdk/src/event.rs)** — Provides helper functions to construct valid NIP-01 events, automatically generating the `id` and `sig` fields via SHA-256 hashing and Schnorr signing.
- **[`crates/buzz-auth/src/nip42.rs`](https://github.com/block/buzz/blob/main/crates/buzz-auth/src/nip42.rs)** — Validates the `auth` tag containing NIP-OA credentials, enforcing owner-attestation before relay acceptance.
- **[`crates/buzz-acp/src/acp.rs`](https://github.com/block/buzz/blob/main/crates/buzz-acp/src/acp.rs)** — Parses and extracts NIP-OA credentials from the `auth` tag for agent-side verification.
- **[`docs/nips/NIP-OA.md`](https://github.com/block/buzz/blob/main/docs/nips/NIP-OA.md)** — Specification document defining the credential format reused for the NIP-OI concept according to the block/buzz source code.

## Summary

- Buzz uses the **standard NIP-01 wire format** for all Nostr events without proprietary extensions or binary encodings.
- Events transmit as **newline-delimited JSON** over WebSocket and HTTP POST endpoints (`/events`, `/count`, `/query`).
- The seven canonical fields follow strict NIP-01 specifications: 64-char hex for `id` and `pubkey`, 128-char hex for `sig`, and integer timestamps.
- **NIP-OI** functionality deploys through standard NIP-**OA** credentials carried in the `auth` tag, validated in [`crates/buzz-auth/src/nip42.rs`](https://github.com/block/buzz/blob/main/crates/buzz-auth/src/nip42.rs).
- Client implementations should use [`crates/buzz-sdk/src/event.rs`](https://github.com/block/buzz/blob/main/crates/buzz-sdk/src/event.rs) helpers to ensure proper event serialization and cryptographic signing.

## Frequently Asked Questions

### What is the NIP-01 wire format used by Buzz?

The NIP-01 wire format is the standard JSON-based event structure defined by the Nostr protocol, consisting of seven required fields transmitted as newline-delimited UTF-8 text. Buzz implements this format exactly as specified in NIP-01, without custom binary encodings or proprietary framing protocols.

### How does Buzz handle event authentication within the NIP-01 format?

Buzz embeds authentication credentials within the standard `tags` array using an `auth` tag that contains a NIP-OA (Owner-Attestation) credential. The relay validates this tag during ingestion in [`crates/buzz-auth/src/nip42.rs`](https://github.com/block/buzz/blob/main/crates/buzz-auth/src/nip42.rs), proving the event publisher has owner authorization while maintaining the standard wire format envelope specified in NIP-01.

### Can standard Nostr clients interact with the Buzz relay?

Yes, because Buzz uses the canonical NIP-01 wire format for Nostr events, any standard Nostr client can connect via WebSocket or HTTP POST to publish and query events. Clients only need to include the `auth` tag extension to utilize Buzz-specific owner-attestation features, while all other fields remain standard NIP-01.

### Where is the NIP-01 event validation implemented in the Buzz codebase?

Core validation and serialization helpers reside in [`crates/buzz-sdk/src/event.rs`](https://github.com/block/buzz/blob/main/crates/buzz-sdk/src/event.rs), which handles canonical ID generation and Schnorr signature verification. WebSocket-specific encoding logic appears in [`crates/buzz-ws-client/src/client.rs`](https://github.com/block/buzz/blob/main/crates/buzz-ws-client/src/client.rs). The relay rejects malformed events that deviate from the seven-field NIP-01 structure or contain invalid hexadecimal encoding.