返回 MCP 目录
public公开dns本地运行

Nostr 实现可能性

NIPs(Nostr Implementation Possibilities)是用于记录与Nostr协议兼容的中继和客户端软件可能实现的内容的标准。NIPs涵盖了多种功能,包括事件类型、消息类型、标准化标签等,旨在确保不同客户端和中继之间的互操作性。这些标准是向后兼容的,并且遵循“单一方法”原则,以避免复杂性。NIPs的制定过程包括社区反馈和共识,确保其实用性和广泛接受。所有NIPs均为公共领域,任何人都可以自由使用和贡献。

article

README

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

| kind | description | NIP | | ------------- | ------------------------------- | -------------------------------------- | | 0 | User Metadata | 01 | | 1 | Short Text Note | 10 | | 2 | Recommend Relay | 01 (deprecated) | | 3 | Follows | 02 | | 4 | Encrypted Direct Messages | 04 | | 5 | Event Deletion Request | 09 | | 6 | Repost | 18 | | 7 | Reaction | 25 | | 8 | Badge Award | 58 | | 9 | Chat Message | C7 | | 10 | Group Chat Threaded Reply | 29 (deprecated) | | 11 | Thread | 7D | | 12 | Group Thread Reply | 29 (deprecated) | | 13 | Seal | 59 | | 14 | Direct Message | 17 | | 15 | File Message | 17 | | 16 | Generic Repost | 18 | | 17 | Reaction to a website | 25 | | 20 | Picture | 68 | | 21 | Video Event | 71 | | 22 | Short-form Portrait Video Event | 71 | | 30 | internal reference | NKBIP-03 | | 31 | external web reference | NKBIP-03 | | 32 | hardcopy reference | NKBIP-03 | | 33 | prompt reference | NKBIP-03 | | 40 | Channel Creation | 28 | | 41 | Channel Metadata | 28 | | 42 | Channel Message | 28 | | 43 | Channel Hide Message | 28 | | 44 | Channel Mute User | 28 | | 62 | Request to Vanish | 62 | | 64 | Chess (PGN) | 64 | | 818 | Merge Requests | 54 | | 1018 | Poll Response | 88 | | 1021 | Bid | 15 | | 1022 | Bid confirmation | 15 | | 1040 | OpenTimestamps | 03 | | 1059 | Gift Wrap | 59 | | 1063 | File Metadata | 94 | | 1068 | Poll | 88 | | 1111 | Comment | 22 | | 1311 | Live Chat Message | 53 | | 1337 | Code Snippet | C0 | | 1617 | Patches | 34 | | 1621 | Issues | 34 | | 1622 | Git Replies (deprecated) | 34 | | 1630-1633 | Status | 34 | | 1971 | Problem Tracker | nostrocket | | 1984 | Reporting | 56 | | 1985 | Label | 32 | | 1986 | Relay reviews | | | 1987 | AI Embeddings / Vector lists | NKBIP-02 | | 2003 | Torrent | 35 | | 2004 | Torrent Comment | 35 | | 2022 | Coinjoin Pool | joinstr | | 4550 | Community Post Approval | 72 | | 5000-5999 | Job Request | 90 | | 6000-6999 | Job Result | 90 | | 7000 | Job Feedback | 90 | | 7374 | Reserved Cashu Wallet Tokens | 60 | | 7375 | Cashu Wallet Tokens | 60 | | 7376 | Cashu Wallet History | 60 | | 9000-9030 | Group Control Events | 29 | | 9041 | Zap Goal | 75 | | 9321 | Nutzap | 61 | | 9467 | Tidal login | Tidal-nostr | | 9734 | Zap Request | 57 | | 9735 | Zap | 57 | | 9802 | Highlights | 84 | | 10000 | Mute list | 51 | | 10001 | Pin list | 51 | | 10002 | Relay List Metadata | 65, 51 | | 10003 | Bookmark list | 51 | | 10004 | Communities list | 51 | | 10005 | Public chats list | 51 | | 10006 | Blocked relays list | 51 | | 10007 | Search relays list | 51 | | 10009 | User groups | 51, 29 | | 10012 | Favorite relays list | 51 | | 10013 | Private event relay list | 37 | | 10015 | Interests list | 51 | | 10019 | Nutzap Mint Recommendation | 61 | | 10020 | Media follows | 51 | | 10030 | User emoji list | 51 | | 10050 | Relay list to receive DMs | 51, 17 | | 10063 | User server list | Blossom | | 10096 | File storage server list | 96 | | 10166 | Relay Monitor Announcement | 66 | | 13194 | Wallet Info | 47 | | 17375 | Cashu Wallet Event | 60 | | 21000 | Lightning Pub RPC | Lightning.Pub | | 22242 | Client Authentication | 42 | | 23194 | Wallet Request | 47 | | 23195 | Wallet Response | 47 | | 24133 | Nostr Connect | 46 | | 24242 | Blobs stored on mediaservers | Blossom | | 27235 | HTTP Auth | 98 | | 30000 | Follow sets | 51 | | 30001 | Generic lists | 51 (deprecated) | | 30002 | Relay sets | 51 | | 30003 | Bookmark sets | 51 | | 30004 | Curation sets | 51 | | 30005 | Video sets | 51 | | 30007 | Kind mute sets | 51 | | 30008 | Profile Badges | 58 | | 30009 | Badge Definition | 58 | | 30015 | Interest sets | 51 | | 30017 | Create or update a stall | 15 | | 30018 | Create or update a product | 15 | | 30019 | Marketplace UI/UX | 15 | | 30020 | Product sold as an auction | 15 | | 30023 | Long-form Content | 23 | | 30024 | Draft Long-form Content | 23 | | 30030 | Emoji sets | 51 | | 30040 | Curated Publication Index | NKBIP-01 | | 30041 | Curated Publication Content | NKBIP-01 | | 30063 | Release artifact sets | 51 | | 30078 | Application-specific Data | 78 | | 30166 | Relay Discovery | 66 | | 30267 | App curation sets | 51 | | 30311 | Live Event | 53 | | 30315 | User Statuses | 38 | | 30388 | Slide Set | Corny Chat | | 30402 | Classified Listing | 99 | | 30403 | Draft Classified Listing | 99 | | 30617 | Repository announcements | 34 | | 30618 | Repository state announcements | 34 | | 30818 | Wiki article | 54 | | 30819 | Redirects | 54 | | 31234 | Draft Event | 37 | | 31388 | Link Set | Corny Chat | | 31890 | Feed | NUD: Custom Feeds | | 31922 | Date-Based Calendar Event | 52 | | 31923 | Time-Based Calendar Event | 52 | | 31924 | Calendar | 52 | | 31925 | Calendar Event RSVP | 52 | | 31989 | Handler recommendation | 89 | | 31990 | Handler information | 89 | | | 32267 | Software Application | | | | 34550 | Community Definition | 72 | | 38383 | Peer-to-peer Order events | 69 | | 39000-9 | Group metadata events | 29 | | 39089 | Starter packs | 51 | | 39092 | Media starter packs | 51 | | 39701 | Web bookmarks | B0 |

