privacy

NIP-86 Relay Management API draft optional Relays may provide an API for performing management tasks. This is made available as a JSON-RPC-like request-response protocol over HTTP, on the same URI as the relay’s websocket. When a relay receives an HTTP(s) request with a Content-Type header of application/nostr+json+rpc to a URI supporting WebSocket upgrades, it should parse the request as a JSON document with the following fields: { "method": "<method-name>", "params": ["<array>", "<of>", "<parameters>"] } Then it should return a response in the format

NIP-69 Peer-to-peer Order events draft optional Abstract Peer-to-peer (P2P) platforms have seen an upturn in recent years, while having more and more options is positive, in the specific case of p2p, having several options contributes to the liquidity split, meaning sometimes there’s not enough assets available for trading. If we combine all these individual solutions into one big pool of orders, it will make them much more competitive compared to centralized systems, where a single authority controls the liquidity.

NIP-68 Picture-first feeds draft optional This NIP defines event kind 20 for picture-first clients. Images must be self-contained. They are hosted externally and referenced using imeta tags. The idea is for this type of event to cater to Nostr clients resembling platforms like Instagram, Flickr, Snapchat, or 9GAG, where the picture itself takes center stage in the user experience. Picture Events Picture events contain a title tag and description in the .

NIP-60 Cashu Wallet draft optional This NIP defines the operations of a cashu-based wallet. A cashu wallet is a wallet which information is stored in relays to make it accessible across applications. The purpose of this NIP is: ease-of-use: new users immediately are able to receive funds without creating accounts with other services. interoperability: users’ wallets follows them across applications. This NIP doesn’t deal with users’ receiving money from someone else, it’s just to keep state of the user’s wallet.

NIP-61: Nut Zaps A Nut Zap is a P2PK cashu token where the payment itself is the receipt. High-level flow Alice wants to nutzap 1 sat to Bob because of an event event-id-1 she liked. Alice nutzaps Bob Alice fetches event kind:10019 from Bob to see the mints Bob trusts. She mints a token at that mint (or swaps some tokens she already had in that mint) p2pk-locked to the pubkey Bob has listed in his kind:10019.

NIP-73 External Content IDs draft optional There are certain established global content identifiers such as Book ISBNs , Podcast GUIDs , and Movie ISANs that are useful to reference in nostr events so that clients can query all the events assosiated with these ids. i tags are used for referencing these external content ids, with k tags representing the external content id kind so that clients can query all the events for a specific kind.

NIP-70 Protected Events draft optional When the "-" tag is present, that means the event is “protected”. A protected event is an event that can only be published to relays by its author. This is achieved by relays ensuring that the author is authenticated before publishing their own events or by just rejecting events with ["-"] outright. The default behavior of a relay MUST be to reject any event that contains ["-"].

NIP-55 Android Signer Application draft optional This NIP describes a method for 2-way communication between an Android signer and any Nostr client on Android. The Android signer is an Android Application and the client can be a web client or an Android application. Usage for Android applications The Android signer uses Intents and Content Resolvers to communicate between applications. To be able to use the Android signer in your application you should add this to your AndroidManifest.

NIP-54 Wiki draft optional This NIP defines kind:30818 (an addressable event) for descriptions (or encyclopedia entries) of particular subjects, and it’s expected that multiple people will write articles about the exact same subjects, with either small variations or completely independent content. Articles are identified by lowercase, normalized ascii d tags. Articles { "content": "A wiki is a hypertext publication collaboratively edited and managed by its own audience.", "tags": [ ["d", "wiki"], ["title", "Wiki"], ] } d tag normalization rules Any non-letter character MUST be converted to a -.

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>", .

NIP-92 Media Attachments Media attachments (images, videos, and other files) may be added to events by including a URL in the event content, along with a matching imeta tag. imeta (“inline metadata”) tags add information about media URLs in the event’s content. Each imeta tag SHOULD match a URL in the event content. Clients may replace imeta URLs with rich previews. The imeta tag is variadic, and each entry is a space-delimited key/value pair.

