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.
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.
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.
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.
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.
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.
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.
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.
NIP-15 Nostr Marketplace draft optional
Based on https://github.com/lnbits/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.
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.
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:
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.
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.
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
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:
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.
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.
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”.
NIP-05 Mapping Nostr keys to DNS-based internet identifiers final optional
On events of kind 0 (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
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.
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.
NIP-09 Event Deletion draft optional
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 and/or a tags 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
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.
GDPR and CCPA Introduction The EU General Data Protection Regulation (Regulation (EU) 2016/679) (GDPR) took effect on May 25, 2018 and replaced the EU Directive and its member state implementing laws.
On June 28, 2018, California became the first U.S. state with a comprehensive consumer privacy law when it enacted the California Consumer Privacy Act of 2018 (CCPA), which becomes effective January 1, 2020, with some exceptions (Cal. Civ. Code §§ 1798.
CCPA Introduction California Consumer Privacy Act of 2018 (CCPA), which becomes effective January 1, 2020, with some exceptions (Cal. Civ. Code §§ 1798.100-1798.199). Given their comprehensiveness and broad reaches, each law may have significant impact on entities that collect and process personal data.
The CCPA grants California resident’s new rights regarding their personal information and imposes various data protection duties on certain entities conducting business in California. While it incorporates several GDPR concepts, such as the rights of access, portability, and data deletion, there are several areas where the CCPA requirements are more specific than those of the GDPR or where the GDPR goes beyond the CCPA requirements.
What Is the GDPR? The General Data Protection Regulation (GDPR) is a major law established in 2018 by the European Union (EU) to protect personal data. The law in the European Economic Area (EEA)—that’s the EU plus Iceland, Liechtenstein, and Norway—recognizes data protection as a fundamental right. The GDPR is the most comprehensive data protection law in the world, and it applies to every company that is based in the EEA and/or offers its goods or services to or monitors the behavior of individuals in the EEA.
Right To Non-Discrimination Per California Consumer Privacy Act (CCPA), Businesses cannot deny goods or services, charge you a different price, or provide a different level or quality of goods or services just because you exercised your rights under the CCPA.
However, if you refuse to provide your personal information to a business or ask it to delete or stop selling your personal information, and that personal information or sale is necessary for the business to provide you with goods or services, the business may not be able to complete that transaction.
Introduction What Is Privacy by Design? Today, privacy is not only an ethical imperative, but also a basic human right. And Privacy by Design is a way of reinforcing that human right.
Privacy by Design is the concept of building privacy into everything we do. In our interconnected world, where personal information is shared freely, privacy is more important than ever.
Inherent in the concept of Privacy by Design is the feature of Privacy by Default, which means that the strictest privacy settings should apply by default to business activities and processes, without any action required from the end user.
