Nostr Protocol is still evolving. It is flexible and open for anyone to propose and add new features – from real-time databases to Lightning Tips and More! With this article we explore basics of some of the currently active NIPs (Nostr Protocols Implementation). For a full summary of all of the NIPs you can check this post here.
NIP-01: Basic protocol flow description
Summary
NIP-01 is a protocol for communication between clients and relays. It involves the exchange of events, which are objects that contain various pieces of information, such as a unique ID, a timestamp, and tags. Clients can send three types of messages to relays:
- “EVENT” messages, which are used to publish events;
- “REQ” messages, which are used to request events and subscribe to updates; and
- “CLOSE” messages, which are used to stop subscriptions.
The protocol also includes a system for filtering events based on various criteria, such as the event ID, the author’s public key, and the timestamp. Relays should store events they receive and use them to respond to REQ messages from clients, sending back events that match the specified filters.
Example
{
"id": <32-bytes sha256 of the the serialized event data>
"pubkey": <32-bytes hex-encoded public key of the event creator>,
"created_at": ,
"kind": ,
"tags": [
["e", <32-bytes hex of the id of another event>, ],
["p", <32-bytes hex of the key>, ],
… // other kinds of tags may be included later
],
"content": ,
"sig": <64-bytes signature of the sha256 hash of the serialized event data, which is the same as the "id" field>
}What’s cool and innovative about it?
One of the cool and innovative aspects of NIP-01 is its decentralized nature. The protocol does not rely on any central servers or authorities, which means that it is resistant to censorship and other forms of control. This makes it a powerful tool for creating a global social network that is open to everyone and can’t be easily shut down or manipulated. The use of cryptographic keys and signatures also ensures the integrity and security of the communication between clients and relays, making it a tamper-proof system. Additionally, the protocol’s ability to filter events based on various criteria allows users to easily find and access the specific content they are interested in, making it a highly efficient and user-friendly system.
NIP-02: Contact List and Petnames
Summary
NIP-02 is a protocol for handling contact lists and petnames, which are user-defined names for other users. It involves the use of a special type of event, called a “contact list” event, which has a kind of 3 and contains a list of tags representing the profiles that the user is following. Each tag includes the public key of the profile, a relay URL where events from that profile can be found, and a local name or “petname” for the profile. Contact list events can be used for several purposes, such as backing up a user’s list of followed profiles, discovering new profiles to follow, and sharing relay information to increase censorship resistance. They can also be used to construct local “petname” tables, which allow clients to display user-friendly names for profiles instead of just public keys.
Example
{
"kind": 3,
"tags": [
["p", "91cf9..4e5ca", "wss://alicerelay.com/", "alice"],
["p", "14aeb..8dad4", "wss://bobrelay.com/nostr", "bob"],
["p", "612ae..e610f", "ws://carolrelay.com/ws", "carol"]
],
"content": "",
…other fieldsWhat’s cool and innovative about it?
Overall, NIP-02 is innovative because it provides a way for users to organize and manage their interactions with other profiles in a decentralized network. It allows users to give meaningful names to the profiles they follow, which can make it easier to understand and navigate the network. Additionally, the use of contact list events allows for various practical applications, such as backup and discovery, which can enhance the user experience in a decentralized network. The ability to share relay information can also increase censorship resistance, which is a key feature in a decentralized network where there is no central authority controlling access to information.
NIP-03: OpenTimestamps Attestations for Events
Summary
NIP-03 describes the use of OpenTimestamps (OTS) in an event, which is a type of data structure used to provide an attestation of the age of the event. When an OTS is available, it may be included in the event body under the “ots” key. The event’s ID must be used as the raw hash to be included in the OpenTimestamps merkle tree. The attestation provided by the OTS can be added by either relays or clients when the event is first uploaded to the relays. It can be used by clients to show that an event is at least as old as the OTS date.
Example
{
id: ...,
kind: ...,
...,
...,
ots: <base64-encoded OTS file data>
}What’s cool and innovative about it?
One cool and innovative aspect of NIP-03 is the use of OpenTimestamps to provide an attestation of the age of an event. This allows for a tamper-proof way to verify the authenticity and age of an event, which can be useful for a variety of purposes. Additionally, the fact that the attestation can be added by either relays or clients gives users flexibility in how they choose to verify the age of their events. Overall, the use of OpenTimestamps in NIP-03 adds an additional layer of security and trust to the Nostr protocol.
NIP-04: Encrypted Direct Message
Summary
NIP-04 describes the “encrypted direct message” event, which is a way for users to send private messages to each other. The content of the message is encrypted so that only the intended recipient can read it. The message also includes information about who the recipient is and, optionally, what message it is in response to. The encryption is done using a shared secret that is generated by combining the recipient’s public key with the sender’s private key. The message is structured in a specific way and can be generated using the provided code sample in JavaScript.
Example
import crypto from 'crypto'
import * as secp from 'noble-secp256k1'
let sharedPoint = secp.getSharedSecret(ourPrivateKey, '02' + theirPublicKey)
let sharedX = sharedPoint.substr(2, 64)
let iv = crypto.randomFillSync(new Uint8Array(16))
var cipher = crypto.createCipheriv(
'aes-256-cbc',
Buffer.from(sharedX, 'hex'),
iv
)
let encryptedMessage = cipher.update(text, 'utf8', 'base64')
encryptedMessage += cipher.final('base64')
let ivBase64 = Buffer.from(iv.buffer).toString('base64')
let event = {
pubkey: ourPubKey,
created_at: Math.floor(Date.now() / 1000),
kind: 4,
tags: [['p', theirPublicKey]],
content: encryptedMessage + '?iv=' + ivBase64
}NIP-05: Mapping Nostr keys to DNS-based internet identifiers
Summary
NIP-05 allows users to create an internet identifier (an email-like address) and associate it with their public key. This way, other users can use the identifier to find and verify the corresponding public key. To do this, a client can make a request to a specific URL using the domain and local part of the identifier. The server at that URL should return a JSON document with a mapping of names to public keys, and the client can check if the public key for the given name matches the pubkey from the event. This feature can be used to allow users to search for and discover other profiles and to show identifiers instead of long public keys. Additionally, JavaScript Nostr apps may need to ensure that the server serving the /.well-known/nostr.json file includes the HTTP header Access-Control-Allow-Origin: * to allow them to access the file.
Example
Request
If a client sees an event like this:
{
"pubkey": "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9",
"kind": 0,
"content": "{\"name\": \"bob\", \"nip05\": \"bob@example.com\"}"
…
}It will make a GET request to https://example.com/.well-known/nostr.json?name=bob and get back a response that will look like
Response
{
"names": {
"bob": "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9"
}
}NIP-06: Basic key derivation from mnemonic seed phrase
Summary
NIP-06 describes a process where a mnemonic seed phrase is used to generate a binary seed using BIP39. This seed is then used to generate a specific key using BIP32. This key is used as the default for a basic, single-key client. Other types of clients can also use this process to generate keys for their own purposes, possibly using different derivation paths.
What’s cool and innovative about it?
One innovative aspect of this process is the use of BIP39 and BIP32, which are established standards for generating and managing cryptographic keys. This helps to ensure the security and reliability of the key generation process. Additionally, the fact that the process can be customized for different types of clients adds flexibility and versatility. The ability to use different derivation paths allows for the creation of keys for a variety of different purposes and contexts. Overall, the use of these standardized and customizable key generation processes can help to make the NOSTR protocol more secure and effective.
NIP-08: Handling Mentions
Summary
NIP-08 In simple terms, explains how clients should handle mentions of other events or pubkeys (a type of key used for identification and encryption in Nostr) inside text_notes (a type of event used to store text messages). When a client wants to allow users to mention other events or pubkeys, it must provide a way for the user to do so (such as a button or an autocomplete feature). The client must then add the mentioned event or pubkey to the event’s tags and replace the mention in the event’s content with a notation like “#[index]”, where “index” is the position of the mentioned item in the tags array. When a client receives a text_note event with these mentions, it can search for and replace them with the actual event or pubkey information, and may also provide additional context or links to the mentioned event or pubkey.
What’s cool and innovative about it?
One innovative aspect of NIP-08 is the use of a notation like “#[index]” to represent mentions of other events or pubkeys. This allows clients to easily identify and handle these mentions in a consistent and standardized way, without requiring the client to understand the content of the mention itself. Additionally, the use of tags to store the mentioned events or pubkeys allows clients to easily reference and display the actual information associated with these mentions, potentially providing a richer and more interactive experience for users. Overall, NIP-08’s approach to handling mentions in text_notes offers a flexible and scalable way for clients to support this feature, while also ensuring that the process is handled consistently across different clients.
NIP-09 is a protocol for storing and sharing files within the Nostr network.
Files in Nostr are stored as events, with the file content being included in the “ots” key of the event body. The event’s ID is used as the raw hash to be included in the OpenTimestamps merkle tree, providing an attestation of the age of the file.
Clients can store files by uploading them to relays using the “EVENT” message, with the file content being included in the “ots” key. Relays will store the event and respond to requests for the file from other clients.
In addition to simply storing and sharing files, NIP-09 also includes support for file versions and file deletion. When a file is updated, a new event is created with a new ID and the previous version of the file is included in the “prev” key. When a file is deleted, an event with a “deleted” key set to true is created, indicating that the file should no longer be shared.