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 (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>/.
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 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.
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.
What is End to End Encrypted Messaging Apps End-to-end encrypted messaging apps are a category of communication platforms that employ advanced encryption techniques to ensure the privacy and security of messages exchanged between users. Unlike traditional messaging services, where messages might be stored and processed on the service provider’s servers, end-to-end encryption ensures that only the sender and intended recipient can access the content of the messages.
In this system, messages are encrypted on the sender’s device and remain encrypted as they traverse the communication channel until they are decrypted on the recipient’s device.
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.