Message types

Client to Relay

| type | description | NIP | | ------- | --------------------------------------------------- | ----------- | | EVENT | used to publish events | 01 | | REQ | used to request events and subscribe to new updates | 01 | | CLOSE | used to stop previous subscriptions | 01 | | AUTH | used to send authentication events | 42 | | COUNT | used to request event counts | 45 |

Relay to Client

| type | description | NIP | | -------- | ------------------------------------------------------- | ----------- | | EOSE | used to notify clients all stored events have been sent | 01 | | EVENT | used to send events requested to clients | 01 | | NOTICE | used to send human-readable messages to clients | 01 | | OK | used to notify clients if an EVENT was successful | 01 | | CLOSED | used to notify clients that a REQ was ended and why | 01 | | AUTH | used to send authentication challenges | 42 | | COUNT | used to send requested event counts to clients | 45 |

Standardized Tags

| name | value | other parameters | NIP | | ----------------- | ------------------------------------ | ------------------------------- | -------------------------------------------------- | | a | coordinates to an event | relay URL | 01 | | A | root address | relay URL | 22 | | d | identifier | -- | 01 | | e | event id (hex) | relay URL, marker, pubkey (hex) | 01, 10 | | E | root event id | relay URL | 22 | | f | currency code | -- | 69 | | g | geohash | -- | 52 | | h | group id | -- | 29 | | i | external identity | proof, url hint | 35, 39, 73 | | I | root external identity | -- | 22 | | k | kind | -- | 18, 25, 72, 73 | | K | root scope | -- | 22 | | l | label, label namespace, language name| -- | 32, C0 | | L | label namespace | -- | 32 | | m | MIME type | -- | 94 | | p | pubkey (hex) | relay URL, petname | 01, 02, 22 | | P | pubkey (hex) | -- | 22, 57 | | q | event id (hex) | relay URL, pubkey (hex) | 18 | | r | a reference (URL, etc) | -- | 24, 25 | | r | relay url | marker | 65 | | s | status | -- | 69 | | t | hashtag | -- | 24, 34, 35 | | u | url | -- | 61, 98 | | x | hash | -- | 35, 56 | | y | platform | -- | 69 | | z | order number | -- | 69 | | - | -- | -- | 70 | | alt | summary | -- | 31 | | amount | millisatoshis, stringified | -- | 57 | | bolt11 | bolt11 invoice | -- | 57 | | challenge | challenge string | -- | 42 | | client | name, address | relay URL | 89 | | clone | git clone URL | -- | 34 | | content-warning | reason | -- | 36 | | delegation | pubkey, conditions, delegation token | -- | 26 | | dep | Required dependency | -- | C0 | | description | description | -- | 34, 57, 58, C0 | | emoji | shortcode, image URL | -- | 30 | | encrypted | -- | -- | 90 | | extension | File extension | -- | C0 | | expiration | unix timestamp (string) | -- | 40 | | file | full path (string) | -- | 35 | | goal | event id (hex) | relay URL | 75 | | image | image URL | dimensions in pixels | 23, 52, 58 | | imeta | inline metadata | -- | 92 | | license | License of the shared content | -- | C0 | | lnurl | bech32 encoded lnurl | -- | 57 | | location | location string | -- | 52, 99 | | name | name | -- | 34, 58, 72, C0 | | nonce | random | difficulty | 13 | | preimage | hash of bolt11 invoice | -- | 57 | | price | price | currency, frequency | 99 | | proxy | external ID | protocol | 48 | | published_at | unix timestamp (string) | -- | 23, B0 | | relay | relay url | -- | 42, 17 | | relays | relay list | -- | 57 | | repo | Reference to the origin repository | -- | C0 | | runtime | Runtime or environment specification | -- | C0 | | server | file storage server url | -- | 96 | | subject | subject | -- | 14, 17, 34 | | summary | summary | -- | 23, 52 | | thumb | badge thumbnail | dimensions in pixels | 58 | | title | title | -- | 23, B0 | | tracker | torrent tracker URL | -- | 35 | | web | webpage URL | -- | 34 | | zap | pubkey (hex), relay URL | weight | 57 |

