NIPs

NIPs stand for Nostr Implementation Possibilities.

They exist to document what may be implemented by Nostr -compatible relay and client software.

• List
• Event Kinds
• Message Types
  • Client to Relay
  • Relay to Client
• Standardized Tags
• Criteria for acceptance of NIPs
• Is this repository a centralizing factor?
• How this repository works
• Breaking Changes
• License

List

• NIP-01: Basic protocol flow description
• NIP-02: Follow List
• NIP-03: OpenTimestamps Attestations for Events
• NIP-04: Encrypted Direct Message — unrecommended: deprecated in favor of NIP-17
• NIP-05: Mapping Nostr keys to DNS-based internet identifiers
• NIP-06: Basic key derivation from mnemonic seed phrase
• NIP-07: window.nostr capability for web browsers
• NIP-08: Handling Mentions — unrecommended: deprecated in favor of NIP-27
• NIP-09: Event Deletion Request
• NIP-10: Conventions for clients’ use of e and p tags in text events
• NIP-11: Relay Information Document
• NIP-13: Proof of Work
• NIP-14: Subject tag in text events
• NIP-15: Nostr Marketplace (for resilient marketplaces)
• NIP-17: Private Direct Messages
• NIP-18: Reposts
• NIP-19: bech32-encoded entities
• NIP-21: nostr: URI scheme
• NIP-22: Comment
• NIP-23: Long-form Content
• NIP-24: Extra metadata fields and tags
• NIP-25: Reactions
• NIP-26: Delegated Event Signing
• NIP-27: Text Note References
• NIP-28: Public Chat
• NIP-29: Relay-based Groups
• NIP-30: Custom Emoji
• NIP-31: Dealing with Unknown Events
• NIP-32: Labeling
• NIP-34: git stuff
• NIP-35: Torrents
• NIP-36: Sensitive Content
• NIP-38: User Statuses
• NIP-39: External Identities in Profiles
• NIP-40: Expiration Timestamp
• NIP-42: Authentication of clients to relays
• NIP-44: Versioned Encryption
• NIP-45: Counting results
• NIP-46: Nostr Connect
• NIP-47: Wallet Connect
• NIP-48: Proxy Tags
• NIP-49: Private Key Encryption
• NIP-50: Search Capability
• NIP-51: Lists
• NIP-52: Calendar Events
• NIP-53: Live Activities
• NIP-54: Wiki
• NIP-55: Android Signer Application
• NIP-56: Reporting
• NIP-57: Lightning Zaps
• NIP-58: Badges
• NIP-59: Gift Wrap
• NIP-60: Cashu Wallet
• NIP-61: Nutzaps
• NIP-64: Chess (PGN)
• NIP-65: Relay List Metadata
• NIP-69: Peer-to-peer Order events
• NIP-70: Protected Events
• NIP-71: Video Events
• NIP-72: Moderated Communities
• NIP-73: External Content IDs
• NIP-75: Zap Goals
• NIP-78: Application-specific data
• NIP-84: Highlights
• NIP-89: Recommended Application Handlers
• NIP-90: Data Vending Machines
• NIP-92: Media Attachments
• NIP-94: File Metadata
• NIP-96: HTTP File Storage Integration
• NIP-98: HTTP Auth
• NIP-99: Classified Listings

Event Kinds

Message types

Client to Relay

Relay to Client

Standardized Tags

Please update these lists when proposing new NIPs.

Criteria for acceptance of NIPs

1. They should be fully implemented in at least two clients and one relay – when applicable.
2. They should make sense.
3. They should be optional and backwards-compatible: care must be taken such that clients and relays that choose to not implement them do not stop working when interacting with the ones that choose to.
4. There should be no more than one way of doing the same thing.
5. Other rules will be made up when necessary.

Is this repository a centralizing factor?

To promote interoperability, we standards that everybody can follow, and we need them to define a single way of doing each thing without ever hurting backwards-compatibility, and for that purpose there is no way around getting everybody to agree on the same thing and keep a centralized index of these standards. However the fact that such index exists doesn’t hurt the decentralization of Nostr. At any point the central index can be challenged if it is failing to fulfill the needs of the protocol and it can migrate to other places and be maintained by other people.

It can even fork into multiple and then some clients would go one way, others would go another way, and some clients would adhere to both competing standards. This would hurt the simplicity, openness and interoperability of Nostr a little, but everything would still work in the short term.

There is a list of notable Nostr software developers who have commit access to this repository, but that exists mostly for practical reasons, as by the nature of the thing we’re dealing with the repository owner can revoke membership and rewrite history as they want – and if these actions are unjustified or perceived as bad or evil the community must react.

How this repository works

Standards may emerge in two ways: the first way is that someone starts doing something, then others copy it; the second way is that someone has an idea of a new standard that could benefit multiple clients and the protocol in general without breaking backwards-compatibility and the principle of having a single way of doing things, then they write that idea and submit it to this repository, other interested parties read it and give their feedback, then once most people reasonably agree we codify that in a NIP which client and relay developers that are interested in the feature can proceed to implement.

These two ways of standardizing things are supported by this repository. Although the second is preferred, an effort will be made to codify standards emerged outside this repository into NIPs that can be later referenced and easily understood and implemented by others – but obviously as in any human system discretion may be applied when standards are considered harmful.

Breaking Changes

Breaking Changes

License

All NIPs are public domain.

Contributors

NIP-01

Basic protocol flow description

draft mandatory

This NIP defines the basic protocol that should be implemented by everybody. New NIPs may add new optional (or mandatory) fields and messages and features to the structures and flows described here.

Events and signatures

Each user has a keypair. Signatures, public key, and encodings are done according to the Schnorr signatures standard for the curve secp256k1 .

The only object type that exists is the event, which has the following format on the wire:

{
  "id": <32-bytes lowercase hex-encoded sha256 of the serialized event data>,
  "pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,
  "created_at": <unix timestamp in seconds>,
  "kind": <integer between 0 and 65535>,
  "tags": [
    [<arbitrary string>...],
    // ...
  ],
  "content": <arbitrary string>,
  "sig": <64-bytes lowercase hex of the signature of the sha256 hash of the serialized event data, which is the same as the "id" field>
}

To obtain the event.id, we sha256 the serialized event. The serialization is done over the UTF-8 JSON-serialized string (which is described below) of the following structure:

[
  0,
  <pubkey, as a lowercase hex string>,
  <created_at, as a number>,
  <kind, as a number>,
  <tags, as an array of arrays of non-null strings>,
  <content, as a string>
]

To prevent implementation differences from creating a different event ID for the same event, the following rules MUST be followed while serializing:

• UTF-8 should be used for encoding.
• Whitespace, line breaks or other unnecessary formatting should not be included in the output JSON.
• The following characters in the content field must be escaped as shown, and all other characters must be included verbatim:
  • A line break (0x0A), use \n
  • A double quote (0x22), use \"
  • A backslash (0x5C), use \\
  • A carriage return (0x0D), use \r
  • A tab character (0x09), use \t
  • A backspace, (0x08), use \b
  • A form feed, (0x0C), use \f

Tags

Each tag is an array of one or more strings, with some conventions around them. Take a look at the example below:

{
  "tags": [
    ["e", "5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36", "wss://nostr.example.com"],
    ["p", "f7234bd4c1394dda46d09f35bd384dd30cc552ad5541990f98844fb06676e9ca"],
    ["a", "30023:f7234bd4c1394dda46d09f35bd384dd30cc552ad5541990f98844fb06676e9ca:abcd", "wss://nostr.example.com"],
    ["alt", "reply"],
    // ...
  ],
  // ...
}

The first element of the tag array is referred to as the tag name or key and the second as the tag value. So we can safely say that the event above has an e tag set to "5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36", an alt tag set to "reply" and so on. All elements after the second do not have a conventional name.

This NIP defines 3 standard tags that can be used across all event kinds with the same meaning. They are as follows:

• The e tag, used to refer to an event: ["e", <32-bytes lowercase hex of the id of another event>, <recommended relay URL, optional>]
• The p tag, used to refer to another user: ["p", <32-bytes lowercase hex of a pubkey>, <recommended relay URL, optional>]
• The a tag, used to refer to an addressable or replaceable event
  • for an addressable event: ["a", <kind integer>:<32-bytes lowercase hex of a pubkey>:<d tag value>, <recommended relay URL, optional>]
  • for a normal replaceable event: ["a", <kind integer>:<32-bytes lowercase hex of a pubkey>:, <recommended relay URL, optional>]

As a convention, all single-letter (only english alphabet letters: a-z, A-Z) key tags are expected to be indexed by relays, such that it is possible, for example, to query or subscribe to events that reference the event "5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36" by using the {"#e": ["5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36"]} filter. Only the first value in any given tag is indexed.

Kinds

Kinds specify how clients should interpret the meaning of each event and the other fields of each event (e.g. an "r" tag may have a meaning in an event of kind 1 and an entirely different meaning in an event of kind 10002). Each NIP may define the meaning of a set of kinds that weren’t defined elsewhere. This NIP defines two basic kinds:

• 0: user metadata: the content is set to a stringified JSON object {name: <username>, about: <string>, picture: <url, string>} describing the user who created the event. Extra metadata fields may be set. A relay may delete older events once it gets a new one for the same pubkey.
• 1: text note: the content is set to the plaintext content of a note (anything the user wants to say). Content that must be parsed, such as Markdown and HTML, should not be used. Clients should also not parse content as those.

And also a convention for kind ranges that allow for easier experimentation and flexibility of relay implementation:

• for kind n such that 1000 <= n < 10000 || 4 <= n < 45 || n == 1 || n == 2, events are regular, which means they’re all expected to be stored by relays.
• for kind n such that 10000 <= n < 20000 || n == 0 || n == 3, events are replaceable, which means that, for each combination of pubkey and kind, only the latest event MUST be stored by relays, older versions MAY be discarded.
• for kind n such that 20000 <= n < 30000, events are ephemeral, which means they are not expected to be stored by relays.
• for kind n such that 30000 <= n < 40000, events are addressable by their kind, pubkey and d tag value – which means that, for each combination of kind, pubkey and the d tag value, only the latest event MUST be stored by relays, older versions MAY be discarded.

In case of replaceable events with the same timestamp, the event with the lowest id (first in lexical order) should be retained, and the other discarded.

When answering to REQ messages for replaceable events such as {"kinds":[0],"authors":[<hex-key>]}, even if the relay has more than one version stored, it SHOULD return just the latest one.

These are just conventions and relay implementations may differ.

Communication between clients and relays

Relays expose a websocket endpoint to which clients can connect. Clients SHOULD open a single websocket connection to each relay and use it for all their subscriptions. Relays MAY limit number of connections from specific IP/client/etc.

From client to relay: sending events and creating subscriptions

Clients can send 3 types of messages, which must be JSON arrays, according to the following patterns:

• ["EVENT", <event JSON as defined above>], used to publish events.
• ["REQ", <subscription_id>, <filters1>, <filters2>, ...], used to request events and subscribe to new updates.
• ["CLOSE", <subscription_id>], used to stop previous subscriptions.

<subscription_id> is an arbitrary, non-empty string of max length 64 chars. It represents a subscription per connection. Relays MUST manage <subscription_id>s independently for each WebSocket connection. <subscription_id>s are not guaranteed to be globally unique.

<filtersX> is a JSON object that determines what events will be sent in that subscription, it can have the following attributes:

{
  "ids": <a list of event ids>,
  "authors": <a list of lowercase pubkeys, the pubkey of an event must be one of these>,
  "kinds": <a list of a kind numbers>,
  "#<single-letter (a-zA-Z)>": <a list of tag values, for #e — a list of event ids, for #p — a list of pubkeys, etc.>,
  "since": <an integer unix timestamp in seconds. Events must have a created_at >= to this to pass>,
  "until": <an integer unix timestamp in seconds. Events must have a created_at <= to this to pass>,
  "limit": <maximum number of events relays SHOULD return in the initial query>
}

Upon receiving a REQ message, the relay SHOULD return events that match the filter. Any new events it receives SHOULD be sent to that same websocket until the connection is closed, a CLOSE event is received with the same <subscription_id>, or a new REQ is sent using the same <subscription_id> (in which case a new subscription is created, replacing the old one).

Filter attributes containing lists (ids, authors, kinds and tag filters like #e) are JSON arrays with one or more values. At least one of the arrays’ values must match the relevant field in an event for the condition to be considered a match. For scalar event attributes such as authors and kind, the attribute from the event must be contained in the filter list. In the case of tag attributes such as #e, for which an event may have multiple values, the event and filter condition values must have at least one item in common.

The ids, authors, #e and #p filter lists MUST contain exact 64-character lowercase hex values.

The since and until properties can be used to specify the time range of events returned in the subscription. If a filter includes the since property, events with created_at greater than or equal to since are considered to match the filter. The until property is similar except that created_at must be less than or equal to until. In short, an event matches a filter if since <= created_at <= until holds.

All conditions of a filter that are specified must match for an event for it to pass the filter, i.e., multiple conditions are interpreted as && conditions.

A REQ message may contain multiple filters. In this case, events that match any of the filters are to be returned, i.e., multiple filters are to be interpreted as || conditions.

The limit property of a filter is only valid for the initial query and MUST be ignored afterwards. When limit: n is present it is assumed that the events returned in the initial query will be the last n events ordered by the created_at. Newer events should appear first, and in the case of ties the event with the lowest id (first in lexical order) should be first. It is safe to return less events than limit specifies, but it is expected that relays do not return (much) more events than requested so clients don’t get unnecessarily overwhelmed by data.

From relay to client: sending events and notices

Relays can send 5 types of messages, which must also be JSON arrays, according to the following patterns:

• ["EVENT", <subscription_id>, <event JSON as defined above>], used to send events requested by clients.
• ["OK", <event_id>, <true|false>, <message>], used to indicate acceptance or denial of an EVENT message.
• ["EOSE", <subscription_id>], used to indicate the end of stored events and the beginning of events newly received in real-time.
• ["CLOSED", <subscription_id>, <message>], used to indicate that a subscription was ended on the server side.
• ["NOTICE", <message>], used to send human-readable error messages or other things to clients.

This NIP defines no rules for how NOTICE messages should be sent or treated.

• EVENT messages MUST be sent only with a subscription ID related to a subscription previously initiated by the client (using the REQ message above).
• OK messages MUST be sent in response to EVENT messages received from clients, they must have the 3rd parameter set to true when an event has been accepted by the relay, false otherwise. The 4th parameter MUST always be present, but MAY be an empty string when the 3rd is true, otherwise it MUST be a string formed by a machine-readable single-word prefix followed by a : and then a human-readable message. Some examples:
  • ["OK", "b1a649ebe8...", true, ""]
  • ["OK", "b1a649ebe8...", true, "pow: difficulty 25>=24"]
  • ["OK", "b1a649ebe8...", true, "duplicate: already have this event"]
  • ["OK", "b1a649ebe8...", false, "blocked: you are banned from posting here"]
  • ["OK", "b1a649ebe8...", false, "blocked: please register your pubkey at https://my-expensive-relay.example.com"]
  • ["OK", "b1a649ebe8...", false, "rate-limited: slow down there chief"]
  • ["OK", "b1a649ebe8...", false, "invalid: event creation date is too far off from the current time"]
  • ["OK", "b1a649ebe8...", false, "pow: difficulty 26 is less than 30"]
  • ["OK", "b1a649ebe8...", false, "error: could not connect to the database"]
• CLOSED messages MUST be sent in response to a REQ when the relay refuses to fulfill it. It can also be sent when a relay decides to kill a subscription on its side before a client has disconnected or sent a CLOSE. This message uses the same pattern of OK messages with the machine-readable prefix and human-readable message. Some examples:
  • ["CLOSED", "sub1", "unsupported: filter contains unknown elements"]
  • ["CLOSED", "sub1", "error: could not connect to the database"]
  • ["CLOSED", "sub1", "error: shutting down idle subscription"]
• The standardized machine-readable prefixes for OK and CLOSED are: duplicate, pow, blocked, rate-limited, invalid, and error for when none of that fits.

NIP-02

Follow List

final optional

A special event with kind 3, meaning “follow list” is defined as having a list of p tags, one for each of the followed/known profiles one is following.

Each tag entry should contain the key for the profile, a relay URL where events from that key can be found (can be set to an empty string if not needed), and a local name (or “petname”) for that profile (can also be set to an empty string or not provided), i.e., ["p", <32-bytes hex key>, <main relay URL>, <petname>].

The .content is not used.

For 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 fields...
}

Every new following list that gets published overwrites the past ones, so it should contain all entries. Relays and clients SHOULD delete past following lists as soon as they receive a new one.

Whenever new follows are added to an existing list, clients SHOULD append them to the end of the list, so they are stored in chronological order.

Uses

Follow list backup

If one believes a relay will store their events for sufficient time, they can use this kind-3 event to backup their following list and recover on a different device.

Profile discovery and context augmentation

A client may rely on the kind-3 event to display a list of followed people by profiles one is browsing; make lists of suggestions on who to follow based on the follow lists of other people one might be following or browsing; or show the data in other contexts.

Relay sharing

A client may publish a follow list with good relays for each of their follows so other clients may use these to update their internal relay lists if needed, increasing censorship-resistance.

Petname scheme

The data from these follow lists can be used by clients to construct local “petname” tables derived from other people’s follow lists. This alleviates the need for global human-readable names. For example:

A user has an internal follow list that says

[
  ["p", "21df6d143fb96c2ec9d63726bf9edc71", "", "erin"]
]

And receives two follow lists, one from 21df6d143fb96c2ec9d63726bf9edc71 that says

[
  ["p", "a8bb3d884d5d90b413d9891fe4c4e46d", "", "david"]
]

and another from a8bb3d884d5d90b413d9891fe4c4e46d that says

[
  ["p", "f57f54057d2a7af0efecc8b0b66f5708", "", "frank"]
]

When the user sees 21df6d143fb96c2ec9d63726bf9edc71 the client can show erin instead; When the user sees a8bb3d884d5d90b413d9891fe4c4e46d the client can show david.erin instead; When the user sees f57f54057d2a7af0efecc8b0b66f5708 the client can show frank.david.erin instead.

NIP-03

OpenTimestamps Attestations for Events

draft optional

This NIP defines an event with kind:1040 that can contain an OpenTimestamps proof for any other event:

{
  "kind": 1040
  "tags": [
    ["e", <event-id>, <relay-url>],
    ["alt", "opentimestamps attestation"]
  ],
  "content": <base64-encoded OTS file data>
}

• The OpenTimestamps proof MUST prove the referenced e event id as its digest.
• The content MUST be the full content of an .ots file containing at least one Bitcoin attestation. This file SHOULD contain a single Bitcoin attestation (as not more than one valid attestation is necessary and less bytes is better than more) and no reference to “pending” attestations since they are useless in this context.

Example OpenTimestamps proof verification flow

Using nak , jq and ots :

~> nak req -i e71c6ea722987debdb60f81f9ea4f604b5ac0664120dd64fb9d23abc4ec7c323 wss://nostr-pub.wellorder.net | jq -r .content | ots verify
> using an esplora server at https://blockstream.info/api
- sequence ending on block 810391 is valid
timestamp validated at block [810391]

Warning unrecommended: deprecated in favor of NIP-17

NIP-04

Encrypted Direct Message

final unrecommended optional

A special event with kind 4, meaning “encrypted direct message”. It is supposed to have the following attributes:

content MUST be equal to the base64-encoded, aes-256-cbc encrypted string of anything a user wants to write, encrypted using a shared cipher generated by combining the recipient’s public-key with the sender’s private-key; this appended by the base64-encoded initialization vector as if it was a querystring parameter named “iv”. The format is the following: "content": "<encrypted_text>?iv=<initialization_vector>".

tags MUST contain an entry identifying the receiver of the message (such that relays may naturally forward this event to them), in the form ["p", "<pubkey, as a hex string>"].

tags MAY contain an entry identifying the previous message in a conversation or a message we are explicitly replying to (such that contextual, more organized conversations may happen), in the form ["e", "<event_id>"].