NIP-49 Private Key Encryption draft optional This NIP defines a method by which clients can encrypt (and decrypt) a user’s private key with a password. Symmetric Encryption Key derivation PASSWORD = Read from the user. The password should be unicode normalized to NFKC format to ensure that the password can be entered identically on other computers/clients. LOG_N = Let the user or implementer choose one byte representing a power of 2 (e.

NIP-96 HTTP File Storage Integration draft optional Introduction This NIP defines a REST API for HTTP file storage servers intended to be used in conjunction with the nostr network. The API will enable nostr users to upload files and later reference them by url on nostr notes. The spec DOES NOT use regular nostr events through websockets for storing, requesting nor retrieving data because, for simplicity, the server will not have to learn anything about nostr relays.

NIP-64 Chess (Portable Game Notation) draft optional This NIP defines kind:64 notes representing chess games in PGN format, which can be read by humans and is also supported by most chess software. Note Content The .content of these notes is a string representing a PGN-database . Notes { "kind": 64, "content": "1. e4 *", // other fields... } { "kind": 64, "tags": [ ["alt", "Fischer vs. Spassky in Belgrade on 1992-11-04 (F/S Return Match, Round 29)"], // rest of tags.

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.

NIP-71 Video Events draft optional This specification defines video events representing a dedicated post of externally hosted content. These video events are addressable and delete-requestable per NIP-09 . Unlike a kind 1 event with a video attached, Video Events are meant to contain all additional metadata concerning the subject media and to be surfaced in video-specific clients rather than general micro-blogging clients. The thought is for events of this kind to be referenced in a Netflix, YouTube, or TikTok like nostr client where the video itself is at the center of the experience.

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.

NIP-84 Highlights draft optional This NIP defines kind:9802, a “highlight” event, to signal content a user finds valuable. Format The .content of these events is the highlighted portion of the text. .content might be empty for highlights of non-text based media (e.g. NIP-94 audio/video). References Events SHOULD tag the source of the highlight, whether nostr-native or not. a or e tags should be used for nostr events and r tags for URLs.

In the realm of Virtual Private Networks (VPNs), OpenVPN and WireGuard stand out as two prominent solutions. Each has its strengths and weaknesses, making them suitable for different use cases. In this article, we will delve into a comparative analysis of OpenVPN and WireGuard, focusing on key aspects such as security, speed, and resource usage. Security OpenVPN OpenVPN is renowned for its robust security features. It employs the OpenSSL library for encryption and supports various cryptographic algorithms.

Introduction In the age of digital transformation, the security of information has never been more critical. With the growing number of cyber threats and the increasing reliance on digital communication, cryptographic algorithms play a pivotal role in safeguarding sensitive data. One such algorithm making waves in the world of cryptography is the Kyber algorithm. Developed as part of the NIST Post-Quantum Cryptography Standardization project, Kyber represents a significant step forward in securing our digital world.

NIP-24 Extra metadata fields and tags draft optional This NIP keeps track of extra optional fields that can added to events which are not defined anywhere else but have become de facto standards and other minor implementation possibilities that do not deserve their own NIP and do not have a place in other NIPs. kind 0 These are extra fields not specified in NIP-01 that may be present in the stringified JSON of metadata events:

NIP-75 Zap Goals draft optional This NIP defines an event for creating fundraising goals. Users can contribute funds towards the goal by zapping the goal event. Nostr Event A kind:9041 event is used. The .content contains a human-readable description of the goal. The following tags are defined as REQUIRED. amount - target amount in milisats. relays - a list of relays the zaps to this goal will be sent to and tallied from.

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!

In the realm of secure communication protocols, the Noise Protocol Framework stands out as a revolutionary approach that prioritizes security, efficiency, and adaptability. This article dives deep into the Noise Protocol Framework, exploring its architecture, benefits, and its significance in enhancing the security landscape of modern digital interactions. What is Noise Protocol Framework The Noise Protocol Framework is a flexible and modular framework designed for creating cryptographic protocols that ensure secure communication over networks.

A source about FBI’s Ability to Legally Access Secure Messaging App Content and Metadata from Jan. 2021 FBI Infographic re Lawful Access to Secure Messaging Apps Data on Property of the People indicate FBI have access to some of end to end encryption message apps. In an era where digital communication has become the norm, ensuring privacy and security of online conversations has gained paramount importance. Encrypted messaging apps have risen in popularity due to their commitment to safeguarding user data.

NIP-59 Gift Wrap optional This NIP defines a protocol for encapsulating any nostr event. This makes it possible to obscure most metadata for a given event, perform collaborative signing, and more. This NIP does not define any messaging protocol. Applications of this NIP should be defined separately. This NIP relies on NIP-44 ’s versioned encryption algorithms. Overview This protocol uses three main concepts to protect the transmission of a target event: rumors, seals, and gift wraps.

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.

NIP-72 Moderated Communities (Reddit Style) draft optional The goal of this NIP is to enable public communities. It defines the replaceable event kind:34550 to define the community and the current list of moderators/administrators. Users that want to post into the community, simply tag any Nostr event with the community’s a tag. Moderators may issue an approval event kind:4550. Community Definition Kind:34550 SHOULD include any field that helps define the community and the set of moderators.

NIP-48 Proxy Tags draft optional Nostr events bridged from other protocols such as ActivityPub can link back to the source object by including a "proxy" tag, in the form: ["proxy", <id>, <protocol>] Where: <id> is the ID of the source object. The ID format varies depending on the protocol. The ID must be universally unique, regardless of the protocol. <protocol> is the name of the protocol, e.g. "activitypub". Clients may use this information to reconcile duplicated content bridged from other protocols, or to display a link to the source object.

NIP-90 Data Vending Machine draft optional This NIP defines the interaction between customers and Service Providers for performing on-demand computation. Money in, data out. Kinds This NIP reserves the range 5000-7000 for data vending machine use. Kind Description 5000-5999 Job request kinds 6000-6999 Job result 7000 Job feedback Job results always use a kind number that is 1000 higher than the job request kind. (e.g. request: kind:5001 gets a result: kind:6001).