Please update these lists when proposing new NIPs.

Criteria for acceptance of NIPs

  1. They should be fully implemented in at least two clients and one relay -- when applicable.
  2. They should make sense.
  3. They should be optional and backwards-compatible: care must be taken such that clients and relays that choose to not implement them do not stop working when interacting with the ones that choose to.
  4. There should be no more than one way of doing the same thing.
  5. Other rules will be made up when necessary.

Is this repository a centralizing factor?

To promote interoperability, we need standards that everybody can follow, and we need them to define a single way of doing each thing without ever hurting backwards-compatibility, and for that purpose there is no way around getting everybody to agree on the same thing and keep a centralized index of these standards. However the fact that such an index exists doesn't hurt the decentralization of Nostr. At any point the central index can be challenged if it is failing to fulfill the needs of the protocol and it can migrate to other places and be maintained by other people.

It can even fork into multiple versions, and then some clients would go one way, others would go another way, and some clients would adhere to both competing standards. This would hurt the simplicity, openness and interoperability of Nostr a little, but everything would still work in the short term.

There is a list of notable Nostr software developers who have commit access to this repository, but that exists mostly for practical reasons, as by the nature of the thing we're dealing with the repository owner can revoke membership and rewrite history as they want -- and if these actions are unjustified or perceived as bad or evil the community must react.

How this repository works

Standards may emerge in two ways: the first way is that someone starts doing something, then others copy it; the second way is that someone has an idea of a new standard that could benefit multiple clients and the protocol in general without breaking backwards-compatibility and the principle of having a single way of doing things, then they write that idea and submit it to this repository, other interested parties read it and give their feedback, then once most people reasonably agree we codify that in a NIP which client and relay developers that are interested in the feature can proceed to implement.

These two ways of standardizing things are supported by this repository. Although the second is preferred, an effort will be made to codify standards emerged outside this repository into NIPs that can be later referenced and easily understood and implemented by others -- but obviously as in any human system discretion may be applied when standards are considered harmful.

Breaking Changes

Breaking Changes

License

All NIPs are public domain.

Contributors

help

运行方式说明

cloud

托管运行

托管运行通常表示这个 MCP Server 由服务方环境承载,用户一般按页面提供的连接方式或授权流程接入,不需要在本地长期启动一个 MCP 进程

  1. 打开服务方连接页
  2. 完成授权或复制端点
  3. 在 MCP 客户端中连接
terminal

本地运行 / 其它方式

本地运行通常需要用户在自己的电脑或服务器上安装依赖,把 server_config 复制到 MCP 客户端,并按 env_schema 补齐环境变量、密钥或其它配置

  1. 复制 server_config
  2. 安装所需依赖
  3. 补齐环境变量后重启客户端