Note: By default in the libsecp256k1 ECDH implementation, the secret is the SHA256 hash of the shared point (both X and Y coordinates). In Nostr, only the X coordinate of the shared point is used as the secret and it is NOT hashed. If using libsecp256k1, a custom function that copies the X coordinate must be passed as the hashfp argument in secp256k1_ecdh. See here .

Code sample for generating such an event in JavaScript:

import crypto from 'crypto'
import * as secp from '@noble/secp256k1'

let sharedPoint = secp.getSharedSecret(ourPrivateKey, '02' + theirPublicKey)
let sharedX = sharedPoint.slice(1, 33)

let iv = crypto.randomFillSync(new Uint8Array(16))
var cipher = crypto.createCipheriv(
  'aes-256-cbc',
  Buffer.from(sharedX),
  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
}

Security Warning

This standard does not go anywhere near what is considered the state-of-the-art in encrypted communication between peers, and it leaks metadata in the events, therefore it must not be used for anything you really need to keep secret, and only with relays that use AUTH to restrict who can fetch your kind:4 events.

Client Implementation Warning

Clients should not search and replace public key or note references from the .content. If processed like a regular text note (where @npub... is replaced with #[0] with a ["p", "..."] tag) the tags are leaked and the mentioned user will receive the message in their inbox.

NIP-05

Mapping Nostr keys to DNS-based internet identifiers

final optional

On events of kind 0 (user metadata) one can specify the key "nip05" with an internet identifier (an email-like address) as the value. Although there is a link to a very liberal “internet identifier” specification above, NIP-05 assumes the <local-part> part will be restricted to the characters a-z0-9-_., case-insensitive.

Upon seeing that, the client splits the identifier into <local-part> and <domain> and use these values to make a GET request to https://<domain>/.well-known/nostr.json?name=<local-part>.

The result should be a JSON document object with a key "names" that should then be a mapping of names to hex formatted public keys. If the public key for the given <name> matches the pubkey from the user's metadata event, the client then concludes that the given pubkey can indeed be referenced by its identifier.

Example

If a client sees an event like this:

{
  "pubkey": "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9",
  "kind": 0,
  "content": "{\"name\": \"bob\", \"nip05\": \"bob@example.com\"}"
  // other fields...
}

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

{
  "names": {
    "bob": "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9"
  }
}

or with the recommended "relays" attribute:

{
  "names": {
    "bob": "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9"
  },
  "relays": {
    "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9": [ "wss://relay.example.com", "wss://relay2.example.com" ]
  }
}

If the pubkey matches the one given in "names" (as in the example above) that means the association is right and the "nip05" identifier is valid and can be displayed.

The recommended "relays" attribute may contain an object with public keys as properties and arrays of relay URLs as values. When present, that can be used to help clients learn in which relays the specific user may be found. Web servers which serve /.well-known/nostr.json files dynamically based on the query string SHOULD also serve the relays data for any name they serve in the same reply when that is available.

Finding users from their NIP-05 identifier

A client may implement support for finding users’ public keys from internet identifiers, the flow is the same as above, but reversed: first the client fetches the well-known URL and from there it gets the public key of the user, then it tries to fetch the kind 0 event for that user and check if it has a matching "nip05".

Notes

Identification, not verification

The NIP-05 is not intended to verify a user, but only to identify them, for the purpose of facilitating the exchange of a contact or their search.
Exceptions are people who own (e.g., a company) or are connected (e.g., a project) to a well-known domain, who can exploit NIP-05 as an attestation of their relationship with it, and thus to the organization behind it, thereby gaining an element of trust.

User discovery implementation suggestion

A client can use this to allow users to search other profiles. If a client has a search box or something like that, a user may be able to type “bob@example.com ” there and the client would recognize that and do the proper queries to obtain a pubkey and suggest that to the user.

Clients must always follow public keys, not NIP-05 addresses

For example, if after finding that bob@bob.com has the public key abc...def, the user clicks a button to follow that profile, the client must keep a primary reference to abc...def, not bob@bob.com. If, for any reason, the address https://bob.com/.well-known/nostr.json?name=bob starts returning the public key 1d2...e3f at any time in the future, the client must not replace abc...def in his list of followed profiles for the user (but it should stop displaying “bob@bob.com ” for that user, as that will have become an invalid "nip05" property).

Public keys must be in hex format

Keys must be returned in hex format. Keys in NIP-19 npub format are only meant to be used for display in client UIs, not in this NIP.

Showing just the domain as an identifier

Clients may treat the identifier _@domain as the “root” identifier, and choose to display it as just the <domain>. For example, if Bob owns bob.com, he may not want an identifier like bob@bob.com as that is redundant. Instead, Bob can use the identifier _@bob.com and expect Nostr clients to show and treat that as just bob.com for all purposes.

Reasoning for the /.well-known/nostr.json?name=<local-part> format

By adding the <local-part> as a query string instead of as part of the path, the protocol can support both dynamic servers that can generate JSON on-demand and static servers with a JSON file in it that may contain multiple names.

Allowing access from JavaScript apps

JavaScript Nostr apps may be restricted by browser CORS policies that prevent them from accessing /.well-known/nostr.json on the user’s domain. When CORS prevents JS from loading a resource, the JS program sees it as a network failure identical to the resource not existing, so it is not possible for a pure-JS app to tell the user for certain that the failure was caused by a CORS issue. JS Nostr apps that see network failures requesting /.well-known/nostr.json files may want to recommend to users that they check the CORS policy of their servers, e.g.:

$ curl -sI https://example.com/.well-known/nostr.json?name=bob | grep -i ^Access-Control
Access-Control-Allow-Origin: *

Users should ensure that their /.well-known/nostr.json is served with the HTTP header Access-Control-Allow-Origin: * to ensure it can be validated by pure JS apps running in modern browsers.

Security Constraints

The /.well-known/nostr.json endpoint MUST NOT return any HTTP redirects.

Fetchers MUST ignore any HTTP redirects given by the /.well-known/nostr.json endpoint.

NIP-06

Basic key derivation from mnemonic seed phrase

draft optional

BIP39 is used to generate mnemonic seed words and derive a binary seed from them.

BIP32 is used to derive the path m/44'/1237'/<account>'/0/0 (according to the Nostr entry on SLIP44 ).

A basic client can simply use an account of 0 to derive a single key. For more advanced use-cases you can increment account, allowing generation of practically infinite keys from the 5-level path with hardened derivation.

Other types of clients can still get fancy and use other derivation paths for their own other purposes.

Test vectors

mnemonic: leader monkey parrot ring guide accident before fence cannon height naive bean
private key (hex): 7f7ff03d123792d6ac594bfa67bf6d0c0ab55b6b1fdb6249303fe861f1ccba9a
nsec: nsec10allq0gjx7fddtzef0ax00mdps9t2kmtrldkyjfs8l5xruwvh2dq0lhhkp
public key (hex): 17162c921dc4d2518f9a101db33695df1afb56ab82f5ff3e5da6eec3ca5cd917
npub: npub1zutzeysacnf9rru6zqwmxd54mud0k44tst6l70ja5mhv8jjumytsd2x7nu

mnemonic: what bleak badge arrange retreat wolf trade produce cricket blur garlic valid proud rude strong choose busy staff weather area salt hollow arm fade
private key (hex): c15d739894c81a2fcfd3a2df85a0d2c0dbc47a280d092799f144d73d7ae78add
nsec: nsec1c9wh8xy5eqdzln7n5t0ctgxjcrdug73gp5yj0x03gntn67h83twssdfhel
public key (hex): d41b22899549e1f3d335a31002cfd382174006e166d3e658e3a5eecdb6463573
npub: npub16sdj9zv4f8sl85e45vgq9n7nsgt5qphpvmf7vk8r5hhvmdjxx4es8rq74h

NIP-07

window.nostr capability for web browsers

draft optional

The window.nostr object may be made available by web browsers or extensions and websites or web-apps may make use of it after checking its availability.

That object must define the following methods:

async window.nostr.getPublicKey(): string // returns a public key as hex
async window.nostr.signEvent(event: { created_at: number, kind: number, tags: string[][], content: string }): Event // takes an event object, adds `id`, `pubkey` and `sig` and returns it

Aside from these two basic above, the following functions can also be implemented optionally:

async window.nostr.getRelays(): { [url: string]: {read: boolean, write: boolean} } // returns a basic map of relay urls to relay policies
async window.nostr.nip04.encrypt(pubkey, plaintext): string // returns ciphertext and iv as specified in nip-04 (deprecated)
async window.nostr.nip04.decrypt(pubkey, ciphertext): string // takes ciphertext and iv as specified in nip-04 (deprecated)
async window.nostr.nip44.encrypt(pubkey, plaintext): string // returns ciphertext as specified in nip-44
async window.nostr.nip44.decrypt(pubkey, ciphertext): string // takes ciphertext as specified in nip-44

Recommendation to Extension Authors

To make sure that the window.nostr is available to nostr clients on page load, the authors who create Chromium and Firefox extensions should load their scripts by specifying "run_at": "document_end" in the extension’s manifest.

Implementation

See https://github.com/aljazceru/awesome-nostr#nip-07-browser-extensions .

Warning unrecommended: deprecated in favor of NIP-27

NIP-08

Handling Mentions

final unrecommended optional

This document standardizes the treatment given by clients of inline mentions of other events and pubkeys inside the content of text_notes.

Clients that want to allow tagged mentions they MUST show an autocomplete component or something analogous to that whenever the user starts typing a special key (for example, “@”) or presses some button to include a mention etc – or these clients can come up with other ways to unambiguously differentiate between mentions and normal text.

Once a mention is identified, for example, the pubkey 27866e9d854c78ae625b867eefdfa9580434bc3e675be08d2acb526610d96fbe, the client MUST add that pubkey to the .tags with the tag p, then replace its textual reference (inside .content) with the notation #[index] in which “index” is equal to the 0-based index of the related tag in the tags array.

The same process applies for mentioning event IDs.

A client that receives a text_note event with such #[index] mentions in its .content CAN do a search-and-replace using the actual contents from the .tags array with the actual pubkey or event ID that is mentioned, doing any desired context augmentation (for example, linking to the pubkey or showing a preview of the mentioned event contents) it wants in the process.

Where #[index] has an index that is outside the range of the tags array or points to a tag that is not an e or p tag or a tag otherwise declared to support this notation, the client MUST NOT perform such replacement or augmentation, but instead display it as normal text.

NIP-09

Event Deletion Request

draft optional

A special event with kind 5, meaning “deletion request” is defined as having a list of one or more e or a tags, each referencing an event the author is requesting to be deleted. Deletion requests SHOULD include a k tag for the kind of each event being requested for deletion.

The event’s content field MAY contain a text note describing the reason for the deletion request.

For example:

{
  "kind": 5,
  "pubkey": <32-bytes hex-encoded public key of the event creator>,
  "tags": [
    ["e", "dcd59..464a2"],
    ["e", "968c5..ad7a4"],
    ["a", "<kind>:<pubkey>:<d-identifier>"],
    ["k", "1"],
    ["k", "30023"]
  ],
  "content": "these posts were published by accident",
  // other fields...
}

Relays SHOULD delete or stop publishing any referenced events that have an identical pubkey as the deletion request. Clients SHOULD hide or otherwise indicate a deletion request status for referenced events.

Relays SHOULD continue to publish/share the deletion request events indefinitely, as clients may already have the event that’s intended to be deleted. Additionally, clients SHOULD broadcast deletion request events to other relays which don’t have it.

When an a tag is used, relays SHOULD delete all versions of the replaceable event up to the created_at timestamp of the deletion request event.

Client Usage

Clients MAY choose to fully hide any events that are referenced by valid deletion request events. This includes text notes, direct messages, or other yet-to-be defined event kinds. Alternatively, they MAY show the event along with an icon or other indication that the author has “disowned” the event. The content field MAY also be used to replace the deleted events’ own content, although a user interface should clearly indicate that this is a deletion request reason, not the original content.

A client MUST validate that each event pubkey referenced in the e tag of the deletion request is identical to the deletion request pubkey, before hiding or deleting any event. Relays can not, in general, perform this validation and should not be treated as authoritative.

Clients display the deletion request event itself in any way they choose, e.g., not at all, or with a prominent notice.

Clients MAY choose to inform the user that their request for deletion does not guarantee deletion because it is impossible to delete events from all relays and clients.

Relay Usage

Relays MAY validate that a deletion request event only references events that have the same pubkey as the deletion request itself, however this is not required since relays may not have knowledge of all referenced events.

Deletion Request of a Deletion Request

Publishing a deletion request event against a deletion request has no effect. Clients and relays are not obliged to support “unrequest deletion” functionality.

NIP-10

On “e” and “p” tags in Text Events (kind 1)

draft optional

Abstract

This NIP describes how to use “e” and “p” tags in text events, especially those that are replies to other text events. It helps clients thread the replies into a tree rooted at the original event.

Marked “e” tags (PREFERRED)

["e", <event-id>, <relay-url>, <marker>, <pubkey>]

Where:

• <event-id> is the id of the event being referenced.
• <relay-url> is the URL of a recommended relay associated with the reference. Clients SHOULD add a valid <relay-url> field, but may instead leave it as "".
• <marker> is optional and if present is one of "reply", "root", or "mention".
• <pubkey> is optional, SHOULD be the pubkey of the author of the referenced event

Those marked with "reply" denote the id of the reply event being responded to. Those marked with "root" denote the root id of the reply thread being responded to. For top level replies (those replying directly to the root event), only the "root" marker should be used. Those marked with "mention" denote a quoted or reposted event id.

A direct reply to the root of a thread should have a single marked “e” tag of type “root”.

This scheme is preferred because it allows events to mention others without confusing them with <reply-id> or <root-id>.

<pubkey> SHOULD be the pubkey of the author of the e tagged event, this is used in the outbox model to search for that event from the authors write relays where relay hints did not resolve the event.

The “p” tag

Used in a text event contains a list of pubkeys used to record who is involved in a reply thread.

When replying to a text event E the reply event’s “p” tags should contain all of E’s “p” tags as well as the "pubkey" of the event being replied to.

Example: Given a text event authored by a1 with “p” tags [p1, p2, p3] then the “p” tags of the reply should be [a1, p1, p2, p3] in no particular order.

Deprecated Positional “e” tags

This scheme is not in common use anymore and is here just to keep backward compatibility with older events on the network.

Positional e tags are deprecated because they create ambiguities that are difficult, or impossible to resolve when an event references another but is not a reply.

They use simple e tags without any marker.

["e", <event-id>, <relay-url>] as per NIP-01.

Where:

• <event-id> is the id of the event being referenced.
• <relay-url> is the URL of a recommended relay associated with the reference. Many clients treat this field as optional.

The positions of the “e” tags within the event denote specific meanings as follows:

• No “e” tag:
  This event is not a reply to, nor does it refer to, any other event.

• One “e” tag:
  ["e", <id>]: The id of the event to which this event is a reply.

• Two “e” tags: ["e", <root-id>], ["e", <reply-id>]
<root-id> is the id of the event at the root of the reply chain. <reply-id> is the id of the article to which this event is a reply.

• Many “e” tags: ["e", <root-id>] ["e", <mention-id>], …, ["e", <reply-id>]
  There may be any number of <mention-ids>. These are the ids of events which may, or may not be in the reply chain. They are citing from this event. root-id and reply-id are as above. NIP-11 ======

Relay Information Document

draft optional

Relays may provide server metadata to clients to inform them of capabilities, administrative contacts, and various server attributes. This is made available as a JSON document over HTTP, on the same URI as the relay’s websocket.

When a relay receives an HTTP(s) request with an Accept header of application/nostr+json to a URI supporting WebSocket upgrades, they SHOULD return a document with the following structure.

{
  "name": <string identifying relay>,
  "description": <string with detailed information>,
  "banner": <a link to an image (e.g. in .jpg, or .png format)>,
  "icon": <a link to an icon (e.g. in .jpg, or .png format>,
  "pubkey": <administrative contact pubkey>,
  "contact": <administrative alternate contact>,
  "supported_nips": <a list of NIP numbers supported by the relay>,
  "software": <string identifying relay software URL>,
  "version": <string version identifier>
}

Any field may be omitted, and clients MUST ignore any additional fields they do not understand. Relays MUST accept CORS requests by sending Access-Control-Allow-Origin, Access-Control-Allow-Headers, and Access-Control-Allow-Methods headers.

Field Descriptions

Name

A relay may select a name for use in client software. This is a string, and SHOULD be less than 30 characters to avoid client truncation.

Description

Detailed plain-text information about the relay may be contained in the description string. It is recommended that this contain no markup, formatting or line breaks for word wrapping, and simply use double newline characters to separate paragraphs. There are no limitations on length.

Banner

To make nostr relay management more user friendly, an effort should be made by relay owners to communicate with non-dev non-technical nostr end users. A banner is a visual representation of the relay. It should aim to visually communicate the brand of the relay, complementing the text Description. Here is an example banner mockup as visualized in Damus iOS relay view of the Damus relay.

Icon

Icon is a compact visual representation of the relay for use in UI with limited real estate such as a nostr user’s relay list view. Below is an example URL pointing to an image to be used as an icon for the relay. Recommended to be squared in shape.

{
  "icon": "https://nostr.build/i/53866b44135a27d624e99c6165cabd76ac8f72797209700acb189fce75021f47.jpg",
  // other fields...
}

Pubkey

An administrative contact may be listed with a pubkey, in the same format as Nostr events (32-byte hex for a secp256k1 public key). If a contact is listed, this provides clients with a recommended address to send encrypted direct messages (See NIP-17 ) to a system administrator. Expected uses of this address are to report abuse or illegal content, file bug reports, or request other technical assistance.

Relay operators have no obligation to respond to direct messages.

Contact

An alternative contact may be listed under the contact field as well, with the same purpose as pubkey. Use of a Nostr public key and direct message SHOULD be preferred over this. Contents of this field SHOULD be a URI, using schemes such as mailto or https to provide users with a means of contact.

Supported NIPs

As the Nostr protocol evolves, some functionality may only be available by relays that implement a specific NIP. This field is an array of the integer identifiers of NIPs that are implemented in the relay. Examples would include 1, for "NIP-01" and 9, for "NIP-09". Client-side NIPs SHOULD NOT be advertised, and can be ignored by clients.

Software

The relay server implementation MAY be provided in the software attribute. If present, this MUST be a URL to the project’s homepage.

Version

The relay MAY choose to publish its software version as a string attribute. The string format is defined by the relay implementation. It is recommended this be a version number or commit identifier.

Extra Fields

Server Limitations

These are limitations imposed by the relay on clients. Your client should expect that requests which exceed these practical limitations are rejected or fail immediately.

{
  "limitation": {
    "max_message_length": 16384,
    "max_subscriptions": 20,
    "max_filters": 100,
    "max_limit": 5000,
    "max_subid_length": 100,
    "max_event_tags": 100,
    "max_content_length": 8196,
    "min_pow_difficulty": 30,
    "auth_required": true,
    "payment_required": true,
    "restricted_writes": true,
    "created_at_lower_limit": 31536000,
    "created_at_upper_limit": 3
  },
  // other fields...
}

• max_message_length: this is the maximum number of bytes for incoming JSON that the relay will attempt to decode and act upon. When you send large subscriptions, you will be limited by this value. It also effectively limits the maximum size of any event. Value is calculated from [ to ] and is after UTF-8 serialization (so some unicode characters will cost 2-3 bytes). It is equal to the maximum size of the WebSocket message frame.

• max_subscriptions: total number of subscriptions that may be active on a single websocket connection to this relay. It’s possible that authenticated clients with a (paid) relationship to the relay may have higher limits.

• max_filters: maximum number of filter values in each subscription. Must be one or higher.

• max_subid_length: maximum length of subscription id as a string.

• max_limit: the relay server will clamp each filter’s limit value to this number. This means the client won’t be able to get more than this number of events from a single subscription filter. This clamping is typically done silently by the relay, but with this number, you can know that there are additional results if you narrowed your filter’s time range or other parameters.

• max_event_tags: in any event, this is the maximum number of elements in the tags list.

• max_content_length: maximum number of characters in the content field of any event. This is a count of unicode characters. After serializing into JSON it may be larger (in bytes), and is still subject to the max_message_length, if defined.

• min_pow_difficulty: new events will require at least this difficulty of PoW, based on NIP-13 , or they will be rejected by this server.

• auth_required: this relay requires NIP-42 authentication to happen before a new connection may perform any other action. Even if set to False, authentication may be required for specific actions.

• payment_required: this relay requires payment before a new connection may perform any action.

• restricted_writes: this relay requires some kind of condition to be fulfilled in order to accept events (not necessarily, but including payment_required and min_pow_difficulty). This should only be set to true when users are expected to know the relay policy before trying to write to it – like belonging to a special pubkey-based whitelist or writing only events of a specific niche kind or content. Normal anti-spam heuristics, for example, do not qualify.

• created_at_lower_limit: ‘created_at’ lower limit

• created_at_upper_limit: ‘created_at’ upper limit

Event Retention

There may be a cost associated with storing data forever, so relays may wish to state retention times. The values stated here are defaults for unauthenticated users and visitors. Paid users would likely have other policies.

Retention times are given in seconds, with null indicating infinity. If zero is provided, this means the event will not be stored at all, and preferably an error will be provided when those are received.

{
  "retention": [
    {"kinds": [0, 1, [5, 7], [40, 49]], "time": 3600},
    {"kinds": [[40000, 49999]], "time": 100},
    {"kinds": [[30000, 39999]], "count": 1000},
    {"time": 3600, "count": 10000}
  ],
  // other fields...
}

retention is a list of specifications: each will apply to either all kinds, or a subset of kinds. Ranges may be specified for the kind field as a tuple of inclusive start and end values. Events of indicated kind (or all) are then limited to a count and/or time period.

It is possible to effectively blacklist Nostr-based protocols that rely on a specific kind number, by giving a retention time of zero for those kind values. While that is unfortunate, it does allow clients to discover servers that will support their protocol quickly via a single HTTP fetch.

There is no need to specify retention times for ephemeral events since they are not retained.

Content Limitations

Some relays may be governed by the arbitrary laws of a nation state. This may limit what content can be stored in clear-text on those relays. All clients are encouraged to use encryption to work around this limitation.

It is not possible to describe the limitations of each country’s laws and policies which themselves are typically vague and constantly shifting.

Therefore, this field allows the relay operator to indicate which countries’ laws might end up being enforced on them, and then indirectly on their users’ content.

Users should be able to avoid relays in countries they don’t like, and/or select relays in more favorable zones. Exposing this flexibility is up to the client software.

{
  "relay_countries": [ "CA", "US" ],
  // other fields...
}

• relay_countries: a list of two-level ISO country codes (ISO 3166-1 alpha-2) whose laws and policies may affect this relay. EU may be used for European Union countries.

Remember that a relay may be hosted in a country which is not the country of the legal entities who own the relay, so it’s very likely a number of countries are involved.

Community Preferences

For public text notes at least, a relay may try to foster a local community. This would encourage users to follow the global feed on that relay, in addition to their usual individual follows. To support this goal, relays MAY specify some of the following values.

{
  "language_tags": ["en", "en-419"],
  "tags": ["sfw-only", "bitcoin-only", "anime"],
  "posting_policy": "https://example.com/posting-policy.html",
  // other fields...
}

• language_tags is an ordered list of IETF language tags indicating the major languages spoken on the relay.

• tags is a list of limitations on the topics to be discussed. For example sfw-only indicates that only “Safe For Work” content is encouraged on this relay. This relies on assumptions of what the “work” “community” feels “safe” talking about. In time, a common set of tags may emerge that allow users to find relays that suit their needs, and client software will be able to parse these tags easily. The bitcoin-only tag indicates that any altcoin, “crypto” or blockchain comments will be ridiculed without mercy.

• posting_policy is a link to a human-readable page which specifies the community policies for the relay. In cases where sfw-only is True, it’s important to link to a page which gets into the specifics of your posting policy.

The description field should be used to describe your community goals and values, in brief. The posting_policy is for additional detail and legal terms. Use the tags field to signify limitations on content, or topics to be discussed, which could be machine processed by appropriate client software.

Pay-to-Relay

Relays that require payments may want to expose their fee schedules.

{
  "payments_url": "https://my-relay/payments",
  "fees": {
    "admission": [{ "amount": 1000000, "unit": "msats" }],
    "subscription": [{ "amount": 5000000, "unit": "msats", "period": 2592000 }],
    "publication": [{ "kinds": [4], "amount": 100, "unit": "msats" }],
  },
  ...
}

Examples

As of 2 May 2023 the following command provided these results:

$ curl -H "Accept: application/nostr+json" https://eden.nostr.land | jq

{
  "description": "nostr.land family of relays (us-or-01)",
  "name": "nostr.land",
  "pubkey": "52b4a076bcbbbdc3a1aefa3735816cf74993b1b8db202b01c883c58be7fad8bd",
  "software": "custom",
  "supported_nips": [
    1,
    2,
    4,
    9,
    11,
    12,
    16,
    20,
    22,
    28,
    33,
    40
  ],
  "version": "1.0.1",
  "limitation": {
    "payment_required": true,
    "max_message_length": 65535,
    "max_event_tags": 2000,
    "max_subscriptions": 20,
    "auth_required": false
  },
  "payments_url": "https://eden.nostr.land",
  "fees": {
    "subscription": [
      {
        "amount": 2500000,
        "unit": "msats",
        "period": 2592000
      }
    ]
  },
}

NIP-12

Generic Tag Queries

final mandatory

Moved to NIP-01 .

NIP-13

Proof of Work

draft optional

This NIP defines a way to generate and interpret Proof of Work for nostr notes. Proof of Work (PoW) is a way to add a proof of computational work to a note. This is a bearer proof that all relays and clients can universally validate with a small amount of code. This proof can be used as a means of spam deterrence.

difficulty is defined to be the number of leading zero bits in the NIP-01 id. For example, an id of 000000000e9d97a1ab09fc381030b346cdd7a142ad57e6df0b46dc9bef6c7e2d has a difficulty of 36 with 36 leading 0 bits.

002f... is 0000 0000 0010 1111... in binary, which has 10 leading zeroes. Do not forget to count leading zeroes for hex digits <= 7.

Mining

To generate PoW for a NIP-01 note, a nonce tag is used:

{"content": "It's just me mining my own business", "tags": [["nonce", "1", "21"]]}

When mining, the second entry to the nonce tag is updated, and then the id is recalculated (see NIP-01 ). If the id has the desired number of leading zero bits, the note has been mined. It is recommended to update the created_at as well during this process.

The third entry to the nonce tag SHOULD contain the target difficulty. This allows clients to protect against situations where bulk spammers targeting a lower difficulty get lucky and match a higher difficulty. For example, if you require 40 bits to reply to your thread and see a committed target of 30, you can safely reject it even if the note has 40 bits difficulty. Without a committed target difficulty you could not reject it. Committing to a target difficulty is something all honest miners should be ok with, and clients MAY reject a note matching a target difficulty if it is missing a difficulty commitment.

Example mined note

{
  "id": "000006d8c378af1779d2feebc7603a125d99eca0ccf1085959b307f64e5dd358",
  "pubkey": "a48380f4cfcc1ad5378294fcac36439770f9c878dd880ffa94bb74ea54a6f243",
  "created_at": 1651794653,
  "kind": 1,
  "tags": [
    ["nonce", "776797", "20"]
  ],
  "content": "It's just me mining my own business",
  "sig": "284622fc0a3f4f1303455d5175f7ba962a3300d136085b9566801bc2e0699de0c7e31e44c81fb40ad9049173742e904713c3594a1da0fc5d2382a25c11aba977"
}

Validating

Here is some reference C code for calculating the difficulty (aka number of leading zero bits) in a nostr event id:

int zero_bits(unsigned char b)
{
        int n = 0;

        if (b == 0)
                return 8;

        while (b >>= 1)
                n++;

        return 7-n;
}

/* find the number of leading zero bits in a hash */
int count_leading_zero_bits(unsigned char *hash)
{
        int bits, total, i;
        for (i = 0, total = 0; i < 32; i++) {
                bits = zero_bits(hash[i]);
                total += bits;
                if (bits != 8)
                        break;
        }
        return total;
}

Here is some JavaScript code for doing the same thing:

// hex should be a hexadecimal string (with no 0x prefix)
function countLeadingZeroes(hex) {
  let count = 0;

  for (let i = 0; i < hex.length; i++) {
    const nibble = parseInt(hex[i], 16);
    if (nibble === 0) {
      count += 4;
    } else {
      count += Math.clz32(nibble) - 28;
      break;
    }
  }

  return count;
}

Delegated Proof of Work

Since the NIP-01 note id does not commit to any signature, PoW can be outsourced to PoW providers, perhaps for a fee. This provides a way for clients to get their messages out to PoW-restricted relays without having to do any work themselves, which is useful for energy-constrained devices like mobile phones.

NIP-14

Subject tag in Text events

draft optional

This NIP defines the use of the “subject” tag in text (kind: 1) events. (implemented in more-speech)

["subject": <string>]

Browsers often display threaded lists of messages. The contents of the subject tag can be used in such lists, instead of the more ad hoc approach of using the first few words of the message. This is very similar to the way email browsers display lists of incoming emails by subject rather than by contents.

When replying to a message with a subject, clients SHOULD replicate the subject tag. Clients MAY adorn the subject to denote that it is a reply. e.g. by prepending “Re:”.

Subjects should generally be shorter than 80 chars. Long subjects will likely be trimmed by clients.

NIP-15

Nostr Marketplace

draft optional

Based on Diagon-Alley .

Implemented in NostrMarket and Plebeian Market .

Terms

• merchant - seller of products with NOSTR key-pair
• customer - buyer of products with NOSTR key-pair
• product - item for sale by the merchant
• stall - list of products controlled by merchant (a merchant can have multiple stalls)
• marketplace - clientside software for searching stalls and purchasing products

Nostr Marketplace Clients

Merchant admin

Where the merchant creates, updates and deletes stalls and products, as well as where they manage sales, payments and communication with customers.

The merchant admin software can be purely clientside, but for convenience and uptime, implementations will likely have a server client listening for NOSTR events.

Marketplace

Marketplace software should be entirely clientside, either as a stand-alone app, or as a purely frontend webpage. A customer subscribes to different merchant NOSTR public keys, and those merchants stalls and products become listed and searchable. The marketplace client is like any other ecommerce site, with basket and checkout. Marketplaces may also wish to include a customer support area for direct message communication with merchants.

Merchant publishing/updating products (event)

A merchant can publish these events:

Event 30017: Create or update a stall.

Event Content

{
  "id": <string, id generated by the merchant. Sequential IDs (`0`, `1`, `2`...) are discouraged>,
  "name": <string, stall name>,
  "description": <string (optional), stall description>,
  "currency": <string, currency used>,
  "shipping": [
    {
      "id": <string, id of the shipping zone, generated by the merchant>,
      "name": <string (optional), zone name>,
      "cost": <float, base cost for shipping. The currency is defined at the stall level>,
      "regions": [<string, regions included in this zone>]
    }
  ]
}

Fields that are not self-explanatory:

• shipping:
  • an array with possible shipping zones for this stall.
  • the customer MUST choose exactly one of those shipping zones.
  • shipping to different zones can have different costs. For some goods (digital for example) the cost can be zero.
  • the id is an internal value used by the merchant. This value must be sent back as the customer selection.
  • each shipping zone contains the base cost for orders made to that shipping zone, but a specific shipping cost per product can also be specified if the shipping cost for that product is higher than what’s specified by the base cost.

Event Tags

{
  "tags": [["d", <string, id of stall]],
  // other fields...
}

• the d tag is required, its value MUST be the same as the stall id.

Event 30018: Create or update a product

Event Content

{
  "id": <string, id generated by the merchant (sequential ids are discouraged)>,
  "stall_id": <string, id of the stall to which this product belong to>,
  "name": <string, product name>,
  "description": <string (optional), product description>,
  "images": <[string], array of image URLs, optional>,
  "currency": <string, currency used>,
  "price": <float, cost of product>,
  "quantity": <int or null, available items>,
  "specs": [
    [<string, spec key>, <string, spec value>]
  ],
  "shipping": [
    {
      "id": <string, id of the shipping zone (must match one of the zones defined for the stall)>,
      "cost": <float, extra cost for shipping. The currency is defined at the stall level>
    }
  ]
}

Fields that are not self-explanatory:

• quantity can be null in the case of items with unlimited availability, like digital items, or services

• specs:

  • an optional array of key pair values. It allows for the Customer UI to present product specifications in a structure mode. It also allows comparison between products
  • eg: [["operating_system", "Android 12.0"], ["screen_size", "6.4 inches"], ["connector_type", "USB Type C"]]

  Open: better to move spec in the tags section of the event?

• shipping:

  • an optional array of extra costs to be used per shipping zone, only for products that require special shipping costs to be added to the base shipping cost defined in the stall
  • the id should match the id of the shipping zone, as defined in the shipping field of the stall
  • to calculate the total cost of shipping for an order, the user will choose a shipping option during checkout, and then the client must consider this costs:
    • the base cost from the stall for the chosen shipping option
    • the result of multiplying the product units by the shipping costs specified in the product, if any.

Event Tags

  "tags": [
    ["d", <string, id of product],
    ["t", <string (optional), product category],
    ["t", <string (optional), product category],
    // other fields...
  ],
  ...

• the d tag is required, its value MUST be the same as the product id.
• the t tag is as searchable tag, it represents different categories that the product can be part of (food, fruits). Multiple t tags can be present.

Checkout events

All checkout events are sent as JSON strings using NIP-04 .

The merchant and the customer can exchange JSON messages that represent different actions. Each JSON message MUST have a type field indicating the what the JSON represents. Possible types:

Step 1: customer order (event)

The below JSON goes in content of NIP-04 .

{
  "id": <string, id generated by the customer>,
  "type": 0,
  "name": <string (optional), ???>,
  "address": <string (optional), for physical goods an address should be provided>,
  "message": <string (optional), message for merchant>,
  "contact": {
    "nostr": <32-bytes hex of a pubkey>,
    "phone": <string (optional), if the customer wants to be contacted by phone>,
    "email": <string (optional), if the customer wants to be contacted by email>
  },
  "items": [
    {
      "product_id": <string, id of the product>,
      "quantity": <int, how many products the customer is ordering>
    }
  ],
  "shipping_id": <string, id of the shipping zone>
}

Open: is contact.nostr required?

Step 2: merchant request payment (event)

Sent back from the merchant for payment. Any payment option is valid that the merchant can check.

The below JSON goes in content of NIP-04 .

payment_options/type include:

• url URL to a payment page, stripe, paypal, btcpayserver, etc
• btc onchain bitcoin address
• ln bitcoin lightning invoice
• lnurl bitcoin lnurl-pay

{
  "id": <string, id of the order>,
  "type": 1,
  "message": <string, message to customer, optional>,
  "payment_options": [
    {
      "type": <string, option type>,
      "link": <string, url, btc address, ln invoice, etc>
    },
    {
      "type": <string, option type>,
      "link": <string, url, btc address, ln invoice, etc>
    },
    {
      "type": <string, option type>,
      "link": <string, url, btc address, ln invoice, etc>
    }
  ]
}

Step 3: merchant verify payment/shipped (event)

Once payment has been received and processed.

The below JSON goes in content of NIP-04 .

{
  "id": <string, id of the order>,
  "type": 2,
  "message": <string, message to customer>,
  "paid": <bool: has received payment>,
  "shipped": <bool: has been shipped>,
}

Customize Marketplace

Create a customized user experience using the naddr from NIP-19 . The use of naddr enables easy sharing of marketplace events while incorporating a rich set of metadata. This metadata can include relays, merchant profiles, and more. Subsequently, it allows merchants to be grouped into a market, empowering the market creator to configure the marketplace’s user interface and user experience, and share that marketplace. This customization can encompass elements such as market name, description, logo, banner, themes, and even color schemes, offering a tailored and unique marketplace experience.

Event 30019: Create or update marketplace UI/UX

Event Content

{
  "name": <string (optional), market name>,
  "about": <string (optional), market description>,
  "ui": {
    "picture": <string (optional), market logo image URL>,
    "banner": <string (optional), market logo banner URL>,
    "theme": <string (optional), market theme>,
    "darkMode": <bool, true/false>
  },
  "merchants": [array of pubkeys (optional)],
  // other fields...
}

This event leverages naddr to enable comprehensive customization and sharing of marketplace configurations, fostering a unique and engaging marketplace environment.

Auctions

Event 30020: Create or update a product sold as an auction

Event Content:

{
    "id": <String, UUID generated by the merchant. Sequential IDs (`0`, `1`, `2`...) are discouraged>,
    "stall_id": <String, UUID of the stall to which this product belong to>,
    "name": <String, product name>,
    "description": <String (optional), product description>,
    "images": <[String], array of image URLs, optional>,
    "starting_bid": <int>,
    "start_date": <int (optional) UNIX timestamp, date the auction started / will start>,
    "duration": <int, number of seconds the auction will run for, excluding eventual time extensions that might happen>,
    "specs": [
        [<String, spec key>, <String, spec value>]
    ],
    "shipping": [
        {
            "id": <String, UUID of the shipping zone. Must match one of the zones defined for the stall>,
            "cost": <float, extra cost for shipping. The currency is defined at the stall level>
        }
    ]
}

[!NOTE] Items sold as an auction are very similar in structure to fixed-price items, with some important differences worth noting.

• The start_date can be set to a date in the future if the auction is scheduled to start on that date, or can be omitted if the start date is unknown/hidden. If the start date is not specified, the auction will have to be edited later to set an actual date.

• The auction runs for an initial number of seconds after the start_date, specified by duration.

Event 1021: Bid

{
    "content": <int, amount of sats>,
    "tags": [["e", <event ID of the auction to bid on>]],
    // other fields...
}

Bids are simply events of kind 1021 with a content field specifying the amount, in the currency of the auction. Bids must reference an auction.

[!NOTE] Auctions can be edited as many times as desired (they are “addressable events”) by the author - even after the start_date, but they cannot be edited after they have received the first bid! This is enforced by the fact that bids reference the event ID of the auction (rather than the product UUID), which changes with every new version of the auctioned product. So a bid is always attached to one “version”. Editing the auction after a bid would result in the new product losing the bid!

Event 1022: Bid confirmation

Event Content:

{
    "status": <String, "accepted" | "rejected" | "pending" | "winner">,
    "message": <String (optional)>,
    "duration_extended": <int (optional), number of seconds>
}

Event Tags:

  "tags": [["e" <event ID of the bid being confirmed>], ["e", <event ID of the auction>]],

Bids should be confirmed by the merchant before being considered as valid by other clients. So clients should subscribe to bid confirmation events (kind 1022) for every auction that they follow, in addition to the actual bids and should check that the pubkey of the bid confirmation matches the pubkey of the merchant (in addition to checking the signature).

The content field is a JSON which includes at least a status. winner is how the winning bid is replied to after the auction ends and the winning bid is picked by the merchant.

The reasons for which a bid can be marked as rejected or pending are up to the merchant’s implementation and configuration - they could be anything from basic validation errors (amount too low) to the bidder being blacklisted or to the bidder lacking sufficient trust, which could lead to the bid being marked as pending until sufficient verification is performed. The difference between the two is that pending bids might get approved after additional steps are taken by the bidder, whereas rejected bids can not be later approved.

An additional message field can appear in the content JSON to give further context as of why a bid is rejected or pending.

Another thing that can happen is - if bids happen very close to the end date of the auction - for the merchant to decide to extend the auction duration for a few more minutes. This is done by passing a duration_extended field as part of a bid confirmation, which would contain a number of seconds by which the initial duration is extended. So the actual end date of an auction is always start_date + duration + (SUM(c.duration_extended) FOR c in all confirmations.

Customer support events

Customer support is handled over whatever communication method was specified. If communicating via nostr, NIP-04 is used.

Additional

Standard data models can be found here

NIP-16

Event Treatment

final mandatory

Moved to NIP-01 .

NIP-17

Private Direct Messages

draft optional

This NIP defines an encrypted direct messaging scheme using NIP-44 encryption and NIP-59 seals and gift wraps.

Direct Message Kind

Kind 14 is a chat message. p tags identify one or more receivers of the message.

{
  "id": "<usual hash>",
  "pubkey": "<sender-pubkey>",
  "created_at": "<current-time>",
  "kind": 14,
  "tags": [
    ["p", "<receiver-1-pubkey>", "<relay-url>"],
    ["p", "<receiver-2-pubkey>", "<relay-url>"],
    ["e", "<kind-14-id>", "<relay-url>", "reply"] // if this is a reply
    ["subject", "<conversation-title>"],
    // rest of tags...
  ],
  "content": "<message-in-plain-text>",
}

.content MUST be plain text. Fields id and created_at are required.

Tags that mention, quote and assemble threading structures MUST follow NIP-10 .

Kind 14s MUST never be signed. If it is signed, the message might leak to relays and become fully public.

Chat Rooms

The set of pubkey + p tags defines a chat room. If a new p tag is added or a current one is removed, a new room is created with clean message history.

Clients SHOULD render messages of the same room in a continuous thread.

An optional subject tag defines the current name/topic of the conversation. Any member can change the topic by simply submitting a new subject to an existing pubkey + p-tags room. There is no need to send subject in every message. The newest subject in the thread is the subject of the conversation.

Encrypting

Following NIP-59 , the unsigned kind:14 chat message must be sealed (kind:13) and then gift-wrapped (kind:1059) to each receiver and the sender individually.

{
  "id": "<usual hash>",
  "pubkey": randomPublicKey,
  "created_at": randomTimeUpTo2DaysInThePast(),
  "kind": 1059, // gift wrap
  "tags": [
    ["p", receiverPublicKey, "<relay-url>"] // receiver
  ],
  "content": nip44Encrypt(
    {
      "id": "<usual hash>",
      "pubkey": senderPublicKey,
      "created_at": randomTimeUpTo2DaysInThePast(),
      "kind": 13, // seal
      "tags": [], // no tags
      "content": nip44Encrypt(unsignedKind14, senderPrivateKey, receiverPublicKey),
      "sig": "<signed by senderPrivateKey>"
    },
    randomPrivateKey, receiverPublicKey
  ),
  "sig": "<signed by randomPrivateKey>"
}

The encryption algorithm MUST use the latest version of NIP-44 .

Clients MUST verify if pubkey of the kind:13 is the same pubkey on the kind:14, otherwise any sender can impersonate others by simply changing the pubkey on kind:14.

Clients SHOULD randomize created_at in up to two days in the past in both the seal and the gift wrap to make sure grouping by created_at doesn’t reveal any metadata.

The gift wrap’s p-tag can be the receiver’s main pubkey or an alias key created to receive DMs without exposing the receiver’s identity.

Clients CAN offer disappearing messages by setting an expiration tag in the gift wrap of each receiver or by not generating a gift wrap to the sender’s public key

Publishing

Kind 10050 indicates the user’s preferred relays to receive DMs. The event MUST include a list of relay tags with relay URIs.

{
  "kind": 10050,
  "tags": [
    ["relay", "wss://inbox.nostr.wine"],
    ["relay", "wss://myrelay.nostr1.com"],
  ],
  "content": "",
  // other fields...
}

Clients SHOULD publish kind 14 events to the 10050-listed relays. If that is not found that indicates the user is not ready to receive messages under this NIP and clients shouldn’t try.

Relays

It’s advisable that relays do not serve kind:1059 to clients other than the ones tagged in them.

It’s advisable that users choose relays that conform to these practices.

Clients SHOULD guide users to keep kind:10050 lists small (1-3 relays) and SHOULD spread it to as many relays as viable.

Benefits & Limitations

This NIP offers the following privacy and security features:

1. No Metadata Leak: Participant identities, each message’s real date and time, event kinds, and other event tags are all hidden from the public. Senders and receivers cannot be linked with public information alone.
2. No Public Group Identifiers: There is no public central queue, channel or otherwise converging identifier to correlate or count all messages in the same group.
3. No Moderation: There are no group admins: no invitations or bans.
4. No Shared Secrets: No secret must be known to all members that can leak or be mistakenly shared
5. Fully Recoverable: Messages can be fully recoverable by any client with the user’s private key
6. Optional Forward Secrecy: Users and clients can opt-in for “disappearing messages”.
7. Uses Public Relays: Messages can flow through public relays without loss of privacy. Private relays can increase privacy further, but they are not required.
8. Cold Storage: Users can unilaterally opt-in to sharing their messages with a separate key that is exclusive for DM backup and recovery.

The main limitation of this approach is having to send a separate encrypted event to each receiver. Group chats with more than 100 participants should find a more suitable messaging scheme.

Implementation

Clients implementing this NIP should by default only connect to the set of relays found in their kind:10050 list. From that they should be able to load all messages both sent and received as well as get new live updates, making it for a very simple and lightweight implementation that should be fast.

When sending a message to anyone, clients must then connect to the relays in the receiver’s kind:10050 and send the events there, but can disconnect right after unless more messages are expected to be sent (e.g. the chat tab is still selected). Clients should also send a copy of their outgoing messages to their own kind:10050 relay set.

Examples

This example sends the message Hola, que tal? from nsec1w8udu59ydjvedgs3yv5qccshcj8k05fh3l60k9x57asjrqdpa00qkmr89m to nsec12ywtkplvyq5t6twdqwwygavp5lm4fhuang89c943nf2z92eez43szvn4dt.

The two final GiftWraps, one to the receiver and the other to the sender, are:

{
   "id":"2886780f7349afc1344047524540ee716f7bdc1b64191699855662330bf235d8",
   "pubkey":"8f8a7ec43b77d25799281207e1a47f7a654755055788f7482653f9c9661c6d51",
   "created_at":1703128320,
   "kind":1059,
   "tags":[
      [ "p", "918e2da906df4ccd12c8ac672d8335add131a4cf9d27ce42b3bb3625755f0788"]
   ],
   "content":"AsqzdlMsG304G8h08bE67dhAR1gFTzTckUUyuvndZ8LrGCvwI4pgC3d6hyAK0Wo9gtkLqSr2rT2RyHlE5wRqbCOlQ8WvJEKwqwIJwT5PO3l2RxvGCHDbd1b1o40ZgIVwwLCfOWJ86I5upXe8K5AgpxYTOM1BD+SbgI5jOMA8tgpRoitJedVSvBZsmwAxXM7o7sbOON4MXHzOqOZpALpS2zgBDXSAaYAsTdEM4qqFeik+zTk3+L6NYuftGidqVluicwSGS2viYWr5OiJ1zrj1ERhYSGLpQnPKrqDaDi7R1KrHGFGyLgkJveY/45y0rv9aVIw9IWF11u53cf2CP7akACel2WvZdl1htEwFu/v9cFXD06fNVZjfx3OssKM/uHPE9XvZttQboAvP5UoK6lv9o3d+0GM4/3zP+yO3C0NExz1ZgFmbGFz703YJzM+zpKCOXaZyzPjADXp8qBBeVc5lmJqiCL4solZpxA1865yPigPAZcc9acSUlg23J1dptFK4n3Tl5HfSHP+oZ/QS/SHWbVFCtq7ZMQSRxLgEitfglTNz9P1CnpMwmW/Y4Gm5zdkv0JrdUVrn2UO9ARdHlPsW5ARgDmzaxnJypkfoHXNfxGGXWRk0sKLbz/ipnaQP/eFJv/ibNuSfqL6E4BnN/tHJSHYEaTQ/PdrA2i9laG3vJti3kAl5Ih87ct0w/tzYfp4SRPhEF1zzue9G/16eJEMzwmhQ5Ec7jJVcVGa4RltqnuF8unUu3iSRTQ+/MNNUkK6Mk+YuaJJs6Fjw6tRHuWi57SdKKv7GGkr0zlBUU2Dyo1MwpAqzsCcCTeQSv+8qt4wLf4uhU9Br7F/L0ZY9bFgh6iLDCdB+4iABXyZwT7Ufn762195hrSHcU4Okt0Zns9EeiBOFxnmpXEslYkYBpXw70GmymQfJlFOfoEp93QKCMS2DAEVeI51dJV1e+6t3pCSsQN69Vg6jUCsm1TMxSs2VX4BRbq562+VffchvW2BB4gMjsvHVUSRl8i5/ZSDlfzSPXcSGALLHBRzy+gn0oXXJ/447VHYZJDL3Ig8+QW5oFMgnWYhuwI5QSLEyflUrfSz+Pdwn/5eyjybXKJftePBD9Q+8NQ8zulU5sqvsMeIx/bBUx0fmOXsS3vjqCXW5IjkmSUV7q54GewZqTQBlcx+90xh/LSUxXex7UwZwRnifvyCbZ+zwNTHNb12chYeNjMV7kAIr3cGQv8vlOMM8ajyaZ5KVy7HpSXQjz4PGT2/nXbL5jKt8Lx0erGXsSsazkdoYDG3U",
   "sig":"a3c6ce632b145c0869423c1afaff4a6d764a9b64dedaf15f170b944ead67227518a72e455567ca1c2a0d187832cecbde7ed478395ec4c95dd3e71749ed66c480"
}

{
   "id":"162b0611a1911cfcb30f8a5502792b346e535a45658b3a31ae5c178465509721",
   "pubkey":"626be2af274b29ea4816ad672ee452b7cf96bbb4836815a55699ae402183f512",
   "created_at":1702711587,
   "kind":1059,
   "tags":[
      [ "p", "44900586091b284416a0c001f677f9c49f7639a55c3f1e2ec130a8e1a7998e1b"]
   ],
   "content":"AsTClTzr0gzXXji7uye5UB6LYrx3HDjWGdkNaBS6BAX9CpHa+Vvtt5oI2xJrmWLen+Fo2NBOFazvl285Gb3HSM82gVycrzx1HUAaQDUG6HI7XBEGqBhQMUNwNMiN2dnilBMFC3Yc8ehCJT/gkbiNKOpwd2rFibMFRMDKai2mq2lBtPJF18oszKOjA+XlOJV8JRbmcAanTbEK5nA/GnG3eGUiUzhiYBoHomj3vztYYxc0QYHOx0WxiHY8dsC6jPsXC7f6k4P+Hv5ZiyTfzvjkSJOckel1lZuE5SfeZ0nduqTlxREGeBJ8amOykgEIKdH2VZBZB+qtOMc7ez9dz4wffGwBDA7912NFS2dPBr6txHNxBUkDZKFbuD5wijvonZDvfWq43tZspO4NutSokZB99uEiRH8NAUdGTiNb25m9JcDhVfdmABqTg5fIwwTwlem5aXIy8b66lmqqz2LBzJtnJDu36bDwkILph3kmvaKPD8qJXmPQ4yGpxIbYSTCohgt2/I0TKJNmqNvSN+IVoUuC7ZOfUV9lOV8Ri0AMfSr2YsdZ9ofV5o82ClZWlWiSWZwy6ypa7CuT1PEGHzywB4CZ5ucpO60Z7hnBQxHLiAQIO/QhiBp1rmrdQZFN6PUEjFDloykoeHe345Yqy9Ke95HIKUCS9yJurD+nZjjgOxZjoFCsB1hQAwINTIS3FbYOibZnQwv8PXvcSOqVZxC9U0+WuagK7IwxzhGZY3vLRrX01oujiRrevB4xbW7Oxi/Agp7CQGlJXCgmRE8Rhm+Vj2s+wc/4VLNZRHDcwtfejogjrjdi8p6nfUyqoQRRPARzRGUnnCbh+LqhigT6gQf3sVilnydMRScEc0/YYNLWnaw9nbyBa7wFBAiGbJwO40k39wj+xT6HTSbSUgFZzopxroO3f/o4+ubx2+IL3fkev22mEN38+dFmYF3zE+hpE7jVxrJpC3EP9PLoFgFPKCuctMnjXmeHoiGs756N5r1Mm1ffZu4H19MSuALJlxQR7VXE/LzxRXDuaB2u9days/6muP6gbGX1ASxbJd/ou8+viHmSC/ioHzNjItVCPaJjDyc6bv+gs1NPCt0qZ69G+JmgHW/PsMMeL4n5bh74g0fJSHqiI9ewEmOG/8bedSREv2XXtKV39STxPweceIOh0k23s3N6+wvuSUAJE7u1LkDo14cobtZ/MCw/QhimYPd1u5HnEJvRhPxz0nVPz0QqL/YQeOkAYk7uzgeb2yPzJ6DBtnTnGDkglekhVzQBFRJdk740LEj6swkJ",
   "sig":"c94e74533b482aa8eeeb54ae72a5303e0b21f62909ca43c8ef06b0357412d6f8a92f96e1a205102753777fd25321a58fba3fb384eee114bd53ce6c06a1c22bab"
}

NIP-18

Reposts

draft optional

A repost is a kind 6 event that is used to signal to followers that a kind 1 text note is worth reading.

The content of a repost event is the stringified JSON of the reposted note. It MAY also be empty, but that is not recommended.

The repost event MUST include an e tag with the id of the note that is being reposted. That tag MUST include a relay URL as its third entry to indicate where it can be fetched.

The repost SHOULD include a p tag with the pubkey of the event being reposted.

Quote Reposts

Quote reposts are kind 1 events with an embedded q tag of the note being quote reposted. The q tag ensures quote reposts are not pulled and included as replies in threads. It also allows you to easily pull and count all of the quotes for a post.

q tags should follow the same conventions as NIP 10 e tags, with the exception of the mark argument.

["q", <event-id>, <relay-url>, <pubkey>]

Quote reposts MUST include the NIP-21 nevent, note, or naddr of the event in the content.

Generic Reposts

Since kind 6 reposts are reserved for kind 1 contents, we use kind 16 as a “generic repost”, that can include any kind of event inside other than kind 1.

kind 16 reposts SHOULD contain a k tag with the stringified kind number of the reposted event as its value.

NIP-19

bech32-encoded entities

draft optional

This NIP standardizes bech32-formatted strings that can be used to display keys, ids and other information in clients. These formats are not meant to be used anywhere in the core protocol, they are only meant for displaying to users, copy-pasting, sharing, rendering QR codes and inputting data.

It is recommended that ids and keys are stored in either hex or binary format, since these formats are closer to what must actually be used the core protocol.

Bare keys and ids

To prevent confusion and mixing between private keys, public keys and event ids, which are all 32 byte strings. bech32-(not-m) encoding with different prefixes can be used for each of these entities.

These are the possible bech32 prefixes:

• npub: public keys
• nsec: private keys
• note: note ids

Example: the hex public key 3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d translates to npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6.

The bech32 encodings of keys and ids are not meant to be used inside the standard NIP-01 event formats or inside the filters, they’re meant for human-friendlier display and input only. Clients should still accept keys in both hex and npub format for now, and convert internally.

Shareable identifiers with extra metadata

When sharing a profile or an event, an app may decide to include relay information and other metadata such that other apps can locate and display these entities more easily.

For these events, the contents are a binary-encoded list of TLV (type-length-value), with T and L being 1 byte each (uint8, i.e. a number in the range of 0-255), and V being a sequence of bytes of the size indicated by L.

These are the possible bech32 prefixes with TLV:

• nprofile: a nostr profile
• nevent: a nostr event
• naddr: a nostr replaceable event coordinate
• nrelay: a nostr relay (deprecated)

These possible standardized TLV types are indicated here:

• 0: special
  • depends on the bech32 prefix:
    • for nprofile it will be the 32 bytes of the profile public key
    • for nevent it will be the 32 bytes of the event id
    • for naddr, it is the identifier (the "d" tag) of the event being referenced. For normal replaceable events use an empty string.
• 1: relay
  • for nprofile, nevent and naddr, optionally, a relay in which the entity (profile or event) is more likely to be found, encoded as ascii
  • this may be included multiple times
• 2: author
  • for naddr, the 32 bytes of the pubkey of the event
  • for nevent, optionally, the 32 bytes of the pubkey of the event
• 3: kind
  • for naddr, the 32-bit unsigned integer of the kind, big-endian
  • for nevent, optionally, the 32-bit unsigned integer of the kind, big-endian

Examples

• npub10elfcs4fr0l0r8af98jlmgdh9c8tcxjvz9qkw038js35mp4dma8qzvjptg should decode into the public key hex 7e7e9c42a91bfef19fa929e5fda1b72e0ebc1a4c1141673e2794234d86addf4e and vice-versa
• nsec1vl029mgpspedva04g90vltkh6fvh240zqtv9k0t9af8935ke9laqsnlfe5 should decode into the private key hex 67dea2ed018072d675f5415ecfaed7d2597555e202d85b3d65ea4e58d2d92ffa and vice-versa
• nprofile1qqsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8gpp4mhxue69uhhytnc9e3k7mgpz4mhxue69uhkg6nzv9ejuumpv34kytnrdaksjlyr9p should decode into a profile with the following TLV items:
  • pubkey: 3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d
  • relay: wss://r.x.com
  • relay: wss://djbas.sadkb.com

Notes

• npub keys MUST NOT be used in NIP-01 events or in NIP-05 JSON responses, only the hex format is supported there.
• When decoding a bech32-formatted string, TLVs that are not recognized or supported should be ignored, rather than causing an error.

NIP-20

Command Results

final mandatory

Moved to NIP-01 .

NIP-21

nostr: URI scheme

draft optional

This NIP standardizes the usage of a common URI scheme for maximum interoperability and openness in the network.

The scheme is nostr:.

The identifiers that come after are expected to be the same as those defined in NIP-19 (except nsec).

Examples

• nostr:npub1sn0wdenkukak0d9dfczzeacvhkrgz92ak56egt7vdgzn8pv2wfqqhrjdv9
• nostr:nprofile1qqsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8gpp4mhxue69uhhytnc9e3k7mgpz4mhxue69uhkg6nzv9ejuumpv34kytnrdaksjlyr9p
• nostr:note1fntxtkcy9pjwucqwa9mddn7v03wwwsu9j330jj350nvhpky2tuaspk6nqc
• nostr:nevent1qqstna2yrezu5wghjvswqqculvvwxsrcvu7uc0f78gan4xqhvz49d9spr3mhxue69uhkummnw3ez6un9d3shjtn4de6x2argwghx6egpr4mhxue69uhkummnw3ez6ur4vgh8wetvd3hhyer9wghxuet5nxnepm

NIP-22

Comment

draft optional

A comment is a threading note always scoped to a root event or an I-tag.

It uses kind:1111 with plaintext .content (no HTML, Markdown, or other formatting).

Comments MUST point to the root scope using uppercase tag names (e.g. K, E, A or I) and MUST point to the parent item with lowercase ones (e.g. k, e, a or i).

{
  kind: 1111,
  content: '<comment>',
  tags: [
    // root scope: event addresses, event ids, or I-tags.
    ["<A, E, I>", "<address, id or I-value>", "<relay or web page hint>", "<root event's pubkey, if an E tag>"],
    // the root item kind
    ["K", "<root kind>"],

    // parent item: event addresses, event ids, or i-tags.
    ["<a, e, i>", "<address, id or i-value>", "<relay or web page hint>", "<parent event's pubkey, if an e tag>"],
    // parent item kind
    ["k", "<parent comment kind>"]
  ]
  // other fields
}

Tags K and k MUST be present to define the event kind of the root and the parent items.

I and i tags create scopes for hashtags, geohashes, URLs, and other external identifiers.

The possible values for i tags – and k tags, when related to an extenal identity – are listed on NIP-73 . Their uppercase versions use the same type of values but relate to the root item instead of the parent one.

q tags MAY be used when citing events in the .content with NIP-21 .

["q", "<event-id> or <event-address>", "<relay-url>", "<pubkey-if-a-regular-event>"]

p tags SHOULD be used when mentioning pubkeys in the .content with NIP-21 . If the parent item is an event, a p tag set to the parent event’s author SHOULD be added.

["p", "<pubkey>", "<relay-url>"]

Examples

A comment on a blog post looks like this:

{
  kind: 1111,
  content: 'Great blog post!',
  tags: [
    // top-level comments scope to event addresses or ids
    ["A", "30023:3c9849383bdea883b0bd16fece1ed36d37e37cdde3ce43b17ea4e9192ec11289:f9347ca7", "wss://example.relay"],
    // the root kind
    ["K", "30023"],

    // the parent event address (same as root for top-level comments)
    ["a", "30023:3c9849383bdea883b0bd16fece1ed36d37e37cdde3ce43b17ea4e9192ec11289:f9347ca7", "wss://example.relay"],
    // when the parent event is replaceable or addressable, also include an `e` tag referencing its id
    ["e", "5b4fc7fed15672fefe65d2426f67197b71ccc82aa0cc8a9e94f683eb78e07651", "wss://example.relay"],
    // the parent event kind
    ["k", "30023"]
  ]
  // other fields
}

A comment on a NIP-94 file looks like this:

{
  kind: 1111,
  content: 'Great file!',
  tags: [
    // top-level comments have the same scope and reply to addresses or ids
    ["E", "768ac8720cdeb59227cf95e98b66560ef03d8bc9a90d721779e76e68fb42f5e6", "wss://example.relay", "3721e07b079525289877c366ccab47112bdff3d1b44758ca333feb2dbbbbe5bb"],
    // the root kind
    ["K", "1063"],

    // the parent event id (same as root for top-level comments)
    ["e", "768ac8720cdeb59227cf95e98b66560ef03d8bc9a90d721779e76e68fb42f5e6", "wss://example.relay", "3721e07b079525289877c366ccab47112bdff3d1b44758ca333feb2dbbbbe5bb"],
    // the parent kind
    ["k", "1063"]
  ]
  // other fields
}

A reply to a comment looks like this:

{
  kind: 1111,
  content: 'This is a reply to "Great file!"',
  tags: [
    // nip-94 file event id
    ["E", "768ac8720cdeb59227cf95e98b66560ef03d8bc9a90d721779e76e68fb42f5e6", "wss://example.relay", "fd913cd6fa9edb8405750cd02a8bbe16e158b8676c0e69fdc27436cc4a54cc9a"],
    // the root kind
    ["K", "1063"],

    // the parent event
    ["e", "5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36", "wss://example.relay", "93ef2ebaaf9554661f33e79949007900bbc535d239a4c801c33a4d67d3e7f546"],
    // the parent kind
    ["k", "1111"]
  ]
  // other fields
}

A comment on a website’s url looks like this:

{
  kind: 1111,
  content: 'Nice article!',
  tags: [
    // referencing the root url
    ["I", "https://abc.com/articles/1"],
    // the root "kind": for an url, the kind is its domain
    ["K", "https://abc.com"],

    // the parent reference (same as root for top-level comments)
    ["i", "https://abc.com/articles/1"],
    // the parent "kind": for an url, the kind is its domain
    ["k", "https://abc.com"]
  ]
  // other fields
}

A podcast comment example:

{
  id: "80c48d992a38f9c445b943a9c9f1010b396676013443765750431a9004bdac05",
  pubkey: "252f10c83610ebca1a059c0bae8255eba2f95be4d1d7bcfa89d7248a82d9f111",
  kind: 1111,
  content: "This was a great episode!",
  tags: [
    // podcast episode reference
    ["I", "podcast:item:guid:d98d189b-dc7b-45b1-8720-d4b98690f31f", "https://fountain.fm/episode/z1y9TMQRuqXl2awyrQxg"],
    // podcast episode type
    ["K", "podcast:item:guid"],

    // same value as "I" tag above, because it is a top-level comment (not a reply to a comment)
    ["i", "podcast:item:guid:d98d189b-dc7b-45b1-8720-d4b98690f31f", "https://fountain.fm/episode/z1y9TMQRuqXl2awyrQxg"],
    ["k", "podcast:item:guid"]
  ]
  // other fields
}

A reply to a podcast comment:

{
  kind: 1111,
  content: "I'm replying to the above comment.",
  tags: [
    // podcast episode reference
    ["I", "podcast:item:guid:d98d189b-dc7b-45b1-8720-d4b98690f31f", "https://fountain.fm/episode/z1y9TMQRuqXl2awyrQxg"],
    // podcast episode type
    ["K", "podcast:item:guid"],

    // this is a reference to the above comment
    ["e", "80c48d992a38f9c445b943a9c9f1010b396676013443765750431a9004bdac05", "wss://example.relay", "252f10c83610ebca1a059c0bae8255eba2f95be4d1d7bcfa89d7248a82d9f111"],
    // the parent comment kind
    ["k", "1111"]
  ]
  // other fields
}

NIP-23

Long-form Content

draft optional

This NIP defines kind:30023 (an addressable event) for long-form text content, generally referred to as “articles” or “blog posts”. kind:30024 has the same structure as kind:30023 and is used to save long form drafts.

“Social” clients that deal primarily with kind:1 notes should not be expected to implement this NIP.

Format

The .content of these events should be a string text in Markdown syntax. To maximize compatibility and readability between different clients and devices, any client that is creating long form notes:

• MUST NOT hard line-break paragraphs of text, such as arbitrary line breaks at 80 column boundaries.

• MUST NOT support adding HTML to Markdown.

Metadata

For the date of the last update the .created_at field should be used, for “tags”/“hashtags” (i.e. topics about which the event might be of relevance) the t tag should be used.

Other metadata fields can be added as tags to the event as necessary. Here we standardize 4 that may be useful, although they remain strictly optional:

• "title", for the article title
• "image", for a URL pointing to an image to be shown along with the title
• "summary", for the article summary
• "published_at", for the timestamp in unix seconds (stringified) of the first time the article was published

Editability

These articles are meant to be editable, so they should include a d tag with an identifier for the article. Clients should take care to only publish and read these events from relays that implement that. If they don’t do that they should also take care to hide old versions of the same article they may receive.

Linking

The article may be linked to using the NIP-19 naddr code along with the a tag.

References

References to other Nostr notes, articles or profiles must be made according to NIP-27 , i.e. by using NIP-21 nostr:... links and optionally adding tags for these (see example below).

Example Event

{
  "kind": 30023,
  "created_at": 1675642635,
  "content": "Lorem [ipsum][nostr:nevent1qqst8cujky046negxgwwm5ynqwn53t8aqjr6afd8g59nfqwxpdhylpcpzamhxue69uhhyetvv9ujuetcv9khqmr99e3k7mg8arnc9] dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.\n\nRead more at nostr:naddr1qqzkjurnw4ksz9thwden5te0wfjkccte9ehx7um5wghx7un8qgs2d90kkcq3nk2jry62dyf50k0h36rhpdtd594my40w9pkal876jxgrqsqqqa28pccpzu.",
  "tags": [
    ["d", "lorem-ipsum"],
    ["title", "Lorem Ipsum"],
    ["published_at", "1296962229"],
    ["t", "placeholder"],
    ["e", "b3e392b11f5d4f28321cedd09303a748acfd0487aea5a7450b3481c60b6e4f87", "wss://relay.example.com"],
    ["a", "30023:a695f6b60119d9521934a691347d9f78e8770b56da16bb255ee286ddf9fda919:ipsum", "wss://relay.nostr.org"]
  ],
  "pubkey": "...",
  "id": "..."
}

NIP-24

Extra metadata fields and tags

draft optional

This NIP defines extra optional fields added to events.

kind 0

These are extra fields not specified in NIP-01 that may be present in the stringified JSON of metadata events:

• display_name: an alternative, bigger name with richer characters than name. name should always be set regardless of the presence of display_name in the metadata.
• website: a web URL related in any way to the event author.
• banner: an URL to a wide (~1024x768) picture to be optionally displayed in the background of a profile screen.
• bot: a boolean to clarify that the content is entirely or partially the result of automation, such as with chatbots or newsfeeds.

Deprecated fields

These are fields that should be ignored or removed when found in the wild:

• displayName: use display_name instead.
• username: use name instead.

kind 3

These are extra fields not specified in NIP-02 that may be present in the stringified JSON of follow events:

Deprecated fields

• {<relay-url>: {"read": <true|false>, "write": <true|false>}, ...}: an object of relays used by a user to read/write. NIP-65 should be used instead.

tags

These tags may be present in multiple event kinds. Whenever a different meaning is not specified by some more specific NIP, they have the following meanings:

• r: a web URL the event is referring to in some way.
• i: an external id the event is referring to in some way - see NIP-73 .
• title: name of NIP-51 sets, NIP-52 calendar event, NIP-53 live event or NIP-99 listing.
• t: a hashtag. The value MUST be a lowercase string.

NIP-25

Reactions

draft optional

A reaction is a kind 7 event that is used to react to other events.

The generic reaction, represented by the content set to a + string, SHOULD be interpreted as a “like” or “upvote”.

A reaction with content set to - SHOULD be interpreted as a “dislike” or “downvote”. It SHOULD NOT be counted as a “like”, and MAY be displayed as a downvote or dislike on a post. A client MAY also choose to tally likes against dislikes in a reddit-like system of upvotes and downvotes, or display them as separate tallies.

The content MAY be an emoji, or NIP-30 custom emoji in this case it MAY be interpreted as a “like” or “dislike”, or the client MAY display this emoji reaction on the post. If the content is an empty string then the client should consider it a “+”.

Tags

The reaction event SHOULD include e and p tags from the note the user is reacting to (and optionally a tags if the target is a replaceable event). This allows users to be notified of reactions to posts they were mentioned in. Including the e tags enables clients to pull all the reactions associated with individual posts or all the posts in a thread. a tags enables clients to seek reactions for all versions of a replaceable event.

The last e tag MUST be the id of the note that is being reacted to.

The last p tag MUST be the pubkey of the event being reacted to.

The a tag MUST contain the coordinates (kind:pubkey:d-tag) of the replaceable being reacted to.

The reaction event MAY include a k tag with the stringified kind number of the reacted event as its value.

Example code

func make_like_event(pubkey: String, privkey: String, liked: NostrEvent) -> NostrEvent {
    var tags: [[String]] = liked.tags.filter {
    	tag in tag.count >= 2 && (tag[0] == "e" || tag[0] == "p")
    }
    tags.append(["e", liked.id])
    tags.append(["p", liked.pubkey])
    tags.append(["k", liked.kind])
    let ev = NostrEvent(content: "+", pubkey: pubkey, kind: 7, tags: tags)
    ev.calculate_id()
    ev.sign(privkey: privkey)
    return ev
}

Reactions to a website

If the target of the reaction is a website, the reaction MUST be a kind 17 event and MUST include an r tag with the website’s URL.

{
  "kind": 17,
  "content": "⭐",
  "tags": [
    ["r", "https://example.com/"]
  ],
  // other fields...
}

URLs SHOULD be normalized , so that reactions to the same website are not omitted from queries. A fragment MAY be attached to the URL, to react to a section of the page. It should be noted that a URL with a fragment is not considered to be the same URL as the original.

Custom Emoji Reaction

The client may specify a custom emoji (NIP-30 ) :shortcode: in the reaction content. The client should refer to the emoji tag and render the content as an emoji if shortcode is specified.

{
  "kind": 7,
  "content": ":soapbox:",
  "tags": [
    ["emoji", "soapbox", "https://gleasonator.com/emoji/Gleasonator/soapbox.png"]
  ],
  // other fields...
}

The content can be set only one :shortcode:. And emoji tag should be one.

NIP-26

Delegated Event Signing

draft optional

This NIP defines how events can be delegated so that they can be signed by other keypairs.

Another application of this proposal is to abstract away the use of the ‘root’ keypairs when interacting with clients. For example, a user could generate new keypairs for each client they wish to use and authorize those keypairs to generate events on behalf of their root pubkey, where the root keypair is stored in cold storage.

Introducing the ‘delegation’ tag

This NIP introduces a new tag: delegation which is formatted as follows:

[
  "delegation",
  <pubkey of the delegator>,
  <conditions query string>,
  <delegation token: 64-byte Schnorr signature of the sha256 hash of the delegation string>
]

Delegation Token

The delegation token should be a 64-byte Schnorr signature of the sha256 hash of the following string:

nostr:delegation:<pubkey of publisher (delegatee)>:<conditions query string>

Conditions Query String

The following fields and operators are supported in the above query string:

Fields:

1. kind
   • Operators:
     • =${KIND_NUMBER} - delegatee may only sign events of this kind
2. created_at
   • Operators:
     • <${TIMESTAMP} - delegatee may only sign events created before the specified timestamp
     • >${TIMESTAMP} - delegatee may only sign events created after the specified timestamp

In order to create a single condition, you must use a supported field and operator. Multiple conditions can be used in a single query string, including on the same field. Conditions must be combined with &.

For example, the following condition strings are valid:

• kind=1&created_at<1675721813
• kind=0&kind=1&created_at>1675721813
• kind=1&created_at>1674777689&created_at<1675721813

For the vast majority of use-cases, it is advisable that:

1. Query strings should include a created_at after condition reflecting the current time, to prevent the delegatee from publishing historic notes on the delegator’s behalf.
2. Query strings should include a created_at before condition that is not empty and is not some extremely distant time in the future. If delegations are not limited in time scope, they expose similar security risks to simply using the root key for authentication.

Example

## Delegator:
privkey: ee35e8bb71131c02c1d7e73231daa48e9953d329a4b701f7133c8f46dd21139c
pubkey:  8e0d3d3eb2881ec137a11debe736a9086715a8c8beeeda615780064d68bc25dd

## Delegatee:
privkey: 777e4f60b4aa87937e13acc84f7abcc3c93cc035cb4c1e9f7a9086dd78fffce1
pubkey:  477318cfb5427b9cfc66a9fa376150c1ddbc62115ae27cef72417eb959691396

Delegation string to grant note publishing authorization to the delegatee (477318cf) from now, for the next 30 days, given the current timestamp is 1674834236.

nostr:delegation:477318cfb5427b9cfc66a9fa376150c1ddbc62115ae27cef72417eb959691396:kind=1&created_at>1674834236&created_at<1677426236

The delegator (8e0d3d3e) then signs a SHA256 hash of the above delegation string, the result of which is the delegation token:

6f44d7fe4f1c09f3954640fb58bd12bae8bb8ff4120853c4693106c82e920e2b898f1f9ba9bd65449a987c39c0423426ab7b53910c0c6abfb41b30bc16e5f524

The delegatee (477318cf) can now construct an event on behalf of the delegator (8e0d3d3e). The delegatee then signs the event with its own private key and publishes.

{
  "id": "e93c6095c3db1c31d15ac771f8fc5fb672f6e52cd25505099f62cd055523224f",
  "pubkey": "477318cfb5427b9cfc66a9fa376150c1ddbc62115ae27cef72417eb959691396",
  "created_at": 1677426298,
  "kind": 1,
  "tags": [
    [
      "delegation",
      "8e0d3d3eb2881ec137a11debe736a9086715a8c8beeeda615780064d68bc25dd",
      "kind=1&created_at>1674834236&created_at<1677426236",
      "6f44d7fe4f1c09f3954640fb58bd12bae8bb8ff4120853c4693106c82e920e2b898f1f9ba9bd65449a987c39c0423426ab7b53910c0c6abfb41b30bc16e5f524"
    ]
  ],
  "content": "Hello, world!",
  "sig": "633db60e2e7082c13a47a6b19d663d45b2a2ebdeaf0b4c35ef83be2738030c54fc7fd56d139652937cdca875ee61b51904a1d0d0588a6acd6168d7be2909d693"
}

The event should be considered a valid delegation if the conditions are satisfied (kind=1, created_at>1674834236 and created_at<1677426236 in this example) and, upon validation of the delegation token, are found to be unchanged from the conditions in the original delegation string.

Clients should display the delegated note as if it was published directly by the delegator (8e0d3d3e).

Relay & Client Support

Relays should answer requests such as ["REQ", "", {"authors": ["A"]}] by querying both the pubkey and delegation tags [1] value.

Relays SHOULD allow the delegator (8e0d3d3e) to delete the events published by the delegatee (477318cf).

NIP-27

Text Note References

draft optional

This document standardizes the treatment given by clients of inline references of other events and profiles inside the .content of any event that has readable text in its .content (such as kinds 1 and 30023).

When creating an event, clients should include mentions to other profiles and to other events in the middle of the .content using NIP-21 codes, such as nostr:nprofile1qqsw3dy8cpu...6x2argwghx6egsqstvg.

Including NIP-10 -style tags (["e", <hex-id>, <relay-url>, <marker>]) for each reference is optional, clients should do it whenever they want the profile being mentioned to be notified of the mention, or when they want the referenced event to recognize their mention as a reply.

A reader client that receives an event with such nostr:... mentions in its .content can do any desired context augmentation (for example, linking to the profile or showing a preview of the mentioned event contents) it wants in the process. If turning such mentions into links, they could become internal links, NIP-21 links or direct links to web clients that will handle these references.

Example of a profile mention process

Suppose Bob is writing a note in a client that has search-and-autocomplete functionality for users that is triggered when they write the character @.

As Bob types "hello @mat" the client will prompt him to autocomplete with mattn’s profile , showing a picture and name.

Bob presses “enter” and now he sees his typed note as "hello @mattn", @mattn is highlighted, indicating that it is a mention. Internally, however, the event looks like this:

{
  "content": "hello nostr:nprofile1qqszclxx9f5haga8sfjjrulaxncvkfekj097t6f3pu65f86rvg49ehqj6f9dh",
  "created_at": 1679790774,
  "id": "f39e9b451a73d62abc5016cffdd294b1a904e2f34536a208874fe5e22bbd47cf",
  "kind": 1,
  "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
  "sig": "f8c8bab1b90cc3d2ae1ad999e6af8af449ad8bb4edf64807386493163e29162b5852a796a8f474d6b1001cddbaac0de4392838574f5366f03cc94cf5dfb43f4d",
  "tags": [
    [
      "p",
      "2c7cc62a697ea3a7826521f3fd34f0cb273693cbe5e9310f35449f43622a5cdc"
    ]
  ]
}

(Alternatively, the mention could have been a nostr:npub1... URL.)

After Bob publishes this event and Carol sees it, her client will initially display the .content as it is, but later it will parse the .content and see that there is a nostr: URL in there, decode it, extract the public key from it (and possibly relay hints), fetch that profile from its internal database or relays, then replace the full URL with the name @mattn, with a link to the internal page view for that profile.

Verbose and probably unnecessary considerations

• The example above was very concrete, but it doesn’t mean all clients have to implement the same flow. There could be clients that do not support autocomplete at all, so they just allow users to paste raw NIP-19 codes into the body of text, then prefix these with nostr: before publishing the event.
• The flow for referencing other events is similar: a user could paste a note1... or nevent1... code and the client will turn that into a nostr:note1... or nostr:nevent1... URL. Then upon reading such references the client may show the referenced note in a preview box or something like that – or nothing at all.
• Other display procedures can be employed: for example, if a client that is designed for dealing with only kind:1 text notes sees, for example, a kind:30023 nostr:naddr1... URL reference in the .content, it can, for example, decide to turn that into a link to some hardcoded webapp capable of displaying such events.
• Clients may give the user the option to include or not include tags for mentioned events or profiles. If someone wants to mention mattn without notifying them, but still have a nice augmentable/clickable link to their profile inside their note, they can instruct their client to not create a ["p", ...] tag for that specific mention.
• In the same way, if someone wants to reference another note but their reference is not meant to show up along other replies to that same note, their client can choose to not include a corresponding ["e", ...] tag for any given nostr:nevent1... URL inside .content. Clients may decide to expose these advanced functionalities to users or be more opinionated about things.

NIP-28

Public Chat

draft optional

This NIP defines new event kinds for public chat channels, channel messages, and basic client-side moderation.

It reserves five event kinds (40-44) for immediate use:

• 40 - channel create
• 41 - channel metadata
• 42 - channel message
• 43 - hide message
• 44 - mute user

Client-centric moderation gives client developers discretion over what types of content they want included in their apps, while imposing no additional requirements on relays.

Kind 40: Create channel

Create a public chat channel.

In the channel creation content field, Client SHOULD include basic channel metadata (name, about, picture and relays as specified in kind 41).

{
  "content": "{\"name\": \"Demo Channel\", \"about\": \"A test channel.\", \"picture\": \"https://placekitten.com/200/200\", \"relays\": [\"wss://nos.lol\", \"wss://nostr.mom\"]}",
 // other fields...
}

Kind 41: Set channel metadata

Update a channel’s public metadata.

Kind 41 is used to update the metadata without modifying the event id for the channel. Only the most recent kind 41 per e tag value MAY be available.

Clients SHOULD ignore kind 41s from pubkeys other than the kind 40 pubkey.

Clients SHOULD support basic metadata fields:

• name - string - Channel name
• about - string - Channel description
• picture - string - URL of channel picture
• relays - array - List of relays to download and broadcast events to

Clients MAY add additional metadata fields.

Clients SHOULD use NIP-10 marked “e” tags to recommend a relay.

{
  "content": "{\"name\": \"Updated Demo Channel\", \"about\": \"Updating a test channel.\", \"picture\": \"https://placekitten.com/201/201\", \"relays\": [\"wss://nos.lol\", \"wss://nostr.mom\"]}",
  "tags": [["e", <channel_create_event_id>, <relay-url>]],
  // other fields...
}

Kind 42: Create channel message

Send a text message to a channel.

Clients SHOULD use NIP-10 marked “e” tags to recommend a relay and specify whether it is a reply or root message.

Clients SHOULD append NIP-10 “p” tags to replies.

Root message:

{
  "content": <string>,
  "tags": [["e", <kind_40_event_id>, <relay-url>, "root"]],
  // other fields...
}

Reply to another message:

{
  "content": <string>,
  "tags": [
      ["e", <kind_40_event_id>, <relay-url>, "root"],
      ["e", <kind_42_event_id>, <relay-url>, "reply"],
      ["p", <pubkey>, <relay-url>],
      // rest of tags...
  ],
  // other fields...
}

Kind 43: Hide message

User no longer wants to see a certain message.

The content may optionally include metadata such as a reason.

Clients SHOULD hide event 42s shown to a given user, if there is an event 43 from that user matching the event 42 id.

Clients MAY hide event 42s for other users other than the user who sent the event 43.

(For example, if three users ‘hide’ an event giving a reason that includes the word ‘pornography’, a Nostr client that is an iOS app may choose to hide that message for all iOS clients.)

{
  "content": "{\"reason\": \"Dick pic\"}",
  "tags": [["e", <kind_42_event_id>]],
  // other fields...
}

Kind 44: Mute user

User no longer wants to see messages from another user.

The content may optionally include metadata such as a reason.

Clients SHOULD hide event 42s shown to a given user, if there is an event 44 from that user matching the event 42 pubkey.

Clients MAY hide event 42s for users other than the user who sent the event 44.

{
  "content": "{\"reason\": \"Posting dick pics\"}",
  "tags": [["p", <pubkey>]],
  // other fields...
}

Relay recommendations

Clients SHOULD use the relay URLs of the metadata events.

Clients MAY use any relay URL. For example, if a relay hosting the original kind 40 event for a channel goes offline, clients could instead fetch channel data from a backup relay, or a relay that clients trust more than the original relay.

Motivation

If we’re solving censorship-resistant communication for social media, we may as well solve it also for Telegram-style messaging.

We can bring the global conversation out from walled gardens into a true public square open to all.

Additional info

• Chat demo PR with fiatjaf+jb55 comments
• Conversation about NIP16

NIP-29

Relay-based Groups

draft optional

This NIP defines a standard for groups that are only writable by a closed set of users. They can be public for reading by external users or not.

Groups are identified by a random string of any length that serves as an id.

There is no way to create a group, what happens is just that relays (most likely when asked by users) will create rules around some specific ids so these ids can serve as an actual group, henceforth messages sent to that group will be subject to these rules.

Normally a group will originally belong to one specific relay, but the community may choose to move the group to other relays or even fork the group so it exists in different forms – still using the same id – across different relays.

Relay-generated events

Relays are supposed to generate the events that describe group metadata and group admins. These are addressable events signed by the relay keypair directly, with the group id as the d tag.

Group identifier

A group may be identified by a string in the format <host>'<group-id>. For example, a group with id abcdef hosted at the relay wss://groups.nostr.com would be identified by the string groups.nostr.com'abcdef.

Group identifiers must be strings restricted to the characters a-z0-9-_.

When encountering just the <host> without the '<group-id>, clients can choose to connect to the group with id _, which is a special top-level group dedicated to relay-local discussions.

Group identifiers in most cases should be random or pseudo-random, as that mitigates message replay confusion and ensures they can be migrated or forked to other relays easily without risking conflicting with other groups using the same id in these new relays. This isn’t a hard rule, as, for example, in unmanaged and/or ephemeral relays groups might not want to migrate ever, so they might not care about this. Notably, the _ relay-local group isn’t expected to be migrated ever.

The h tag

Events sent by users to groups (chat messages, text notes, moderation events etc) must have an h tag with the value set to the group id.

Timeline references

In order to not be used out of context, events sent to these groups may contain references to previous events seen from the same relay in the previous tag. The choice of which previous events to pick belongs to the clients. The references are to be made using the first 8 characters (4 bytes) of any event in the last 50 events seen by the user in the relay, excluding events by themselves. There can be any number of references (including zero), but it’s recommended that clients include at least 3 and that relays enforce this.

This is a hack to prevent messages from being broadcasted to external relays that have forks of one group out of context. Relays are expected to reject any events that contain timeline references to events not found in their own database. Clients should also check these to keep relays honest about them.

Late publication

Relays should prevent late publication (messages published now with a timestamp from days or even hours ago) unless they are open to receive a group forked or moved from another relay.

Group management

Groups can have any number of users with elevated access. These users are identified by role labels which are arbitrarily defined by the relays (see also the description of kind:39003). What each role is capable of not defined in this NIP either, it’s a relay policy that can vary. Roles can be assigned by other users (as long as they have the capability to add roles) by publishing a kind:9000 event with that user’s pubkey in a p tag and the roles afterwards (even if the user is already a group member a kind:9000 can be issued and the user roles must just be updated).

The roles supported by the group as to having some special privilege assigned to them should be accessible on the event kind:39003, but the relay may also accept other role names, arbitrarily defined by clients, and just not do anything with them.

Users with any roles that have any privilege can be considered admins in a broad sense and be returned in the kind:39001 event for a group.

Unmanaged groups

Unmanaged groups are impromptu groups that can be used in any public relay unaware of NIP-29 specifics. They piggyback on relays’ natural white/blacklists (or lack of) but aside from that are not actively managed and won’t have any admins, group state or metadata events.

In unmanaged groups, everybody is considered to be a member.

Unmanaged groups can transition to managed groups, in that case the relay master key just has to publish moderation events setting the state of all groups and start enforcing the rules they choose to.

Event definitions

These are the events expected to be found in NIP-29 groups.

Normal user-created events

These events generally can be sent by all members of a group and they require the h tag to be present so they’re attached to a specific group.

• chat message (kind:9)

This is the basic unit of a chat message sent to a group.

  "kind": 9,
  "content": "hello my friends lovers of pizza",
  "tags": [
    ["h", "<group-id>"],
    ["previous", "<event-id-first-chars>", "<event-id-first-chars>", /*...*/]
  ]
  // other fields...

• thread root post (kind:11)

This is the basic unit of a forum-like root thread post sent to a group.

  "kind": 11,
  "content": "hello my friends lovers of pizza",
  "tags": [
    ["h", "<group-id>"],
    ["previous", "<event-id-first-chars>", "<event-id-first-chars>", /*...*/]
  ]
  // other fields...

• other events:

Groups may also accept other events, like NIP-22 comments as threaded replies to both chats messages and threads, long-form articles, calendar, livestreams, market announcements and so on. These should be as defined in their respective NIPs, with the addition of the h tag.

User-related group management events

These are events that can be sent by users to manage their situation in a group, they also require the h tag.

• join request (kind:9021)

Any user can send one of these events to the relay in order to be automatically or manually added to the group. If the group is open the relay will automatically issue a kind:9000 in response adding this user. Otherwise group admins may choose to query for these requests and act upon them.

{
  "kind": 9021,
  "content": "optional reason",
  "tags": [
    ["h", "<group-id>"],
    ["code", "<optional-invite-code>"]
  ]
}

The optional code tag may be used by the relay to preauthorize acceptances in closed groups, together with the kind:9009 create-invite moderation event.

• leave request (kind:9022)

Any user can send one of these events to the relay in order to be automatically removed from the group. The relay will automatically issue a kind:9001 in response removing this user.

{
  "kind": 9022,
  "content": "optional reason",
  "tags": [
    ["h", "<group-id>"]
  ]
}

Group state – or moderation

These are events expected to be sent by the relay master key or by group admins – and relays should reject them if they don’t come from an authorized admin. They also require the h tag.

• moderation events (kinds:9000-9020) (optional)

Clients can send these events to a relay in order to accomplish a moderation action. Relays must check if the pubkey sending the event is capable of performing the given action based on its role and the relay’s internal policy (see also the description of kind:39003).

{
  "kind": 90xx,
  "content": "optional reason",
  "tags": [
    ["h", "<group-id>"],
    ["previous", /*...*/]
  ]
}

Each moderation action uses a different kind and requires different arguments, which are given as tags. These are defined in the following table:

It’s expected that the group state (of who is an allowed member or not, who is an admin and with which permission or not, what are the group name and picture etc) can be fully reconstructed from the canonical sequence of these events.

Group metadata events

These events contain the group id in a d tag instead of the h tag. They MUST be created by the relay master key only and a single instance of each (or none) should exist at all times for each group. They are merely informative but should reflect the latest group state (as it was changed by moderation events over time).

• group metadata (kind:39000) (optional)

This event defines the metadata for the group – basically how clients should display it. It must be generated and signed by the relay in which is found. Relays shouldn’t accept these events if they’re signed by anyone else.

If the group is forked and hosted in multiple relays, there will be multiple versions of this event in each different relay and so on.

When this event is not found, clients may still connect to the group, but treat it as having a different status, unmanaged,

{
  "kind": 39000,
  "content": "",
  "tags": [
    ["d", "<group-id>"],
    ["name", "Pizza Lovers"],
    ["picture", "https://pizza.com/pizza.png"],
    ["about", "a group for people who love pizza"],
    ["public"], // or ["private"]
    ["open"] // or ["closed"]
  ]
  // other fields...
}

name, picture and about are basic metadata for the group for display purposes. public signals the group can be read by anyone, while private signals that only AUTHed users can read. open signals that anyone can request to join and the request will be automatically granted, while closed signals that members must be pre-approved or that requests to join will be manually handled.

• group admins (kind:39001) (optional)

Each admin is listed along with one or more roles. These roles SHOULD have a correspondence with the roles supported by the relay, as advertised by the kind:39003 event.

{
  "kind": 39001,
  "content": "list of admins for the pizza lovers group",
  "tags": [
    ["d", "<group-id>"],
    ["p", "<pubkey1-as-hex>", "ceo"],
    ["p", "<pubkey2-as-hex>", "secretary", "gardener"],
    // other pubkeys...
  ],
  // other fields...
}

• group members (kind:39002) (optional)

It’s a list of pubkeys that are members of the group. Relays might choose to not to publish this information, to restrict what pubkeys can fetch it or to only display a subset of the members in it.

Clients should not assume this will always be present or that it will contain a full list of members.

{
  "kind": 39002,
  "content": "list of members for the pizza lovers group",
  "tags": [
    ["d", "<group-id>"],
    ["p", "<admin1>"],
    ["p", "<member-pubkey1>"],
    ["p", "<member-pubkey2>"],
    // other pubkeys...
  ],
  // other fields...
}

• group roles (kind:39003) (optional)

This is an event that MAY be published by the relay informing users and clients about what are the roles supported by this relay according to its internal logic.

For example, a relay may choose to support the roles "admin" and "moderator", in which the "admin" will be allowed to edit the group metadata, delete messages and remove users from the group, while the "moderator" can only delete messages (or the relay may choose to call these roles "ceo" and "secretary" instead, the exact role name is not relevant).

The process through which the relay decides what roles to support and how to handle moderation events internally based on them is specific to each relay and not specified here.

{
  "kind": 39003,
  "content": "list of roles supported by this group",
  "tags": [
    ["d", "<group-id>"],
    ["role", "<role-name>", "<optional-description>"],
    ["role", "<role-name>", "<optional-description>"],
    // other roles...
  ],
  // other fields...
}

Implementation quirks

Checking your own membership in a group

The latest of either kind:9000 or kind:9001 events present in a group should tell a user that they are currently members of the group or if they were removed. In case none of these exist the user is assumed to not be a member of the group – unless the group is unmanaged, in which case the user is assumed to be a member.

Adding yourself to a group

When a group is open, anyone can send a kind:9021 event to it in order to be added, then expect a kind:9000 event to be emitted confirming that the user was added. The same happens with closed groups, except in that case a user may only send a kind:9021 if it has an invite code.

Storing your list of groups

A definition for kind:10009 was included in NIP-51 that allows clients to store the list of groups a user wants to remember being in.

Using unmanaged relays

To prevent event leakage, replay and confusion, when using unmanaged relays, clients should include the NIP-70 - tag, as just the previous tag won’t be checked by other unmanaged relays.

NIP-30

Custom Emoji

draft optional

Custom emoji may be added to kind 0, kind 1, kind 7 (NIP-25 ) and kind 30315 (NIP-38 ) events by including one or more "emoji" tags, in the form:

["emoji", <shortcode>, <image-url>]

Where:

• <shortcode> is a name given for the emoji, which MUST be comprised of only alphanumeric characters and underscores.
• <image-url> is a URL to the corresponding image file of the emoji.

For each emoji tag, clients should parse emoji shortcodes (aka “emojify”) like :shortcode: in the event to display custom emoji.

Clients may allow users to add custom emoji to an event by including :shortcode: identifier in the event, and adding the relevant "emoji" tags.

Kind 0 events

In kind 0 events, the name and about fields should be emojified.

{
  "kind": 0,
  "content": "{\"name\":\"Alex Gleason :soapbox:\"}",
  "tags": [
    ["emoji", "soapbox", "https://gleasonator.com/emoji/Gleasonator/soapbox.png"]
  ],
  "pubkey": "79c2cae114ea28a981e7559b4fe7854a473521a8d22a66bbab9fa248eb820ff6",
  "created_at": 1682790000
}

Kind 1 events

In kind 1 events, the content should be emojified.

{
  "kind": 1,
  "content": "Hello :gleasonator: 😂 :ablobcatrainbow: :disputed: yolo",
    "tags": [
    ["emoji", "ablobcatrainbow", "https://gleasonator.com/emoji/blobcat/ablobcatrainbow.png"],
    ["emoji", "disputed", "https://gleasonator.com/emoji/Fun/disputed.png"],
    ["emoji", "gleasonator", "https://gleasonator.com/emoji/Gleasonator/gleasonator.png"]
  ],
  "pubkey": "79c2cae114ea28a981e7559b4fe7854a473521a8d22a66bbab9fa248eb820ff6",
  "created_at": 1682630000
}

Kind 7 events

In kind 7 events, the content should be emojified.

{
  "kind": 7,
  "content": ":dezh:",
  "tags": [
    ["emoji", "dezh", "https://raw.githubusercontent.com/dezh-tech/brand-assets/main/dezh/logo/black-normal.svg"]
  ],
  "pubkey": "79c2cae114ea28a981e7559b4fe7854a473521a8d22a66bbab9fa248eb820ff6",
  "created_at": 1682630000
}

NIP-31

Dealing with unknown event kinds

draft optional

When creating a new custom event kind that is part of a custom protocol and isn’t meant to be read as text (like kind:1), clients should use an alt tag to write a short human-readable plaintext summary of what that event is about.

The intent is that social clients, used to display only kind:1 notes, can still show something in case a custom event pops up in their timelines. The content of the alt tag should provide enough context for a user that doesn’t know anything about this event kind to understand what it is.

These clients that only know kind:1 are not expected to ask relays for events of different kinds, but users could still reference these weird events on their notes, and without proper context these could be nonsensical notes. Having the fallback text makes that situation much better – even if only for making the user aware that they should try to view that custom event elsewhere.

kind:1-centric clients can make interacting with these event kinds more functional by supporting NIP-89 .

NIP-32

Labeling

draft optional

This NIP defines two new indexable tags to label events and a new event kind (kind:1985) to attach those labels to existing events. This supports several use cases, including distributed moderation, collection management, license assignment, and content classification.

New Tags:

• L denotes a label namespace
• l denotes a label

Label Namespace Tag

An L tag can be any string, but publishers SHOULD ensure they are unambiguous by using a well-defined namespace (such as an ISO standard) or reverse domain name notation.

L tags are RECOMMENDED in order to support searching by namespace rather than by a specific tag. The special ugc (“user generated content”) namespace MAY be used when the label content is provided by an end user.

L tags starting with # indicate that the label target should be associated with the label’s value. This is a way of attaching standard nostr tags to events, pubkeys, relays, urls, etc.

Label Tag

An l tag’s value can be any string. If using an L tag, l tags MUST include a mark matching an L tag value in the same event. If no L tag is included, a mark SHOULD still be included. If none is included, ugc is implied.

Label Target

The label event MUST include one or more tags representing the object or objects being labeled: e, p, a, r, or t tags. This allows for labeling of events, people, relays, or topics respectively. As with NIP-01, a relay hint SHOULD be included when using e and p tags.

Content

Labels should be short, meaningful strings. Longer discussions, such as for an explanation of why something was labeled the way it was, should go in the event’s content field.

Self-Reporting

l and L tags MAY be added to other event kinds to support self-reporting. For events with a kind other than 1985, labels refer to the event itself.

Example events

A suggestion that multiple pubkeys be associated with the permies topic.

{
  "kind": 1985,
  "tags": [
    ["L", "#t"],
    ["l", "permies", "#t"],
    ["p", <pubkey1>, <relay_url>],
    ["p", <pubkey2>, <relay_url>]
  ],
  // other fields...
}

A report flagging violence toward a human being as defined by ontology.example.com.

{
  "kind": 1985,
  "tags": [
    ["L", "com.example.ontology"],
    ["l", "VI-hum", "com.example.ontology"],
    ["p", <pubkey1>, <relay_url>],
    ["p", <pubkey2>, <relay_url>]
  ],
  // other fields...
}

A moderation suggestion for a chat event.

{
  "kind": 1985,
  "tags": [
    ["L", "nip28.moderation"],
    ["l", "approve", "nip28.moderation"],
    ["e", <kind40_event_id>, <relay_url>]
  ],
  // other fields...
}

Assignment of a license to an event.

{
  "kind": 1985,
  "tags": [
    ["L", "license"],
    ["l", "MIT", "license"],
    ["e", <event_id>, <relay_url>]
  ],
  // other fields...
}

Publishers can self-label by adding l tags to their own non-1985 events. In this case, the kind 1 event’s author is labeling their note as being related to Milan, Italy using ISO 3166-2.

{
  "kind": 1,
  "tags": [
    ["L", "ISO-3166-2"],
    ["l", "IT-MI", "ISO-3166-2"]
  ],
  "content": "It's beautiful here in Milan!",
  // other fields...
}

Author is labeling their note language as English using ISO-639-1.

{
  "kind": 1,
  "tags": [
    ["L", "ISO-639-1"],
    ["l", "en", "ISO-639-1"]
  ],
  "content": "English text",
  // other fields...
}

Other Notes

When using this NIP to bulk-label many targets at once, events may be requested for deletion using NIP-09 and a replacement may be published. We have opted not to use addressable/replaceable events for this due to the complexity in coming up with a standard d tag. In order to avoid ambiguity when querying, publishers SHOULD limit labeling events to a single namespace.

Before creating a vocabulary, explore how your use case may have already been designed and imitate that design if possible. Reverse domain name notation is encouraged to avoid namespace clashes, but for the sake of interoperability all namespaces should be considered open for public use, and not proprietary. In other words, if there is a namespace that fits your use case, use it even if it points to someone else’s domain name.

Vocabularies MAY choose to fully qualify all labels within a namespace (for example, ["l", "com.example.vocabulary:my-label"]. This may be preferred when defining more formal vocabularies that should not be confused with another namespace when querying without an L tag. For these vocabularies, all labels SHOULD include the namespace (rather than mixing qualified and unqualified labels).

A good heuristic for whether a use case fits this NIP is whether labels would ever be unique. For example, many events might be labeled with a particular place, topic, or pubkey, but labels with specific values like “John Doe” or “3.18743” are not labels, they are values, and should be handled in some other way.

Appendix: Known Ontologies

Below is a non-exhaustive list of ontologies currently in widespread use.

• social.ontolo.categories

NIP-33

Parameterized Replaceable Events

final mandatory

Renamed to “Addressable events” and moved to NIP-01 .

NIP-34

git stuff

draft optional

This NIP defines all the ways code collaboration using and adjacent to git can be done using Nostr.

Repository announcements

Git repositories are hosted in Git-enabled servers, but their existence can be announced using Nostr events, as well as their willingness to receive patches, bug reports and comments in general.

{
  "kind": 30617,
  "content": "",
  "tags": [
    ["d", "<repo-id>"], // usually kebab-case short name
    ["name", "<human-readable project name>"],
    ["description", "brief human-readable project description>"],
    ["web", "<url for browsing>", ...], // a webpage url, if the git server being used provides such a thing
    ["clone", "<url for git-cloning>", ...], // a url to be given to `git clone` so anyone can clone it
    ["relays", "<relay-url>", ...] // relays that this repository will monitor for patches and issues
    ["r", "<earliest-unique-commit-id>", "euc"]
    ["maintainers", "<other-recognized-maintainer>", ...]
  ]
}

The tags web, clone, relays, maintainers can have multiple values.

The r tag annotated with the "euc" marker should be the commit ID of the earliest unique commit of this repo, made to identify it among forks and group it with other repositories hosted elsewhere that may represent essentially the same project. In most cases it will be the root commit of a repository. In case of a permanent fork between two projects, then the first commit after the fork should be used.

Except d, all tags are optional.

Repository state announcements

An optional source of truth for the state of branches and tags in a repository.

{
  "kind": 30618,
  "content": "",
  "tags": [
    ["d", "<repo-id>"], // matches the identifier in the coresponding repository announcement
    ["refs/<heads|tags>/<branch-or-tag-name>","<commit-id>"]
    ["HEAD", "ref: refs/heads/<branch-name>"]
  ]
}

The refs tag may appear multiple times, or none.

If no refs tags are present, the author is no longer tracking repository state using this event. This approach enables the author to restart tracking state at a later time unlike NIP-09 deletion requests.

The refs tag can be optionally extended to enable clients to identify how many commits ahead a ref is:

{
  "tags": [
    ["refs/<heads|tags>/<branch-or-tag-name>", "<commit-id>", "<shorthand-parent-commit-id>", "<shorthand-grandparent>", ...],
  ]
}

Patches

Patches can be sent by anyone to any repository. Patches to a specific repository SHOULD be sent to the relays specified in that repository’s announcement event’s "relays" tag. Patch events SHOULD include an a tag pointing to that repository’s announcement address.

Patches in a patch set SHOULD include a NIP-10 e reply tag pointing to the previous patch.

The first patch revision in a patch revision SHOULD include a NIP-10 e reply to the original root patch.

{
  "kind": 1617,
  "content": "<patch>", // contents of <git format-patch>
  "tags": [
    ["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>"],
    ["r", "<earliest-unique-commit-id-of-repo>"] // so clients can subscribe to all patches sent to a local git repo
    ["p", "<repository-owner>"],
    ["p", "<other-user>"], // optionally send the patch to another user to bring it to their attention

    ["t", "root"], // omitted for additional patches in a series
    // for the first patch in a revision
    ["t", "root-revision"],

    // optional tags for when it is desirable that the merged patch has a stable commit id
    // these fields are necessary for ensuring that the commit resulting from applying a patch
    // has the same id as it had in the proposer's machine -- all these tags can be omitted
    // if the maintainer doesn't care about these things
    ["commit", "<current-commit-id>"],
    ["r", "<current-commit-id>"] // so clients can find existing patches for a specific commit
    ["parent-commit", "<parent-commit-id>"],
    ["commit-pgp-sig", "-----BEGIN PGP SIGNATURE-----..."], // empty string for unsigned commit
    ["committer", "<name>", "<email>", "<timestamp>", "<timezone offset in minutes>"],
  ]
}

The first patch in a series MAY be a cover letter in the format produced by git format-patch.

Issues

Issues are Markdown text that is just human-readable conversational threads related to the repository: bug reports, feature requests, questions or comments of any kind. Like patches, these SHOULD be sent to the relays specified in that repository’s announcement event’s "relays" tag.

Issues may have a subject tag, which clients can utilize to display a header. Additionally, one or more t tags may be included to provide labels for the issue.

{
  "kind": 1621,
  "content": "<markdown text>",
  "tags": [
    ["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>"],
    ["p", "<repository-owner>"]
    ["subject", "<issue-subject>"]
    ["t", "<issue-label>"]
    ["t", "<another-issue-label>"]
  ]
}

Replies

Replies are also Markdown text. The difference is that they MUST be issued as replies to either a kind:1621 issue or a kind:1617 patch event. The threading of replies and patches should follow NIP-10 rules.

{
  "kind": 1622,
  "content": "<markdown text>",
  "tags": [
    ["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>", "<relay-url>"],
    ["e", "<issue-or-patch-id-hex>", "", "root"],

    // other "e" and "p" tags should be applied here when necessary, following the threading rules of NIP-10
    ["p", "<patch-author-pubkey-hex>", "", "mention"],
    ["e", "<previous-reply-id-hex>", "", "reply"],
    // rest of tags...
  ],
  // other fields...
}

Status

Root Patches and Issues have a Status that defaults to ‘Open’ and can be set by issuing Status events.

{
  "kind": 1630, // Open
  "kind": 1631, // Applied / Merged for Patches; Resolved for Issues
  "kind": 1632, // Closed
  "kind": 1633, // Draft
  "content": "<markdown text>",
  "tags": [
    ["e", "<issue-or-original-root-patch-id-hex>", "", "root"],
    ["e", "<accepted-revision-root-id-hex>", "", "reply"], // for when revisions applied
    ["p", "<repository-owner>"],
    ["p", "<root-event-author>"],
    ["p", "<revision-author>"],

    // optional for improved subscription filter efficiency
    ["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>", "<relay-url>"],
    ["r", "<earliest-unique-commit-id-of-repo>"]

    // optional for `1631` status
    ["e", "<applied-or-merged-patch-event-id>", "", "mention"], // for each
    // when merged
    ["merge-commit", "<merge-commit-id>"]
    ["r", "<merge-commit-id>"]
    // when applied
    ["applied-as-commits", "<commit-id-in-master-branch>", ...]
    ["r", "<applied-commit-id>"] // for each
  ]
}

The Status event with the largest created_at date is valid.

The Status of a patch-revision defaults to either that of the root-patch, or 1632 (Closed) if the root-patch’s Status is 1631 and the patch-revision isn’t tagged in the 1631 event.

Possible things to be added later

• “branch merge” kind (specifying a URL from where to fetch the branch to be merged)
• inline file comments kind (we probably need one for patches and a different one for merged files)

NIP-35

Torrents

draft optional

This NIP defined a new kind 2003 which is a Torrent.

kind 2003 is a simple torrent index where there is enough information to search for content and construct the magnet link. No torrent files exist on nostr.

Tags

• x: V1 BitTorrent Info Hash, as seen in the magnet link magnet:?xt=urn:btih:HASH
• file: A file entry inside the torrent, including the full path ie. info/example.txt
• tracker: (Optional) A tracker to use for this torrent

In order to make torrents searchable by general category, you SHOULD include a few tags like movie, tv, HD, UHD etc.

Tag prefixes

Tag prefixes are used to label the content with references, ie. ["i", "imdb:1234"]

• tcat: A comma separated text category path, ie. ["i", "tcat:video,movie,4k"], this should also match the newznab category in a best effort approach.
• newznab: The category ID from newznab
• tmdb: The movie database id.
• ttvdb: TV database id.
• imdb: IMDB id.
• mal: MyAnimeList id.
• anilist: AniList id.

A second level prefix should be included where the database supports multiple media types.

• tmdb:movie:693134 maps to themoviedb.org/movie/693134
• ttvdb:movie:290272 maps to thetvdb.com/movies/dune-part-two
• mal:anime:9253 maps to myanimelist.net/anime/9253
• mal:manga:17517 maps to myanimelist.net/manga/17517

In some cases the url mapping isnt direct, mapping the url in general is out of scope for this NIP, the section above is only a guide so that implementers have enough information to succsesfully map the url if they wish.

{
  "kind": 2003,
  "content": "<long-description-pre-formatted>",
  "tags": [
    ["title", "<torrent-title>"],
    ["x", "<bittorrent-info-hash>"],
    ["file", "<file-name>", "<file-size-in-bytes>"],
    ["file", "<file-name>", "<file-size-in-bytes>"],
    ["tracker", "udp://mytacker.com:1337"],
    ["tracker", "http://1337-tracker.net/announce"],
    ["i", "tcat:video,movie,4k"],
    ["i", "newznab:2045"],
    ["i", "imdb:tt15239678"],
    ["i", "tmdb:movie:693134"],
    ["i", "ttvdb:movie:290272"],
    ["t", "movie"],
    ["t", "4k"],
  ]
}

Torrent Comments

A torrent comment is a kind 2004 event which is used to reply to a torrent event.

This event works exactly like a kind 1 and should follow NIP-10 for tagging.

Implementations

1. dtan.xyz
2. nostrudel.ninja NIP-36 ======

Sensitive Content / Content Warning

draft optional

The content-warning tag enables users to specify if the event’s content needs to be approved by readers to be shown. Clients can hide the content until the user acts on it.

l and L tags MAY be also be used as defined in NIP-32 with the content-warning or other namespace to support further qualification and querying.

Spec

tag: content-warning
options:
 - [reason]: optional

Example

{
  "pubkey": "<pub-key>",
  "created_at": 1000000000,
  "kind": 1,
  "tags": [
    ["t", "hastag"],
    ["L", "content-warning"],
    ["l", "reason", "content-warning"],
    ["L", "social.nos.ontology"],
    ["l", "NS-nud", "social.nos.ontology"],
    ["content-warning", "<optional reason>"]
  ],
  "content": "sensitive content with #hastag\n",
  "id": "<event-id>"
}

NIP-38

User Statuses

draft optional

Abstract

This NIP enables a way for users to share live statuses such as what music they are listening to, as well as what they are currently doing: work, play, out of office, etc.

Live Statuses

A special event with kind:30315 “User Status” is defined as an optionally expiring addressable event, where the d tag represents the status type:

For example:

{
  "kind": 30315,
  "content": "Sign up for nostrasia!",
  "tags": [
    ["d", "general"],
    ["r", "https://nostr.world"]
  ],
}

{
  "kind": 30315,
  "content": "Intergalatic - Beastie Boys",
  "tags": [
    ["d", "music"],
    ["r", "spotify:search:Intergalatic%20-%20Beastie%20Boys"],
    ["expiration", "1692845589"]
  ],
}

Two common status types are defined: general and music. general represent general statuses: “Working”, “Hiking”, etc.

music status events are for live streaming what you are currently listening to. The expiry of the music status should be when the track will stop playing.

Any other status types can be used but they are not defined by this NIP.

The status MAY include an r, p, e or a tag linking to a URL, profile, note, or addressable event.

The content MAY include emoji(s), or NIP-30 custom emoji(s). If the content is an empty string then the client should clear the status.

Client behavior

Clients MAY display this next to the username on posts or profiles to provide live user status information.

Use Cases

• Calendar nostr apps that update your general status when you’re in a meeting
• Nostr Nests that update your general status with a link to the nest when you join
• Nostr music streaming services that update your music status when you’re listening
• Podcasting apps that update your music status when you’re listening to a podcast, with a link for others to listen as well
• Clients can use the system media player to update playing music status

NIP-39

External Identities in Profiles

draft optional

Abstract

Nostr protocol users may have other online identities such as usernames, profile pages, keypairs etc. they control and they may want to include this data in their profile metadata so clients can parse, validate and display this information.

i tag on a metadata event

A new optional i tag is introduced for kind 0 metadata event defined in NIP-01 :

{
  "id": <id>,
  "pubkey": <pubkey>,
  "tags": [
    ["i", "github:semisol", "9721ce4ee4fceb91c9711ca2a6c9a5ab"],
    ["i", "twitter:semisol_public", "1619358434134196225"],
    ["i", "mastodon:bitcoinhackers.org/@semisol", "109775066355589974"]
    ["i", "telegram:1087295469", "nostrdirectory/770"]
  ],
  // other fields...
}

An i tag will have two parameters, which are defined as the following:

1. platform:identity: This is the platform name (for example github) and the identity on that platform (for example semisol) joined together with :.
2. proof: String or object that points to the proof of owning this identity.

Clients SHOULD process any i tags with more than 2 values for future extensibility. Identity provider names SHOULD only include a-z, 0-9 and the characters ._-/ and MUST NOT include :. Identity names SHOULD be normalized if possible by replacing uppercase letters with lowercase letters, and if there are multiple aliases for an entity the primary one should be used.

Claim types

github

Identity: A GitHub username.

Proof: A GitHub Gist ID. This Gist should be created by <identity> with a single file that has the text Verifying that I control the following Nostr public key: <npub encoded public key>. This can be located at https://gist.github.com/<identity>/<proof>.

twitter

Identity: A Twitter username.

Proof: A Tweet ID. The tweet should be posted by <identity> and have the text Verifying my account on nostr My Public Key: "<npub encoded public key>". This can be located at https://twitter.com/<identity>/status/<proof>.

mastodon

Identity: A Mastodon instance and username in the format <instance>/@<username>.

Proof: A Mastodon post ID. This post should be published by <username>@<instance> and have the text Verifying that I control the following Nostr public key: "<npub encoded public key>". This can be located at https://<identity>/<proof>.

telegram

Identity: A Telegram user ID.

Proof: A string in the format <ref>/<id> which points to a message published in the public channel or group with name <ref> and message ID <id>. This message should be sent by user ID <identity> and have the text Verifying that I control the following Nostr public key: "<npub encoded public key>". This can be located at https://t.me/<proof>.

NIP-40

Expiration Timestamp

draft optional

The expiration tag enables users to specify a unix timestamp at which the message SHOULD be considered expired (by relays and clients) and SHOULD be deleted by relays.

Spec

tag: expiration
values:
 - [UNIX timestamp in seconds]: required

Example

{
  "pubkey": "<pub-key>",
  "created_at": 1000000000,
  "kind": 1,
  "tags": [
    ["expiration", "1600000000"]
  ],
  "content": "This message will expire at the specified timestamp and be deleted by relays.\n",
  "id": "<event-id>"
}

Note: The timestamp should be in the same format as the created_at timestamp and should be interpreted as the time at which the message should be deleted by relays.

Client Behavior

Clients SHOULD use the supported_nips field to learn if a relay supports this NIP. Clients SHOULD NOT send expiration events to relays that do not support this NIP.

Clients SHOULD ignore events that have expired.

Relay Behavior

Relays MAY NOT delete expired messages immediately on expiration and MAY persist them indefinitely. Relays SHOULD NOT send expired events to clients, even if they are stored. Relays SHOULD drop any events that are published to them if they are expired. An expiration timestamp does not affect storage of ephemeral events.

Suggested Use Cases

• Temporary announcements - This tag can be used to make temporary announcements. For example, an event organizer could use this tag to post announcements about an upcoming event.
• Limited-time offers - This tag can be used by businesses to make limited-time offers that expire after a certain amount of time. For example, a business could use this tag to make a special offer that is only available for a limited time.

Warning

The events could be downloaded by third parties as they are publicly accessible all the time on the relays. So don’t consider expiring messages as a security feature for your conversations or other uses.

NIP-42

Authentication of clients to relays

draft optional

This NIP defines a way for clients to authenticate to relays by signing an ephemeral event.

Motivation

A relay may want to require clients to authenticate to access restricted resources. For example,

• A relay may request payment or other forms of whitelisting to publish events – this can naïvely be achieved by limiting publication to events signed by the whitelisted key, but with this NIP they may choose to accept any events as long as they are published from an authenticated user;
• A relay may limit access to kind: 4 DMs to only the parties involved in the chat exchange, and for that it may require authentication before clients can query for that kind.
• A relay may limit subscriptions of any kind to paying users or users whitelisted through any other means, and require authentication.

Definitions

New client-relay protocol messages

This NIP defines a new message, AUTH, which relays CAN send when they support authentication and clients can send to relays when they want to authenticate. When sent by relays the message has the following form:

["AUTH", <challenge-string>]

And, when sent by clients, the following form:

["AUTH", <signed-event-json>]

AUTH messages sent by clients MUST be answered with an OK message, like any EVENT message.

Canonical authentication event

The signed event is an ephemeral event not meant to be published or queried, it must be of kind: 22242 and it should have at least two tags, one for the relay URL and one for the challenge string as received from the relay. Relays MUST exclude kind: 22242 events from being broadcasted to any client. created_at should be the current time. Example:

{
  "kind": 22242,
  "tags": [
    ["relay", "wss://relay.example.com/"],
    ["challenge", "challengestringhere"]
  ],
  // other fields...
}

OK and CLOSED machine-readable prefixes

This NIP defines two new prefixes that can be used in OK (in response to event writes by clients) and CLOSED (in response to rejected subscriptions by clients):

• "auth-required: " - for when a client has not performed AUTH and the relay requires that to fulfill the query or write the event.
• "restricted: " - for when a client has already performed AUTH but the key used to perform it is still not allowed by the relay or is exceeding its authorization.

Protocol flow

At any moment the relay may send an AUTH message to the client containing a challenge. The challenge is valid for the duration of the connection or until another challenge is sent by the relay. The client MAY decide to send its AUTH event at any point and the authenticated session is valid afterwards for the duration of the connection.

auth-required in response to a REQ message

Given that a relay is likely to require clients to perform authentication only for certain jobs, like answering a REQ or accepting an EVENT write, these are some expected common flows:

relay: ["AUTH", "<challenge>"]
client: ["REQ", "sub_1", {"kinds": [4]}]
relay: ["CLOSED", "sub_1", "auth-required: we can't serve DMs to unauthenticated users"]
client: ["AUTH", {"id": "abcdef...", ...}]
relay: ["OK", "abcdef...", true, ""]
client: ["REQ", "sub_1", {"kinds": [4]}]
relay: ["EVENT", "sub_1", {...}]
relay: ["EVENT", "sub_1", {...}]
relay: ["EVENT", "sub_1", {...}]
relay: ["EVENT", "sub_1", {...}]
...

In this case, the AUTH message from the relay could be sent right as the client connects or it can be sent immediately before the CLOSED is sent. The only requirement is that the client must have a stored challenge associated with that relay so it can act upon that in response to the auth-required CLOSED message.

auth-required in response to an EVENT message

The same flow is valid for when a client wants to write an EVENT to the relay, except now the relay sends back an OK message instead of a CLOSED message:

relay: ["AUTH", "<challenge>"]
client: ["EVENT", {"id": "012345...", ...}]
relay: ["OK", "012345...", false, "auth-required: we only accept events from registered users"]
client: ["AUTH", {"id": "abcdef...", ...}]
relay: ["OK", "abcdef...", true, ""]
client: ["EVENT", {"id": "012345...", ...}]
relay: ["OK", "012345...", true, ""]

Signed Event Verification

To verify AUTH messages, relays must ensure:

• that the kind is 22242;
• that the event created_at is close (e.g. within ~10 minutes) of the current time;
• that the "challenge" tag matches the challenge sent before;
• that the "relay" tag matches the relay URL:
  • URL normalization techniques can be applied. For most cases just checking if the domain name is correct should be enough.

NIP-44

Encrypted Payloads (Versioned)

optional

The NIP introduces a new data format for keypair-based encryption. This NIP is versioned to allow multiple algorithm choices to exist simultaneously. This format may be used for many things, but MUST be used in the context of a signed event as described in NIP 01.

Note: this format DOES NOT define any kinds related to a new direct messaging standard, only the encryption required to define one. It SHOULD NOT be used as a drop-in replacement for NIP 04 payloads.

Versions

Currently defined encryption algorithms:

• 0x00 - Reserved
• 0x01 - Deprecated and undefined
• 0x02 - secp256k1 ECDH, HKDF, padding, ChaCha20, HMAC-SHA256, base64

Limitations

Every nostr user has their own public key, which solves key distribution problems present in other solutions. However, nostr’s relay-based architecture makes it difficult to implement more robust private messaging protocols with things like metadata hiding, forward secrecy, and post compromise secrecy.

The goal of this NIP is to have a simple way to encrypt payloads used in the context of a signed event. When applying this NIP to any use case, it’s important to keep in mind your users’ threat model and this NIP’s limitations. For high-risk situations, users should chat in specialized E2EE messaging software and limit use of nostr to exchanging contacts.

On its own, messages sent using this scheme have a number of important shortcomings:

• No deniability: it is possible to prove an event was signed by a particular key
• No forward secrecy: when a key is compromised, it is possible to decrypt all previous conversations
• No post-compromise security: when a key is compromised, it is possible to decrypt all future conversations
• No post-quantum security: a powerful quantum computer would be able to decrypt the messages
• IP address leak: user IP may be seen by relays and all intermediaries between user and relay
• Date leak: created_at is public, since it is a part of NIP 01 event
• Limited message size leak: padding only partially obscures true message length
• No attachments: they are not supported

Lack of forward secrecy may be partially mitigated by only sending messages to trusted relays, and asking relays to delete stored messages after a certain duration has elapsed.

Version 2

NIP-44 version 2 has the following design characteristics:

• Payloads are authenticated using a MAC before signing rather than afterwards because events are assumed to be signed as specified in NIP-01. The outer signature serves to authenticate the full payload, and MUST be validated before decrypting.
• ChaCha is used instead of AES because it’s faster and has better security against multi-key attacks .
• ChaCha is used instead of XChaCha because XChaCha has not been standardized. Also, xChaCha’s improved collision resistance of nonces isn’t necessary since every message has a new (key, nonce) pair.
• HMAC-SHA256 is used instead of Poly1305 because polynomial MACs are much easier to forge.
• SHA256 is used instead of SHA3 or BLAKE because it is already used in nostr. Also BLAKE’s speed advantage is smaller in non-parallel environments.
• A custom padding scheme is used instead of padmé because it provides better leakage reduction for small messages.
• Base64 encoding is used instead of another compression algorithm because it is widely available, and is already used in nostr.

Encryption

1. Calculate a conversation key
   • Execute ECDH (scalar multiplication) of public key B by private key A Output shared_x must be unhashed, 32-byte encoded x coordinate of the shared point
   • Use HKDF-extract with sha256, IKM=shared_x and salt=utf8_encode('nip44-v2')
   • HKDF output will be a conversation_key between two users.
   • It is always the same, when key roles are swapped: conv(a, B) == conv(b, A)
2. Generate a random 32-byte nonce
   • Always use CSPRNG
   • Don’t generate a nonce from message content
   • Don’t re-use the same nonce between messages: doing so would make them decryptable, but won’t leak the long-term key
3. Calculate message keys
   • The keys are generated from conversation_key and nonce. Validate that both are 32 bytes long
   • Use HKDF-expand, with sha256, PRK=conversation_key, info=nonce and L=76
   • Slice 76-byte HKDF output into: chacha_key (bytes 0..32), chacha_nonce (bytes 32..44), hmac_key (bytes 44..76)
4. Add padding
   • Content must be encoded from UTF-8 into byte array
   • Validate plaintext length. Minimum is 1 byte, maximum is 65535 bytes
   • Padding format is: [plaintext_length: u16][plaintext][zero_bytes]
   • Padding algorithm is related to powers-of-two, with min padded msg size of 32
   • Plaintext length is encoded in big-endian as first 2 bytes of the padded blob
5. Encrypt padded content
   • Use ChaCha20, with key and nonce from step 3
6. Calculate MAC (message authentication code)
   • AAD (additional authenticated data) is used - instead of calculating MAC on ciphertext, it’s calculated over a concatenation of nonce and ciphertext
   • Validate that AAD (nonce) is 32 bytes
7. Base64-encode (with padding) params using concat(version, nonce, ciphertext, mac)

Encrypted payloads MUST be included in an event’s payload, hashed, and signed as defined in NIP 01, using schnorr signature scheme over secp256k1.

Decryption

Before decryption, the event’s pubkey and signature MUST be validated as defined in NIP 01. The public key MUST be a valid non-zero secp256k1 curve point, and the signature must be valid secp256k1 schnorr signature. For exact validation rules, refer to BIP-340.

1. Check if first payload’s character is #
   • # is an optional future-proof flag that means non-base64 encoding is used
   • The # is not present in base64 alphabet, but, instead of throwing base64 is invalid, implementations MUST indicate that the encryption version is not yet supported
2. Decode base64
   • Base64 is decoded into version, nonce, ciphertext, mac
   • If the version is unknown, implementations must indicate that the encryption version is not supported
   • Validate length of base64 message to prevent DoS on base64 decoder: it can be in range from 132 to 87472 chars
   • Validate length of decoded message to verify output of the decoder: it can be in range from 99 to 65603 bytes
3. Calculate conversation key
   • See step 1 of encryption
4. Calculate message keys
   • See step 3 of encryption
5. Calculate MAC (message authentication code) with AAD and compare
   • Stop and throw an error if MAC doesn’t match the decoded one from step 2
   • Use constant-time comparison algorithm
6. Decrypt ciphertext
   • Use ChaCha20 with key and nonce from step 3
7. Remove padding
   • Read the first two BE bytes of plaintext that correspond to plaintext length
   • Verify that the length of sliced plaintext matches the value of the two BE bytes
   • Verify that calculated padding from step 3 of the encryption process matches the actual padding

Details

• Cryptographic methods
  • secure_random_bytes(length) fetches randomness from CSPRNG.
  • hkdf(IKM, salt, info, L) represents HKDF (RFC 5869) with SHA256 hash function comprised of methods hkdf_extract(IKM, salt) and hkdf_expand(OKM, info, L).
  • chacha20(key, nonce, data) is ChaCha20 (RFC 8439) with starting counter set to 0.
  • hmac_sha256(key, message) is HMAC (RFC 2104) .
  • secp256k1_ecdh(priv_a, pub_b) is multiplication of point B by scalar a (a ⋅ B), defined in BIP340 . The operation produces a shared point, and we encode the shared point’s 32-byte x coordinate, using method bytes(P) from BIP340. Private and public keys must be validated as per BIP340: pubkey must be a valid, on-curve point, and private key must be a scalar in range [1, secp256k1_order - 1]. NIP44 doesn’t do hashing of the output: keep this in mind, because some libraries hash it using sha256. As an example, in libsecp256k1, unhashed version is available in secp256k1_ec_pubkey_tweak_mul
• Operators
  • x[i:j], where x is a byte array and i, j <= 0 returns a (j - i)-byte array with a copy of the i-th byte (inclusive) to the j-th byte (exclusive) of x.
• Constants c:
  • min_plaintext_size is 1. 1b msg is padded to 32b.
  • max_plaintext_size is 65535 (64kb - 1). It is padded to 65536.
• Functions
  • base64_encode(string) and base64_decode(bytes) are Base64 (RFC 4648 , with padding)
  • concat refers to byte array concatenation
  • is_equal_ct(a, b) is constant-time equality check of 2 byte arrays
  • utf8_encode(string) and utf8_decode(bytes) transform string to byte array and back
  • write_u8(number) restricts number to values 0..255 and encodes into Big-Endian uint8 byte array
  • write_u16_be(number) restricts number to values 0..65535 and encodes into Big-Endian uint16 byte array
  • zeros(length) creates byte array of length length >= 0, filled with zeros
  • floor(number) and log2(number) are well-known mathematical methods

Implementation pseudocode

The following is a collection of python-like pseudocode functions which implement the above primitives, intended to guide implementers. A collection of implementations in different languages is available at https://github.com/paulmillr/nip44 .

## Calculates length of the padded byte array.
def calc_padded_len(unpadded_len):
  next_power = 1 << (floor(log2(unpadded_len - 1))) + 1
  if next_power <= 256:
    chunk = 32
  else:
    chunk = next_power / 8
  if unpadded_len <= 32:
    return 32
  else:
    return chunk * (floor((len - 1) / chunk) + 1)

## Converts unpadded plaintext to padded bytearray
def pad(plaintext):
  unpadded = utf8_encode(plaintext)
  unpadded_len = len(plaintext)
  if (unpadded_len < c.min_plaintext_size or
      unpadded_len > c.max_plaintext_size): raise Exception('invalid plaintext length')
  prefix = write_u16_be(unpadded_len)
  suffix = zeros(calc_padded_len(unpadded_len) - unpadded_len)
  return concat(prefix, unpadded, suffix)

## Converts padded bytearray to unpadded plaintext
def unpad(padded):
  unpadded_len = read_uint16_be(padded[0:2])
  unpadded = padded[2:2+unpadded_len]
  if (unpadded_len == 0 or
      len(unpadded) != unpadded_len or
      len(padded) != 2 + calc_padded_len(unpadded_len)): raise Exception('invalid padding')
  return utf8_decode(unpadded)

## metadata: always 65b (version: 1b, nonce: 32b, max: 32b)
## plaintext: 1b to 0xffff
## padded plaintext: 32b to 0xffff
## ciphertext: 32b+2 to 0xffff+2
## raw payload: 99 (65+32+2) to 65603 (65+0xffff+2)
## compressed payload (base64): 132b to 87472b
def decode_payload(payload):
  plen = len(payload)
  if plen == 0 or payload[0] == '#': raise Exception('unknown version')
  if plen < 132 or plen > 87472: raise Exception('invalid payload size')
  data = base64_decode(payload)
  dlen = len(d)
  if dlen < 99 or dlen > 65603: raise Exception('invalid data size');
  vers = data[0]
  if vers != 2: raise Exception('unknown version ' + vers)
  nonce = data[1:33]
  ciphertext = data[33:dlen - 32]
  mac = data[dlen - 32:dlen]
  return (nonce, ciphertext, mac)

def hmac_aad(key, message, aad):
  if len(aad) != 32: raise Exception('AAD associated data must be 32 bytes');
  return hmac(sha256, key, concat(aad, message));

## Calculates long-term key between users A and B: `get_key(Apriv, Bpub) == get_key(Bpriv, Apub)`
def get_conversation_key(private_key_a, public_key_b):
  shared_x = secp256k1_ecdh(private_key_a, public_key_b)
  return hkdf_extract(IKM=shared_x, salt=utf8_encode('nip44-v2'))

## Calculates unique per-message key
def get_message_keys(conversation_key, nonce):
  if len(conversation_key) != 32: raise Exception('invalid conversation_key length')
  if len(nonce) != 32: raise Exception('invalid nonce length')
  keys = hkdf_expand(OKM=conversation_key, info=nonce, L=76)
  chacha_key = keys[0:32]
  chacha_nonce = keys[32:44]
  hmac_key = keys[44:76]
  return (chacha_key, chacha_nonce, hmac_key)

def encrypt(plaintext, conversation_key, nonce):
  (chacha_key, chacha_nonce, hmac_key) = get_message_keys(conversation_key, nonce)
  padded = pad(plaintext)
  ciphertext = chacha20(key=chacha_key, nonce=chacha_nonce, data=padded)
  mac = hmac_aad(key=hmac_key, message=ciphertext, aad=nonce)
  return base64_encode(concat(write_u8(2), nonce, ciphertext, mac))

def decrypt(payload, conversation_key):
  (nonce, ciphertext, mac) = decode_payload(payload)
  (chacha_key, chacha_nonce, hmac_key) = get_message_keys(conversation_key, nonce)
  calculated_mac = hmac_aad(key=hmac_key, message=ciphertext, aad=nonce)
  if not is_equal_ct(calculated_mac, mac): raise Exception('invalid MAC')
  padded_plaintext = chacha20(key=chacha_key, nonce=chacha_nonce, data=ciphertext)
  return unpad(padded_plaintext)

## Usage:
##   conversation_key = get_conversation_key(sender_privkey, recipient_pubkey)
##   nonce = secure_random_bytes(32)
##   payload = encrypt('hello world', conversation_key, nonce)
##   'hello world' == decrypt(payload, conversation_key)

Audit

The v2 of the standard was audited by Cure53 in December 2023. Check out audit-2023.12.pdf and auditor’s website .

Tests and code

A collection of implementations in different languages is available at https://github.com/paulmillr/nip44 .

We publish extensive test vectors. Instead of having it in the document directly, a sha256 checksum of vectors is provided:

269ed0f69e4c192512cc779e78c555090cebc7c785b609e338a62afc3ce25040  nip44.vectors.json

Example of a test vector from the file:

{
  "sec1": "0000000000000000000000000000000000000000000000000000000000000001",
  "sec2": "0000000000000000000000000000000000000000000000000000000000000002",
  "conversation_key": "c41c775356fd92eadc63ff5a0dc1da211b268cbea22316767095b2871ea1412d",
  "nonce": "0000000000000000000000000000000000000000000000000000000000000001",
  "plaintext": "a",
  "payload": "AgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABee0G5VSK0/9YypIObAtDKfYEAjD35uVkHyB0F4DwrcNaCXlCWZKaArsGrY6M9wnuTMxWfp1RTN9Xga8no+kF5Vsb"
}

The file also contains intermediate values. A quick guidance with regards to its usage:

• valid.get_conversation_key: calculate conversation_key from secret key sec1 and public key pub2
• valid.get_message_keys: calculate chacha_key, chacha_nonce, hmac_key from conversation_key and nonce
• valid.calc_padded_len: take unpadded length (first value), calculate padded length (second value)
• valid.encrypt_decrypt: emulate real conversation. Calculate pub2 from sec2, verify conversation_key from (sec1, pub2), encrypt, verify payload, then calculate pub1 from sec1, verify conversation_key from (sec2, pub1), decrypt, verify plaintext.
• valid.encrypt_decrypt_long_msg: same as previous step, but instead of a full plaintext and payload, their checksum is provided.
• invalid.encrypt_msg_lengths
• invalid.get_conversation_key: calculating conversation_key must throw an error
• invalid.decrypt: decrypting message content must throw an error

NIP-45

Event Counts

draft optional

Relays may support the verb COUNT, which provides a mechanism for obtaining event counts.

Motivation

Some queries a client may want to execute against connected relays are prohibitively expensive, for example, in order to retrieve follower counts for a given pubkey, a client must query all kind-3 events referring to a given pubkey only to count them. The result may be cached, either by a client or by a separate indexing server as an alternative, but both options erode the decentralization of the network by creating a second-layer protocol on top of Nostr.

Filters and return values

This NIP defines the verb COUNT, which accepts a subscription id and filters as specified in NIP 01 for the verb REQ. Multiple filters are OR’d together and aggregated into a single count result.

["COUNT", <subscription_id>, <filters JSON>...]

Counts are returned using a COUNT response in the form {"count": <integer>}. Relays may use probabilistic counts to reduce compute requirements. In case a relay uses probabilistic counts, it MAY indicate it in the response with approximate key i.e. {"count": <integer>, "approximate": <true|false>}.

["COUNT", <subscription_id>, {"count": <integer>}]

Whenever the relay decides to refuse to fulfill the COUNT request, it MUST return a CLOSED message.

Examples

Followers count

["COUNT", <subscription_id>, {"kinds": [3], "#p": [<pubkey>]}]
["COUNT", <subscription_id>, {"count": 238}]

Count posts and reactions

["COUNT", <subscription_id>, {"kinds": [1, 7], "authors": [<pubkey>]}]
["COUNT", <subscription_id>, {"count": 5}]

Count posts approximately

["COUNT", <subscription_id>, {"kinds": [1]}]
["COUNT", <subscription_id>, {"count": 93412452, "approximate": true}]

Relay refuses to count

["COUNT", <subscription_id>, {"kinds": [4], "authors": [<pubkey>], "#p": [<pubkey>]}]
["CLOSED", <subscription_id>, "auth-required: cannot count other people's DMs"]

NIP-46

Nostr Remote Signing

Changes

remote-signer-key is introduced, passed in bunker url, clients must differentiate between remote-signer-pubkey and user-pubkey, must call get_public_key after connect, nip05 login is removed, create_account moved to another NIP.

Rationale

Private keys should be exposed to as few systems - apps, operating systems, devices - as possible as each system adds to the attack surface.

This NIP describes a method for 2-way communication between a remote signer and a Nostr client. The remote signer could be, for example, a hardware device dedicated to signing Nostr events, while the client is a normal Nostr client.

Terminology

• user: A person that is trying to use Nostr.
• client: A user-facing application that user is looking at and clicking buttons in. This application will send requests to remote-signer.
• remote-signer: A daemon or server running somewhere that will answer requests from client, also known as “bunker”.
• client-keypair/pubkey: The keys generated by client. Used to encrypt content and communicate with remote-signer.
• remote-signer-keypair/pubkey: The keys used by remote-signer to encrypt content and communicate with client. This keypair MAY be same as user-keypair, but not necessarily.
• user-keypair/pubkey: The actual keys representing user (that will be used to sign events in response to sign_event requests, for example). The remote-signer generally has control over these keys.

All pubkeys specified in this NIP are in hex format.

Overview

1. client generates client-keypair. This keypair doesn’t need to be communicated to user since it’s largely disposable. client might choose to store it locally and they should delete it on logout;
2. A connection is established (see below), remote-signer learns client-pubkey, client learns remote-signer-pubkey.
3. client uses client-keypair to send requests to remote-signer by p-tagging and encrypting to remote-signer-pubkey;
4. remote-signer responds to client by p-tagging and encrypting to the client-pubkey.
5. client requests get_public_key to learn user-pubkey.

Initiating a connection

There are two ways to initiate a connection:

Direct connection initiated by remote-signer

remote-signer provides connection token in the form:

bunker://<remote-signer-pubkey>?relay=<wss://relay-to-connect-on>&relay=<wss://another-relay-to-connect-on>&secret=<optional-secret-value>

user passes this token to client, which then sends connect request to remote-signer via the specified relays. Optional secret can be used for single successfully established connection only, remote-signer SHOULD ignore new attempts to establish connection with old secret.

Direct connection initiated by the client

client provides a connection token in the form:

nostrconnect://<client-pubkey>?relay=<wss://relay-to-connect-on>&metadata=<json metadata: {"name":"...", "url": "...", "description": "...", "perms": "..."}>&secret=<required-secret-value>

user passes this token to remote-signer, which then sends connect response event to the client-pubkey via the specified relays. Client discovers remote-signer-pubkey from connect response author. secret value MUST be provided to avoid connection spoofing, client MUST validate the secret returned by connect response.

Request Events kind: 24133

{
    "kind": 24133,
    "pubkey": <local_keypair_pubkey>,
    "content": <nip04(<request>)>,
    "tags": [["p", <remote-signer-pubkey>]],
}