What is NOSTR?
We already covered Nostr Protocol in depth here, but briefly Nostr is an open protocol for creating censorship-resistant global networks. It uses a simple system of relays that can transmit messages and other data between users. The protocol does not rely on a blockchain, but rather uses private and public keys for identity and message signing. One of the main features of nostr is its ability to allow for direct messaging between users by combining their private and public keys to create a shared secret. There are various implementations and instances of Nostr, including clients and relays, that allow users to interact with the network and publish and view messages.
Protocol Basics – What Protocol is and Why is it even Important?
A computer protocol is a set of rules and guidelines that enable computers to communicate with each other. It specifies the format for exchanging information, as well as the rules for how the communication should take place. Protocols can be used for a variety of purposes, such as transferring data between computers or devices, accessing the internet, and sending emails. In general, a protocol defines the way in which different components of a system should interact in order to achieve a certain goal.
A computer protocol is a set of rules and guidelines that enable computers to communicate with each other. It specifies the format for exchanging information, as well as the rules for how the communication should take place. Protocols can be used for a variety of purposes, such as transferring data between computers or devices, accessing the internet, and sending emails. In general, a protocol defines the way in which different components of a system should interact in order to achieve a certain goal.
Here is a good video primer on protocols for those of us who would like to do a further deep dive into fundamentals.
now back to basics..
What Are NIPS – Nostr Implementation Possibilities?
Nostr Implementation Possibilities (or NIPs for short) are requirements and recommendations for implementing Nostr-compatible relay and client software. They specify what features must be implemented, what features should be implemented, and what features may be implemented. They serve as a guide for developers working on Nostr-compatible software.
Currently active NOSTR protocol NIPS are fully documented here and as of now have about 26 NIPS. Not all of them are yet final or required. Below is a brief summary of each to give you a basic idea how NOSTR while simple, can revolutionize the way we build social apps – if you don’t have time to go through all of the details yourself yet.
Here is a brief summary of the NIPS:
| NIP | Summary | Authors | State | Type |
|---|---|---|---|---|
| NIP-01: Basic protocol flow description | NIP-01 is a protocol that defines how users can communicate with each other using events. Events are objects that contain a public key, a timestamp, a kind, tags, content, and a signature. Clients can send events to relays, which will store them and send them to other clients who have subscribed to them. Clients can also subscribe to events that match certain criteria, such as events created by a certain user or events with certain tags. The protocol also defines some basic event kinds, such as `set_metadata`, `text_note`, and `recommend_server`. | fiatjaf, distbit, scsibug, kukks, jb55 | Final | Required |
| NIP-02: Contact List and Petnames | NIP-02 defines a special event type that allows users to store a list of contacts they are following, along with a local name (or “petname”) for each contact. This list can be used for contact list backup, profile discovery and context augmentation, relay sharing, and petname schemes. | fiatjaf, arcbtc | Draft | Required |
| NIP-03: OpenTimestamps Attestations for Events | NIP-03 is a proposal to add OpenTimestamps attestations to events. This would allow users to prove that an event was created at a certain time, by including a timestamp in the event body. This timestamp would be generated by OpenTimestamps, a decentralized timestamping system. The timestamp would be generated using the event id as the raw hash, and the timestamp would be included in the event body under the “ots” key. This would allow users to prove that an event was created at a certain time. | fiatjaf | Draft | Optional |
| NIP-04: Encrypted Direct Message | NIP-04 is a protocol for sending encrypted direct messages between two users. It requires the sender to encrypt the message using a shared cipher generated by combining the recipient’s public-key with the sender’s private-key. It also requires the sender to include an initialization vector as part of the message. This protocol provides a secure way for users to communicate with each other without their messages being intercepted. | arcbtc | Final | Required |
| NIP-05: Mapping Nostr keys to DNS-based internet identifiers | NIP-05 is a protocol that allows users to map their Nostr keys to DNS-based internet identifiers. It works by having a client make a GET request to a specific URL (`https://<domain>/.well-known/nostr.json?name=<local-part>`) and getting back 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 `set_metadata` event, the client then concludes that the given pubkey can indeed be referenced by its identifier. This protocol also allows for users to search for other profiles by typing in their internet identifier. | fiatjaf | Draft | Required |
| NIP-06: Basic key derivation from mnemonic seed phrase | NIP-06 is a proposal to standardize the derivation path for basic, single-key clients, so that all wallets and services can use the same path and be compatible with each other. | fiatjaf | Draft | Optional |
| NIP-07: window.nostr capability for web browsers | NIP-07 is a proposal for web browsers and extensions to provide a `window.nostr` object that websites and web-apps can use to securely sign events and encrypt data. This would allow for more secure communication between websites and users, and would provide a more secure way to authenticate users. | fiatjaf, nos2x, Alby, Blockcore | Draft | Required |
| NIP-08: Handling Mentions | NIP-08 describes a process for handling mentions of other events and pubkeys (a type of identification key) within the content of text notes in a client application. It specifies that when a mention is identified (such as when a user starts typing a special key or clicks a button to include a mention), the client must add the pubkey or event ID to the list of tags and replace the mention in the text with a notation that includes the index of the tag in the list. When a client receives a text note with these mentions, it can use the actual contents from the list of tags to replace the notation and add any additional context or information (such as links or previews) as desired. | fiatjaf, scsibug | Final | Required |
| NIP-09: Event Deletion | NIP-09 defines a special event type for deleting events. This event type allows authors to request that their events be deleted, and for clients and relays to act on those requests. Clients can choose to hide or indicate a deletion status for the events referenced in the deletion request, and relays should continue to publish the deletion event indefinitely. | scsibug | Draft | Required |
| NIP-10: Conventions for clients’ use of e and p tags in text events. | NIP-10 describes how to use “e” and “p” tags in text events, especially those that are replies to other text events. It explains how to use “e” tags to thread replies into a tree rooted at the original event, and how to use “p” tags to record who is involved in a reply thread. This helps clients keep track of conversations and who is involved in them. | UncleBobMartin | Final | Required |
| NIP-11: Relay Information Document | In non-technical terms, NIP-11 is a document that relays can use to provide information about their capabilities, administrative contacts, and other server attributes. This document is provided in the form of a JSON document over HTTP, and contains fields such as the name of the relay, a description, a pubkey, contact information, supported NIPs, software, and version. This document is used by clients to get information about the relay and its capabilities. | scsibug | Draft | Optional |
| NIP-12: Generic Tag Queries | In non-technical terms, NIP-12 allows for the use of generic tags in queries. This means that users can search for events based on tags, such as hashtags, geohashes, and references to other webpages. This allows for more efficient searching and more specific results. | scsibug, fiatjaf | Draft | Optional |
| NIP-13: Proof of Work | NIP-13 defines a way to generate and interpret Proof of Work for nostr notes. This is a way to add a proof of computational work to a note, which can be used as a means of spam deterrence. Mining is done by updating the nonce tag and recalculating the note id. The difficulty is defined as the number of leading zero bits in the note id. Relays can be queried for notes of a certain difficulty, and PoW can be outsourced to PoW providers for a fee. | jb55, cameri | Draft | Optional |
| NIP-14: Subject tag in text events. | In short, NIP-14 defines the use of the “subject” tag in text events, which can be used to display threaded lists of messages in browsers. It also suggests that when replying to a message, the subject tag should be replicated and may be adorned with “Re:”. Finally, it suggests that subjects should generally be shorter than 80 characters. | UncleBobMartin | Final | Required |
| NIP-15: End of Stored Events Notice | In non-technical terms, this NIP proposes a way for a relay to notify a client when all stored events have been sent. This would reduce uncertainty for the client and make their code simpler. | Semisol | Final | Required |
| NIP-16: Event Treatment | NIP-16 allows relays to decide whether to allow replaceable and/or ephemeral events. These events can be used for applications such as states, typing indicators, and messaging. | Semisol | Final | Required |
| NIP-18: Reposts | NIP-18 is a standard that defines how reposts should be formatted and used. It ensures that reposts are consistent and can be easily identified and tracked. | jb55 | Draft | Optional |
| NIP-19: bech32-encoded entities | NIP-19 is a standard that defines how to encode keys, ids and other information in a format that is easier for humans to read and use. It defines different prefixes for different types of information, such as public keys, private keys and event ids. It also defines a format for sharing profiles and events that includes extra metadata, such as the location of a relay. This standard is meant to make it easier for users to share and input data, while still keeping the core protocol secure. | jb55, fiatjaf, Semisol | Draft | Optional |
| NIP-20: Command Results | NIP-20 introduces the concept of command results which provide more information about if an event was accepted or rejected when submitting events to relays. Command results are like NOTICE’s except they provide more information about why an event was accepted or rejected. This information can be used by clients to be more intelligent about how to handle events, such as showing an error popup if an event is blocked or rate-limited. | jb55 | Draft | Required |
| NIP-22: Event created_at Limits | NIP-22 allows relays to set limits on the timestamp of events that they will accept. This means that if an event is created too far in the past or future, the relay will not store it. This NIP also allows clients to know if a relay has these restrictions in place. This can help create a better user experience by reducing the amount of events that appear out of order or from impossible dates. | Jeff Thibault, Giszmo | Final | optional |
| NIP-25: Reactions | NIP-25 allows users to react to other notes with a “like” or “dislike” by creating a reaction note. This reaction note includes tags from the note it is reacting to, so that users can be notified of reactions to posts they were mentioned in. The reaction note also includes an emoji, which can be interpreted as a “like” or displayed as an emoji reaction on the post. | jb55 | Draft | Optional |
| NIP-26: Delegated Event Signing | NIP 26 defines how events can be delegated so that they can be signed by other keypairs. This allows users to 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. This NIP also introduces a new tag, ‘delegation’, which is used to identify the keypair that is authorized to sign events on behalf of the root keypair. | Mark Harding, Minds | Final | Optional |
| NIP-28: Public Chat | This NIP defines new event kinds for public chat channels, channel messages, and basic client-side moderation. It reserves event kinds for immediate use and event kinds for future use. This NIP also outlines how clients should handle these events, such as how to recommend a relay and how to hide messages. This NIP is motivated by the idea of bringing the global conversation out from walled gardens into a true public square open to all. | ChristopherDavid, fiatjaf, jb55, Cameri | Draft | Optional |
| NIP-35: User Discovery | This NIP proposes a mechanism to allow users to discover other users and their associated relays. It does not modify any data or events within the nostr protocol, but instead extends the contents of `https://<domain>/.well-known/nostr.json?name=<local-part>` return values with additional relay information. This will allow clients to discover users via email-like addresses and potentially find what relays they post to along with their public key. | Mike Dilger | Draft | Optional |
| NIP-36: Sensitive Content | NIP-36 is a proposed standard that allows users to specify if the content of an event needs to be approved by readers before it is shown. This allows users to hide potentially sensitive content until the reader has given their approval. | fernandolguevara | Draft | Optional |
| NIP-40: Expiration Timestamp | NIP-40 enables users to specify a unix timestamp at which a message should be considered expired and deleted by relays. This can be used for temporary announcements, limited-time offers, and other uses. However, it should not be considered a security feature as the messages can still be downloaded by third parties. | 0xtlt | Draft | Required |