NIP-1

NIP-1 outlines the basic NOSTR protocol, defining event structure, communication between clients and relays via WebSockets, and the initial event kinds for user metadata, text notes, and recommended s

NIP-1

NIP-1 provides the basic protocol that should be implemented by all participants in the NOSTR network. It defines the structure and communication of events, the main object type in the network. Events have the following format:

• id: SHA256 hash of the serialized event data.

• pubkey: Public key of the event creator (lowercase hex-encoded).

• created_at: Unix timestamp in seconds.

• kind: Integer representing the type of event.

• tags: Array of arrays containing references to other events or public keys.

• content: Arbitrary string.

• sig: Signature of the event's SHA256 hash.

Events are serialized in a specific format, and the protocol uses the secp256k1 curve with Schnorr signatures for signing and encoding.

Communication between clients and relays happens through a WebSocket. Clients send messages to relays with one of the following formats:

1. ["EVENT", <event JSON>]: Publish an event.

2. ["REQ", <subscription_id>, <filters JSON>]: Request events and subscribe to updates.

3. ["CLOSE", <subscription_id>]: Stop previous subscriptions.

Filters define which events will be sent in a subscription and can include attributes like ids, authors, kinds, #e, #p, since, until, and limit.

Relays send messages to clients in these formats:

1. ["EVENT", <subscription_id>, <event JSON>]: Send requested events.

2. ["EOSE", <subscription_id>]: Indicate the end of stored events and the beginning of real-time updates.

3. ["NOTICE", <message>]: Send human-readable error messages or other information.

NIP-1 also defines three basic event kinds:

1. set_metadata: Contains user information like name, about, and picture URL.

2. text_note: Contains plaintext content of a note.

3. recommend_server: Contains the URL of a recommended relay.

Clients should use only one WebSocket per relay, and NIP-1 introduces "e" and "p" tags to store references to other events or public keys, respectively. The recommended relay URL in tags can be used to increase censorship resistance and ease the spread of relay addresses across clients.