NIP-42 Authentication of clients to relays draft optional author:Semisol author:fiatjaf 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.

NIP-19 bech32-encoded entities draft optional author:jb55 author:fiatjaf author:Semisol 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.

NIP-40 Expiration Timestamp draft optional author:0xtlt 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.

NIP-36 Sensitive Content / Content Warning draft optional author:fernandolguevara 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. Spec tag: content-warning options: - [reason]: optional Example { "pubkey": "<pub-key>", "created_at": 1000000000, "kind": 1, "tags": [ ["t", "hastag"], ["content-warning", "reason"] /* reason is optional */ ], "content": "sensitive content with #hastag\n", "id": "<event-id>" } Source: nostr-protocol/nips/36.

NIP-20 Command Results draft optional author:jb55 When submitting events to relays, clients currently have no way to know if an event was successfully committed to the database. This NIP introduces the concept of command results which are like NOTICE’s except provide more information about if an event was accepted or rejected. A command result is a JSON object with the following structure that is returned when an event is successfully saved to the database or rejected:

Introduction Virtual Private Network (VPN) is a secure method for remote users to access resources on a private network over the public internet. One of the widely used VPN protocols is IPsec, which stands for Internet Protocol Security. It provides security for internet protocol (IP) communications by encrypting all data packets to provide confidentiality and authentication for each IP packet of the data stream. In this article, we will go through the steps of configuring an IPsec VPN.

OpenVPN is an open-source virtual private network (VPN) solution that provides a secure and encrypted connection between networks. It allows you to securely access remote networks and protect your online activities from being monitored. In this article, we’ll take a step-by-step approach to configuring OpenVPN on your system. Install and Set up OpenVPN Install OpenVPN: The first step in configuring OpenVPN is to install it on your system. On Windows systems, you can download the OpenVPN client from the official website and follow the installation instructions.

Server Name Indication (SNI) is a feature in the Transport Layer Security (TLS) protocol that enables a client to send the hostname of the website it wants to connect to before starting the SSL/TLS negotiation. This information is used by the server to determine which certificate to present to the client, allowing multiple websites to share the same IP address and still maintain secure, encrypted connections. However, before the advent of encrypted SNI, this information was sent in plain text, making it vulnerable to snooping and tampering.

OAuth and OpenID are two popular authentication protocols that are widely used for authorization and authentication purposes. Both protocols allow users to securely sign in to a website or application without revealing their passwords. However, they have different purposes and uses, and it’s essential to understand the key differences between the two. In this article, we’ll take a closer look at OAuth and OpenID and compare them in detail. Authorization or Authentication OAuth (Open Authorization) is an authorization protocol that enables third-party applications to access user data without revealing their passwords.

NIP-28 Public Chat draft optional author:ChristopherDavid author:fiatjaf author:jb55 author:Cameri 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.

NIP-27 Text Note References draft optional author:arthurfranca author:hodlbod author:fiatjaf 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.

NIP: 26 Delegated Event Signing draft optional author:markharding author:minds 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.

NIP-25 Reactions draft optional author:jb55 A reaction is a kind 7 note that is used to react to other notes. 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.

NIP-22 Event created_at Limits draft optional author:jeffthibault author:Giszmo Relays may define both upper and lower limits within which they will consider an event’s created_at to be acceptable. Both the upper and lower limits MUST be unix timestamps in seconds as defined in NIP-01 . If a relay supports this NIP, the relay SHOULD send the client a NIP-20 command result saying the event was not stored for the created_at timestamp not being within the permitted limits.

NIP-15 End of Stored Events Notice final optional author:Semisol Relays may support notifying clients when all stored events have been sent. If a relay supports this NIP, the relay SHOULD send the client a EOSE message in the format ["EOSE", <subscription_id>] after it has sent all the events it has persisted and it indicates all the events that come after this message are newly published. Client Behavior Clients SHOULD use the supported_nips field to learn if a relay supports end of stored events notices.

NIP-16 Event Treatment draft optional author:Semisol Relays may decide to allow replaceable and/or ephemeral events. Regular Events A regular event is defined as an event with a kind 1000 <= n < 10000. Upon a regular event being received, the relay SHOULD send it to all clients with a matching filter, and SHOULD store it. New events of the same kind do not affect previous events in any way. Replaceable Events A replaceable event is defined as an event with a kind 10000 <= n < 20000.

NIP-14 Subject tag in Text events. draft optional author:unclebobmartin 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.

NIP-07 window.nostr capability for web browsers draft optional author:fiatjaf 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: Event): 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:

NIP-13 Proof of Work draft optional author:jb55 author:cameri 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.

NIP-10 On “e” and “p” tags in Text Events (kind 1). draft optional author:unclebobmartin 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. Positional “e” tags (DEPRECATED) This scheme is in common use; but should be considered deprecated. ["e", <event-id>, <relay-url>] as per NIP-01.

NIP-01 Basic protocol flow description draft mandatory author:fiatjaf author:distbit author:scsibug author:kukks author:jb55 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 .

NIP-02 Contact List and Petnames final optional author:fiatjaf author:arcbtc A special event with kind 3, meaning “contact 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.

NIP-03 OpenTimestamps Attestations for Events draft optional author:fiatjaf When there is an OTS available it MAY be included in the existing event body under the ots key: { "id": ..., "kind": ..., ..., ..., "ots": <base64-encoded OTS file data> } The event id MUST be used as the raw hash to be included in the OpenTimestamps merkle tree. The attestation can be either provided by relays automatically (and the OTS binary contents just appended to the events it receives) or by clients themselves when they first upload the event to relays — and used by clients to show that an event is really “at least as old as [OTS date]”.

NIP-04 Encrypted Direct Message final optional author:arcbtc 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”.

NIP-05 Mapping Nostr keys to DNS-based internet identifiers final optional author:fiatjaf author:mikedilger On events of kind 0 (set_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>/.

NIP-06 Basic key derivation from mnemonic seed phrase draft optional author:fiatjaf 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'/0'/0/0 (according to the Nostr entry on SLIP44 ). This is the default for a basic, normal, single-key client. Other types of clients can still get fancy and use other derivation paths for their own other purposes.

Warning unrecommended: deprecated in favor of NIP-27 NIP-08 Handling Mentions final unrecommended optional author:fiatjaf author:scsibug 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.

NIP-09 Event Deletion draft optional author:scsibug A special event with kind 5, meaning “deletion” is defined as having a list of one or more e tags, each referencing an event the author is requesting to be deleted. Each tag entry must contain an “e” event id intended for deletion. The event’s content field MAY contain a text note describing the reason for the deletion. For example: { "kind": 5, "pubkey": <32-bytes hex-encoded public key of the event creator>, "tags": [ ["e", "dcd59.

NIP-11 Relay Information Document draft optional author:scsibug author:doc-hex author:cameri 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.

NIP-12 Generic Tag Queries draft optional author:scsibug author:fiatjaf Relays may support subscriptions over arbitrary tags. NIP-01 requires relays to respond to queries for e and p tags. This NIP allows any single-letter tag present in an event to be queried. The <filters> object described in NIP-01 is expanded to contain arbitrary keys with a # prefix. Any single-letter key in a filter beginning with # is a tag query, and MUST have a value of an array of strings.