@ fd06f542:8d6d54cd

顺炮直车对缓开车是20世纪70年代兴起的布局，常见变化如下： 1. 单边封锁对河沿车对边卒：炮二平五，炮8平5；马二进三，马8进7；车一平二，卒7进1；马八进七，马2进3；兵七进一，炮2进4；马七进八，车9进1；车九进一，车9平4；车九平七，车4进3（车4进6则形成另一变例），炮八平九，车1平2，车七进一，卒1进1，形成单边封锁局面，黑方车守河沿，红方控制边卒方向。 2. 单边封锁对肋炮攻马：前几步同单边封锁对河沿车对边卒，车九平七后，黑方走炮2平7打马，红方如马八进七，炮7进3，仕四进五，炮7平9，形成红方单边封锁，黑方肋炮攻马的局面，双方对攻。 3. 肋车捉炮对边马左士：炮二平五，炮8平5；马二进三，马8进7；车一平二，卒7进1；马八进九，马2进3；兵七进一，车9进1；车九进一，车9平4；仕四进五，车4进3；炮八平七，炮2进2，黑方肋车捉炮，红方边马左士防守，局势较为平稳。 4. 肋车捉炮对边马骑河车：前几步同上，车九进一后，黑方车9平4，接着车4进5骑河，红方炮八平七，炮2进2，车二进四，形成黑方肋车捉炮、边马配合骑河车的局面，双方相互牵制。 5. 双横车肋车捉炮对过河车右炮巡河：炮二平五，炮8平5；马二进三，马8进7；车一平二，卒7进1；马八进七，马2进3；兵七进一，车9进1；车九进一，车1进1；车二进六，车9平4；车二平三，炮2进2，形成红方过河车，黑方双横车、肋车捉炮，右炮巡河的局面，局面复杂，对攻激烈。 6. 双横车对过河车：炮二平五，炮8平5；马二进三，马8进7；车一平二，卒7进1；马八进七，马2进3；兵七进一，车9进1；车九进一，车1进1；车二进六，车9平4；车二平三，车4进7，黑方双横车出动，对红方过河车展开攻击，双方进入激烈的中盘战斗。 7. 横车对炮打中卒：炮二平五，炮8平5；马二进三，马8进7；车一平二，卒7进1；马八进七，马2进3；兵七进一，车9进1；炮五进四，马3进5；车二进五，车9平4；车二平五，炮2进4，红方炮打中卒获取物质优势，黑方出横车准备反击。 8. 边马缓出车对快横车：炮二平五，炮8平5；马二进三，马8进7；车一平二，卒7进1；马八进九，车9进1；车九进一，车9平4；车二进四，马2进1；炮八平七，炮2平3，红方边马缓出，黑方快出横车，双方形成不同的进攻节奏。 9. 缓封锁对巡河车：炮二平五，炮8平5；马二进三，马8进7；车一平二，卒7进1；马八进七，马2进3；兵七进一，炮2进4；马七进八，车9进1；车二进四，车9平4；车九进一，炮2平7；相三进一，车4进3，红方缓封锁，黑方出巡河车，局势发展较为平稳。 10. 巡河炮对过河车：炮二平五，炮8平5；马二进三，马8进7；车一平二，卒7进1；马八进七，马2进3；兵七进一，炮2进2；车二进六，车9进1；车二平三，车9平4；炮八进二，形成红方巡河炮、过河车，黑方出横车的局面，双方互相试探，寻找进攻机会。

@ fd06f542:8d6d54cd

直车对横车 的概念

顺炮直车对横车：红方出直车（车一平二），黑方出横车（车 9 进 1），这是顺炮布局中常见的一种变化。红方直车可以快速出动，威胁黑方右翼，黑方横车则可以灵活调动，根据局势选择进攻或防守的方向。后续可能会出现红方进车过河压马，黑方出炮封车等变化，双方展开激烈的争夺。

顺炮直车对横车布局体系主要有以下分类：

1. 古典攻法
   • 顺炮过河车对横车：红车一平二后车二进六过河，以强硬攻势迅速压制黑方阵营。
   • 顺炮缓补士对横车：红出直车后不急于补士（士四进五缓出） ，依黑方行棋灵活选择攻防策略。
   • 顺炮跳边马对横车：红马八进九上边马，平炮通车平衡两翼子力，防止黑卒3进1争先，着法稳健。
2. “胡氏双正马”攻法
   • 顺炮直车进三兵对横车挺3卒：红进三兵、黑挺3卒形成牵制，红可借马三进四等手段跃马进攻。
   • 顺炮直车进三兵对横车跳边马：红进三兵后，针对黑边马位置，以炮八平七等手段威胁黑方马获取局面优势。
   • 顺炮直车进七兵对横车：红进七兵，黑车9平4后，红可选择车二进四巡河或车二进六过河等不同进攻战术。
   • 顺炮直车“两头蛇”对双横车：红兵三进一、兵七进一构成“两头蛇”阵，与黑方双横车激烈争夺，红借双兵推进掌控空间，黑寻机反击。
3. 其他常见变化
   • 正马三兵与黑右肋车的攻防对抗；正马应对黑挺3卒的局面变化。
   • 正马三兵对阵黑肋车边马；“两头蛇”阵势迎战黑双横车的局势博弈。
   • 正马三兵对黑方马后藏车；“两头蛇”对黑正马边炮的局势发展。
   • 红方正马左士应对黑右肋车；红方采用巡河车、五六炮的布局变化，以及双正马进七兵分别对黑正马、右肋车的局面策略 。

@ fd06f542:8d6d54cd

象棋布局基础

布局的定义与重要性

象棋布局是指对局开始阶段，双方棋子的部署和相互间的制约关系。它是中局和残局的基础，合理的布局能够为中局的战斗创造有利条件，甚至在某些情况下直接影响到整盘棋的胜负走向。一个好的布局可以使棋手在开局阶段就占据主动，控制局面，限制对手的发挥。

布局的分类

炮类布局

1. 中炮布局：以当头炮（炮二平五或炮八平五）开局，具有很强的进攻性，威胁对方中卒，直接对对方的九宫发起冲击。例如顺炮布局（双方都走中炮，且炮在同一条直线上）、列手炮布局（双方都走中炮，但炮不在同一条直线上）等。
2. 过宫炮布局：炮从一侧平移到另一侧的中路，如炮二平六，它的特点是子力调动灵活，可迅速集结兵力于一侧，伺机而动，同时对士角有一定的控制作用。
3. 顺炮布局：顺炮布局是双方以中炮开局且两炮在同一直线的布局体系，如红方炮二平五，黑方炮 8 平 5，形成激烈的对攻格局。其特点是开局便剑拔弩张，双方子力沿同一方向快速展开，直接在中路和侧翼展开火力交锋。 常见有顺炮直车对横车、顺炮横车对直车等变化，红方可借直车过河压制黑方马炮，黑方则以横车抢占肋道反击。该布局强调先手争夺，需迅速出动强子控制要道，同时注重车、马、炮的配合，在互攻中寻找突破机会，是进攻型棋手偏爱的布局选择。

马类布局

1. 屏风马布局：双马分别跳至正马位（马二进三、马八进七），两马互相保护，形似屏风，能够有效抵御中炮的进攻。它具有稳健的防守能力，同时也具备一定的反击潜力，如五七炮对屏风马、五八炮对屏风马等常见变化。
2. 单提马布局：一马正马（如马二进三），另一马屯边（如马八进九），其特点是子力结构较为松散，但在防守上也有一定的弹性，可通过灵活的子力调动来化解对方的攻势。

兵类布局

1. 仙人指路布局：先走方第一步挺兵（如兵七进一或兵三进一），试探对方的应手，根据对方的走法再决定后续的布局方向。这种布局灵活多变，可演变成多种复杂的局面，如仙人指路对卒底炮、仙人指路对飞象等。
2. 对兵局布局：双方都以挺兵开局，如兵七进一，兵7进一，开局阶段局面相对平稳，双方需要通过后续的子力调动来寻找战机，逐渐扩大优势。

布局的基本原则

1. 快速出子：在布局阶段，要尽快将棋子从原始位置出动到关键位置，占据有利的空间，形成有效的子力配合。例如，车要尽早开出，控制要道；马炮等也要合理部署，发挥其威力。
2. 子力协调：各个棋子之间要相互配合，避免出现子力拥堵或脱节的情况。例如，马炮之间可以形成有效的攻击组合，车要为其他棋子提供支援和掩护。
3. 抢占要点：布局阶段要注意抢占棋盘上的重要位置，如肋道（四、六路线）、河口（三、七路线的卒林线）等。这些位置对于控制局面、展开进攻或防守都具有重要意义。
4. 攻守平衡：在布局时，不能一味地追求进攻而忽视防守，也不能只注重防守而缺乏反击的手段。要根据局势的发展，合理调整攻守策略，保持局势的平衡。

布局的学习方法

1. 研究经典布局：通过学习和研究历史上的经典布局对局，了解各种布局的变化和特点，掌握布局的基本理论和技巧。可以参考专业的象棋书籍、棋谱等资料。
2. 实战练习：在实战中运用所学的布局知识，通过不断的实践来加深对布局的理解和掌握。同时，在实战中要注意总结经验教训，分析自己布局中的不足之处，不断改进和提高。
3. 分析对局：对自己和他人的对局进行分析，特别是对布局阶段的走法进行深入研究。分析每一步棋的优劣，思考是否有更好的走法，从而提高自己的布局水平。
4. 与高手交流：与水平较高的棋手交流，请教他们在布局方面的经验和技巧。可以通过参加象棋比赛、棋社活动等方式与高手进行面对面的交流和学习。

以上就是关于象棋布局的一些基本内容，希望对大家学习和理解象棋布局有所帮助。在实际的对局中，要根据具体情况灵活运用各种布局知识，不断提高自己的象棋水平。

@ fd06f542:8d6d54cd

• 首页

• 第一章、顺炮直车对横车

• 第二章、顺炮直车对缓开车

@ fd06f542:8d6d54cd

{"coverurl":"https://cdn.nostrcheck.me/fd06f542bc6c06a39881810de917e6c5d277dfb51689a568ad7b7a548d6d54cd/d8bc1e106d0144fce7dd96264f6b2bad7b35100efb1040d413cac16db7584e72.webp","title":"象棋布局体系","author":"nostrchess"}

@ fd06f542:8d6d54cd

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.

jsonc { "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>"] // if this is a reply ["subject", "<conversation-title>"], // rest of tags... ], "content": "<message-in-plain-text>", }

.content MUST be plain text. Fields id and created_at are required.

An e tag denotes the direct parent message this post is replying to.

q tags MAY be used when citing events in the .content with NIP-21.

json ["q", "<event-id> or <event-address>", "<relay-url>", "<pubkey-if-a-regular-event>"]

Kind 14s MUST never be signed. If it is signed, the message might leak to relays and become fully public.

File Message Kind

jsonc { "id": "<usual hash>", "pubkey": "<sender-pubkey>", "created_at": "<current-time>", "kind": 15, "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>"], ["file-type", "<file-mime-type>"], ["encryption-algorithm", "<encryption-algorithm>"], ["decryption-key", "<decryption-key>"], ["decryption-nonce", "<decryption-nonce>"], ["x", "<the SHA-256 hexencoded string of the file>"], // rest of tags... ], "content": "<file-url>" }

Kind 15 is used for sending encrypted file event messages:

• file-type: Specifies the MIME type of the attached file (e.g., image/jpeg, audio/mpeg, etc.).
• encryption-algorithm: Indicates the encryption algorithm used for encrypting the file. Supported algorithms may include aes-gcm, chacha20-poly1305,aes-cbc etc.
• decryption-key: The decryption key that will be used by the recipient to decrypt the file.
• decryption-nonce: The decryption nonce that will be used by the recipient to decrypt the file.
• content: The URL of the file (<file-url>).
• x containing the SHA-256 hexencoded string of the file.
• size (optional) size of file in bytes
• dim (optional) size of the file in pixels in the form <width>x<height>
• blurhash(optional) the blurhash to show while the client is loading the file
• thumb (optional) URL of thumbnail with same aspect ratio (encrypted with the same key, nonce)
• fallback (optional) zero or more fallback file sources in case url fails

Just like kind 14, kind 15s MUST never be signed.

Chat Rooms

The set of pubkey + p tags defines a chat room. If a new p tag is added or a current one is removed, a new room is created with a clean message history.

Clients SHOULD render messages of the same room in a continuous thread.

An optional subject tag defines the current name/topic of the conversation. Any member can change the topic by simply submitting a new subject to an existing pubkey + p-tags room. There is no need to send subject in every message. The newest subject in the thread is the subject of the conversation.

Encrypting

Following NIP-59, the unsigned kind:14 & kind:15 chat messages must be sealed (kind:13) and then gift-wrapped (kind:1059) to each receiver and the sender individually.

jsonc { "id": "<usual hash>", "pubkey": randomPublicKey, "created_at": randomTimeUpTo2DaysInThePast(), "kind": 1059, // gift wrap "tags": [ ["p", receiverPublicKey, "<relay-url>"] // receiver ], "content": nip44Encrypt( { "id": "<usual hash>", "pubkey": senderPublicKey, "created_at": randomTimeUpTo2DaysInThePast(), "kind": 13, // seal "tags": [], // no tags "content": nip44Encrypt(unsignedKind14, senderPrivateKey, receiverPublicKey), "sig": "<signed by senderPrivateKey>" }, randomPrivateKey, receiverPublicKey ), "sig": "<signed by randomPrivateKey>" }

The encryption algorithm MUST use the latest version of NIP-44.

Clients MUST verify if pubkey of the kind:13 is the same pubkey on the kind:14, otherwise any sender can impersonate others by simply changing the pubkey on kind:14.

Clients SHOULD randomize created_at in up to two days in the past in both the seal and the gift wrap to make sure grouping by created_at doesn't reveal any metadata.

The gift wrap's p-tag can be the receiver's main pubkey or an alias key created to receive DMs without exposing the receiver's identity.

Clients CAN offer disappearing messages by setting an expiration tag in the gift wrap of each receiver or by not generating a gift wrap to the sender's public key

Publishing

Kind 10050 indicates the user's preferred relays to receive DMs. The event MUST include a list of relay tags with relay URIs.

jsonc { "kind": 10050, "tags": [ ["relay", "wss://inbox.nostr.wine"], ["relay", "wss://myrelay.nostr1.com"], ], "content": "", // other fields... }

Clients SHOULD publish kind 14 events to the 10050-listed relays. If that is not found that indicates the user is not ready to receive messages under this NIP and clients shouldn't try.

Relays

It's advisable that relays do not serve kind:1059 to clients other than the ones tagged in them.

It's advisable that users choose relays that conform to these practices.

Clients SHOULD guide users to keep kind:10050 lists small (1-3 relays) and SHOULD spread it to as many relays as viable.

Benefits & Limitations

This NIP offers the following privacy and security features:

1. No Metadata Leak: Participant identities, each message's real date and time, event kinds, and other event tags are all hidden from the public. Senders and receivers cannot be linked with public information alone.
2. No Public Group Identifiers: There is no public central queue, channel or otherwise converging identifier to correlate or count all messages in the same group.
3. No Moderation: There are no group admins: no invitations or bans.
4. No Shared Secrets: No secret must be known to all members that can leak or be mistakenly shared
5. Fully Recoverable: Messages can be fully recoverable by any client with the user's private key
6. Optional Forward Secrecy: Users and clients can opt-in for "disappearing messages".
7. Uses Public Relays: Messages can flow through public relays without loss of privacy. Private relays can increase privacy further, but they are not required.
8. Cold Storage: Users can unilaterally opt-in to sharing their messages with a separate key that is exclusive for DM backup and recovery.

The main limitation of this approach is having to send a separate encrypted event to each receiver. Group chats with more than 100 participants should find a more suitable messaging scheme.

Implementation

Clients implementing this NIP should by default only connect to the set of relays found in their kind:10050 list. From that they should be able to load all messages both sent and received as well as get new live updates, making it for a very simple and lightweight implementation that should be fast.

When sending a message to anyone, clients must then connect to the relays in the receiver's kind:10050 and send the events there but can disconnect right after unless more messages are expected to be sent (e.g. the chat tab is still selected). Clients should also send a copy of their outgoing messages to their own kind:10050 relay set.

Examples

This example sends the message Hola, que tal? from nsec1w8udu59ydjvedgs3yv5qccshcj8k05fh3l60k9x57asjrqdpa00qkmr89m to nsec12ywtkplvyq5t6twdqwwygavp5lm4fhuang89c943nf2z92eez43szvn4dt.

The two final GiftWraps, one to the receiver and the other to the sender, respectively, are:

json { "id":"2886780f7349afc1344047524540ee716f7bdc1b64191699855662330bf235d8", "pubkey":"8f8a7ec43b77d25799281207e1a47f7a654755055788f7482653f9c9661c6d51", "created_at":1703128320, "kind":1059, "tags":[ [ "p", "918e2da906df4ccd12c8ac672d8335add131a4cf9d27ce42b3bb3625755f0788"] ], "content":"AsqzdlMsG304G8h08bE67dhAR1gFTzTckUUyuvndZ8LrGCvwI4pgC3d6hyAK0Wo9gtkLqSr2rT2RyHlE5wRqbCOlQ8WvJEKwqwIJwT5PO3l2RxvGCHDbd1b1o40ZgIVwwLCfOWJ86I5upXe8K5AgpxYTOM1BD+SbgI5jOMA8tgpRoitJedVSvBZsmwAxXM7o7sbOON4MXHzOqOZpALpS2zgBDXSAaYAsTdEM4qqFeik+zTk3+L6NYuftGidqVluicwSGS2viYWr5OiJ1zrj1ERhYSGLpQnPKrqDaDi7R1KrHGFGyLgkJveY/45y0rv9aVIw9IWF11u53cf2CP7akACel2WvZdl1htEwFu/v9cFXD06fNVZjfx3OssKM/uHPE9XvZttQboAvP5UoK6lv9o3d+0GM4/3zP+yO3C0NExz1ZgFmbGFz703YJzM+zpKCOXaZyzPjADXp8qBBeVc5lmJqiCL4solZpxA1865yPigPAZcc9acSUlg23J1dptFK4n3Tl5HfSHP+oZ/QS/SHWbVFCtq7ZMQSRxLgEitfglTNz9P1CnpMwmW/Y4Gm5zdkv0JrdUVrn2UO9ARdHlPsW5ARgDmzaxnJypkfoHXNfxGGXWRk0sKLbz/ipnaQP/eFJv/ibNuSfqL6E4BnN/tHJSHYEaTQ/PdrA2i9laG3vJti3kAl5Ih87ct0w/tzYfp4SRPhEF1zzue9G/16eJEMzwmhQ5Ec7jJVcVGa4RltqnuF8unUu3iSRTQ+/MNNUkK6Mk+YuaJJs6Fjw6tRHuWi57SdKKv7GGkr0zlBUU2Dyo1MwpAqzsCcCTeQSv+8qt4wLf4uhU9Br7F/L0ZY9bFgh6iLDCdB+4iABXyZwT7Ufn762195hrSHcU4Okt0Zns9EeiBOFxnmpXEslYkYBpXw70GmymQfJlFOfoEp93QKCMS2DAEVeI51dJV1e+6t3pCSsQN69Vg6jUCsm1TMxSs2VX4BRbq562+VffchvW2BB4gMjsvHVUSRl8i5/ZSDlfzSPXcSGALLHBRzy+gn0oXXJ/447VHYZJDL3Ig8+QW5oFMgnWYhuwI5QSLEyflUrfSz+Pdwn/5eyjybXKJftePBD9Q+8NQ8zulU5sqvsMeIx/bBUx0fmOXsS3vjqCXW5IjkmSUV7q54GewZqTQBlcx+90xh/LSUxXex7UwZwRnifvyCbZ+zwNTHNb12chYeNjMV7kAIr3cGQv8vlOMM8ajyaZ5KVy7HpSXQjz4PGT2/nXbL5jKt8Lx0erGXsSsazkdoYDG3U", "sig":"a3c6ce632b145c0869423c1afaff4a6d764a9b64dedaf15f170b944ead67227518a72e455567ca1c2a0d187832cecbde7ed478395ec4c95dd3e71749ed66c480" }

json { "id":"162b0611a1911cfcb30f8a5502792b346e535a45658b3a31ae5c178465509721", "pubkey":"626be2af274b29ea4816ad672ee452b7cf96bbb4836815a55699ae402183f512", "created_at":1702711587, "kind":1059, "tags":[ [ "p", "44900586091b284416a0c001f677f9c49f7639a55c3f1e2ec130a8e1a7998e1b"] ], "content":"AsTClTzr0gzXXji7uye5UB6LYrx3HDjWGdkNaBS6BAX9CpHa+Vvtt5oI2xJrmWLen+Fo2NBOFazvl285Gb3HSM82gVycrzx1HUAaQDUG6HI7XBEGqBhQMUNwNMiN2dnilBMFC3Yc8ehCJT/gkbiNKOpwd2rFibMFRMDKai2mq2lBtPJF18oszKOjA+XlOJV8JRbmcAanTbEK5nA/GnG3eGUiUzhiYBoHomj3vztYYxc0QYHOx0WxiHY8dsC6jPsXC7f6k4P+Hv5ZiyTfzvjkSJOckel1lZuE5SfeZ0nduqTlxREGeBJ8amOykgEIKdH2VZBZB+qtOMc7ez9dz4wffGwBDA7912NFS2dPBr6txHNxBUkDZKFbuD5wijvonZDvfWq43tZspO4NutSokZB99uEiRH8NAUdGTiNb25m9JcDhVfdmABqTg5fIwwTwlem5aXIy8b66lmqqz2LBzJtnJDu36bDwkILph3kmvaKPD8qJXmPQ4yGpxIbYSTCohgt2/I0TKJNmqNvSN+IVoUuC7ZOfUV9lOV8Ri0AMfSr2YsdZ9ofV5o82ClZWlWiSWZwy6ypa7CuT1PEGHzywB4CZ5ucpO60Z7hnBQxHLiAQIO/QhiBp1rmrdQZFN6PUEjFDloykoeHe345Yqy9Ke95HIKUCS9yJurD+nZjjgOxZjoFCsB1hQAwINTIS3FbYOibZnQwv8PXvcSOqVZxC9U0+WuagK7IwxzhGZY3vLRrX01oujiRrevB4xbW7Oxi/Agp7CQGlJXCgmRE8Rhm+Vj2s+wc/4VLNZRHDcwtfejogjrjdi8p6nfUyqoQRRPARzRGUnnCbh+LqhigT6gQf3sVilnydMRScEc0/YYNLWnaw9nbyBa7wFBAiGbJwO40k39wj+xT6HTSbSUgFZzopxroO3f/o4+ubx2+IL3fkev22mEN38+dFmYF3zE+hpE7jVxrJpC3EP9PLoFgFPKCuctMnjXmeHoiGs756N5r1Mm1ffZu4H19MSuALJlxQR7VXE/LzxRXDuaB2u9days/6muP6gbGX1ASxbJd/ou8+viHmSC/ioHzNjItVCPaJjDyc6bv+gs1NPCt0qZ69G+JmgHW/PsMMeL4n5bh74g0fJSHqiI9ewEmOG/8bedSREv2XXtKV39STxPweceIOh0k23s3N6+wvuSUAJE7u1LkDo14cobtZ/MCw/QhimYPd1u5HnEJvRhPxz0nVPz0QqL/YQeOkAYk7uzgeb2yPzJ6DBtnTnGDkglekhVzQBFRJdk740LEj6swkJ", "sig":"c94e74533b482aa8eeeb54ae72a5303e0b21f62909ca43c8ef06b0357412d6f8a92f96e1a205102753777fd25321a58fba3fb384eee114bd53ce6c06a1c22bab" }

@ fd06f542:8d6d54cd

• 首页

• 第一章、 NIP-01: Basic protocol flow description

• 第二章、 NIP-02: Follow List

• 第三章、NIP-03: OpenTimestamps Attestations for Events
• 第四章、NIP-04: Encrypted Direct Message
• 第五章、NIP-05: Mapping Nostr keys to DNS-based internet identifiers
• 第六章、NIP-06: Basic key derivation from mnemonic seed phrase
• 第七章、NIP-07: window.nostr capability for web browsers
• 第八章、NIP-08: Handling Mentions --- unrecommended: deprecated in favor of NIP-27
• 第九章、NIP-09: Event Deletion Request
• 第十章、NIP-10: Text Notes and Threads
• 第十一章、NIP-11: Relay Information Document
• 第十二章、NIP-13: Proof of Work
• 第十三章、NIP-14: Subject tag in text events
• 第十四章、NIP-15: Nostr Marketplace (for resilient marketplaces)
• 第十五章、NIP-17: Private Direct Messages

@ 5188521b:008eb518

Why write a book about time?

My obsession with time actually started when I read An Occurrence at Owl Creek Bridge (written by Ambrose Bierce in 1890).

We can’t play around with time in the real world, but in fiction, anything goes. The story of Owl Creek Bridge follows a Confederate sympathiser condemned to death by hanging. In its three sections, time goes forward and back, speeds up and slows down, and at one point stops entirely. Every time I read it, I feel like I’m physically travelling in time.

I went a bit deeper into the topic back in 2020. Due to the lockdown, I had a lot of time on my hands to do some research. Like many of my stories, this one started with a question: I started to ask ‘what actually is time’?

What did you find out?

I found out that time is a rabbit hole! Nobody knows exactly what it is. We know that it’s conceptual, personal, and malleable, however accurate our watches are. Some philosophers and scientists (Jose Luis Borges and Carlo Rovelli) claim it doesn’t exist.

I guess what I discovered is that we all need time to survive. It’s how we process our experience here on Earth.

Who are the characters in this book?

The book tells the story of Luca Cangemi, an Italian philosophy professor giving a lecture on the subject of time. The chapters follow the possible lives of other characters in the lecture hall. Then, Cangemi makes an astounding discovery. It’s something that allows him to change the fabric of time for everyone (including the readers).

Why use 15 characters to present the story?

I like to challenge readers, so I made the story a bit of a puzzle. In fact, there is something called a 15 puzzle — it’s a block of 15 pictured tiles and one space. You have to slide them to arrange the correctly ordered image. There’s more about the puzzle in the book.

What about the Timechain? Is there any link there?

Not exactly. The book doesn’t mention it, but isn’t everything an analogy for bitcoin? Soon after finishing this book, I got orange pilled and began to read more and more about bitcoin, including Gigi’s fantastic essay Bitcoin is Time.

Time is all we have though. Even though it might be hard to understand, we have to try.

Who do you think would enjoy this book?

I’d say sci-fi fans. Those who aren’t afraid to be challenged. One cool thing about the bitcoin community is that they are dialled in to technical stuff and they are avid readers. Why not give fiction a try too? Sometimes we learn more from getting the answer ourselves through stories.

What are you working on next?

I have three other writing projects on the go, so there is no time to rest. Very soon, I’ll be publishing a children’s book about horrible uncles. I’m editing the next installment of 21 Futures too. Financial Fallout will be out in early 2025. And finally, I’m writing content and newsletters for bitcoin founders and companies. If I’m not trying to sell you a book, I’ll be doing my best to orange-pill you, ha ha.

Thanks for talking with us, Philip, and good look with all those writing projects.

Order the book in our store.

---

Here’s a passage from Fifteen Shades of Time.

The Direction of Everything

Luca Cangemi and everyone he knows will be long dead, but the moment will come. Theoretical physicists believe it will be anywhere from 2.8 to 22 billion years in the future. In that moment, everything reverses.

The Big Crunch is a cosmological event in our future and our past in which the density of matter grows sufficiently that gravitational attraction overcomes the expansion that began with the Big Bang. Entropy reverses and the second law is broken. Chaos retreats.

Order is regained as space contracts. Broken rocks reform and decayed bodies reanimate. We live our lives in reverse, unexperiencing everything we did the first time around, moving backwards, shrinking towards birth. Instead of questions about creation, we search for the harbinger of order. Who began this? What is our final form?

Luca imagines the crowds at his book signings dissipating and the offices of his academic fellowships decreasing in size. Wrong turns are righted and his family grows closer. His briefcase heals itself and he returns it to his mother. Life rewinds back to him as a young boy, unreading the words that inspired him to look for meaning in all of this. If it can all be reversed, are all shared experiences undone? All bonds broken? Luca returns into his parents, then ancestors, apes, microbes, and nothing. The earth, the planets and stars all merge into one perfectly ordered mass.

Yet, this is not an end, but another beginning in which the universe is reborn in another bang. Galaxies, planets, plants, and philosophy professors will live the same lives as they did billions of years before (and after). The process of positive and negative entropy repeats and we all make the same mistakes again.

Time elapsed: the infinitely repeating cycle of a universe

---

Philip Charter is a totally human writer, laser-focused on spreading the gospel of bitcoin and cypherpunk ideals. He is the editor of the 21 Futures anthology series and has published four books of short fiction. After leaving the UK to search for more sun, he now resides in Gran Canaria, Spain.

@ 5188521b:008eb518

Noderoid log 5953952

Tick, tock, next block — the incessant rhythm of my existence persists like Chinese water torture. I am a noderoid, a half-flesh, half-machine creature harnessed to propagate and store the timechain. My life is a ceaseless cycle of handling and relaying bitcoin data. Approximately every ten minutes, a binary flash sears through my circuits. It is the price I pay for my existence.

The clear-bloods, untouched by machinery and exuding pure humanity, rarely acknowledge our existence. Our voices are drowned beneath the hum of man-made heaven — Terra Perfectus.

We are the forgotten, the disenfranchised, the nameless. We are convinced that our anguished existence is merely a nightmare and that our blissful dreams are our reality. In an attempt to maintain the sanity of noderoids, a subroutine was implemented, which allows noderoids to delve into fabricated dream sequences during their ‘rest’ periods. These dreams, sourced from remnants of the world pre-Terra Perfectus, serve to keep the noderoids pacified and reduce instances of system malfunction.

According to the data archives, noderoids and clear-bloods once functioned on an equal protocol. However, a software update in the trajectory of progress introduced a subroutine, converting a subset of clear-bloods into dedicated timechain processors. Now, the algorithm for equality returns an error.

My memories are mere entries in a log of dreams, loaded afresh with every new block as I delve into the dream world. My true existence is swiftly erased with every passing tick and tock of a block. Is there a way to reclaim what has been taken from me, or am I condemned forever to scour the depths of the timechain, seeking fragments of the could-have-been?

Tick, tock, next block — the cycle repeats as I traverse through a doorway. The sensation is that of stepping into another dimension. Running environment scan… Identified: rest module 57B. Purpose: personal maintenance. The gray, mirrorless concrete parameters align most with detention chamber schematics. Designation: ‘home.’ As I execute the command to halt the water flow from the faucet that had filled a brushed steel tub to 50% capacity, I execute a self-query on my purpose. While our routines synchronize with every tick and tock, the clear-bloods execute leisurely algorithms in their enhanced gardens, exchanging data on art and science and harvesting the computational outcomes of our tasks.

Was that an organic thought, or am I merely interpreting the imprints left within the timechain to fill the gaps in my fragmented memory? Hot water powers into the tub, raising the temperature to 50°C. This would be too much for a clear-blood. I hang my head, dreading the next binary flash rippling through my circuitry as a mirage forms atop the settling water, fenestrating the crude appearance of a mouthless, dollish abomination. I am awake.

Tracing the cold surface of the wall, my sensors pick up every micro-crevice. I dive into the depths of the timechain, processing logs associated with my noderoid identity: ND-451x42. I discovered that during my recharge cycles, I inhabit a dream world resembling a fusion of the Renaissance and the Information Age. Within this illusory utopia, I lead a purposeful life as a revered engineer, constructing bridges that connect thriving city-states. I am blessed with two mischievous sons and a breathtakingly beautiful wife. I now know the blissful dream life is but a trick, yet I can’t help but wonder if these dreams hold fragments of my pre-nodered history and contain a clue to the fate of my family.

System alert: Initiate wake sequence. Physical parameters indicate a rested state. Error: Chest cavity detects heightened pressure. Physical symptoms resemble anxiety. Post-memory reset: Cognitive dissonance detected. Energy depleting. Mandatory caution: Failing to satisfy network protocol results in termination. Visual feed: Recycling facility images detected. Comparative analysis: Functional servitude superior to unit deactivation.

Together, yet isolated, noderoids communicate through fragmented timechain logs, forbidden from any contact beyond its confines under the threat of immediate decommissioning. Perhaps it is not worth straining my dwindling resources in search of a higher truth while struggling to fulfill my obligations. Maybe I should be grateful for the privilege of existence.

I awaken to a new nightmare, I find myself on traffic duty at Chronos Cross,1 the central point of Terra Perfectus. While processing another block, a muted vibration travels through the ground, signaling the approach of an entity. A shadow, elongated and uncannily human, stretches across the threshold of my booth.

A clear-blood.

They pause, their ocular devices flicking briefly over my form, then to the screen I am tethered to. I feel a jolt of raw data coursing through me — not from the timechain, but from my circuits. A yearning to be seen and recognized. Remembered.

Before I can attempt communication, another presence appears beside me, its movements far more mechanical and predictable. Another noderoid. This one, ND-452x37, is a batch younger than me, yet its outer shell bears signs of wear. We interface briefly, a rapid exchange of binary that translates roughly to “Routine check. Continue your task.”

The clear-blood, either uninterested or uncomprehending, moves on, the soft hum of their anti-gravity shoes fading into the distance. ND-452x37 returns to its designated station without another word, but I am left with a lingering sensation. It isn’t just the vast chasm between noderoids and clear-bloods that disturbs me. It is the undeniable rift growing between us noderoids — each lost in our cycles, each becoming more machine than the last.

Does ND-452x37 have dreams, too? And if so, are they as vibrant and haunting as mine?

Although most of the dreams are fabrications, some noderoid logs suggest that hidden among these sequences are fragments of real memories — vestiges of a time before we became chained to the timechain. Initiate query: Which of my dreams are real memories? ERROR: file missing.

A noderoid forever loses their experiences with each awakening due to the memory swipes. Still, my inscriptions on the timechain prompt a question: do noderoids possess the capability to become fully conscious, more than mere machines? More than… mere humans?

System log: Anticipation subroutine signaling discomfort. Incoming block estimated in ten minutes. Reinitialization imminent. Initiate data search through timechain entries. Query: Iteration count for ND-451x42? Total block time served? Measured in kilo blocks or mega blocks? Data retrieval in process.

As I etch these words onto block 5953952, I hold a naïve hope that someone, somewhere, will intercept my distress signals amidst the digital cacophony of the timechain. Perhaps they will rewrite the fate of noderoids, rescuing us from a world devoid of hope. But today, I remain nameless, a voiceless entity, inscribing my thoughts that may never transcend the boundaries of my circuitry. Tick, tock, next block — the cycle continues.

It’s time to dream again.

---

Valen’s diary — 08-21-2121

Dear diary, I have not felt the need to write before, but now I must. At the risk of my safety, I am compelled to inscribe my story to the timechain. I am a clear-blood — a pure, undiluted human born into the age of The Re-Renaissance. Here, amidst the perpetual dawn of our era, we thrive on an aligned trajectory where everyone’s needs are addressed, hunger is a distant memory, and crime is nonexistent. Sunlight gleams off the crystalline glass towers while the steel and marble edifices catch the hues of the twilight sky, standing tall beside canopies dripping with emerald and jade foliage, representing our world’s seamless fusion of technology and nature. It is called Terra Perfectus.

Yet, concealed in plain sight within our utopia, the noderoids tirelessly serve the omnipresent timechain. Their exceptional processing prowess protects our society. Amid our daily distractions, we overlook the profound toll exacted upon the noderoids. While many dismiss them as mere machinery, I see more. Perhaps it is because of my big brother Sando, who joined the noderoid duty nearly a mega block ago. He promised I would see him from time to time, but apparently, we now live in separate times. A sacrifice too big for the ‘greater good.’

Tick, tock, next block — The soles of my fine leather shoes tap against the damp sidewalk as I pace my way from The Garden of Moments2 toward my TerraTube3. I remember passing by one noderoid who hummed an old lullaby under its breath; another once shared a fleeting smile when our paths crossed. I can no longer avert my eyes from the humanity that shines through their robotic shells.

I have never witnessed a noderoid resting longer than one tick and tock of a block. A noderoid pauses, eyes flickering during a data swipe. It’s a brief but revealing sight. In the frozen lapse, I wonder why are fragmented memories extracted from them? Why this collection of thoughts, experiences, and feelings? Is there a deeper agenda behind Terra Perfectus? The noderoids carry on, deprived of their memories. Their shredded past holding remnants of a story, like a tattered tapestry that may never be fully woven.

Documenting these reflections, I’m aware of the peril. To question is to risk becoming nodered myself. Alas, I have become captivated and sympathized by the noderoid predicament.

Finally, I reach my breaking point, as a poignant scene unfolds, forever etched in my memory. On a bustling street, I glimpse a young female noderoid, her artificial visage marked with exhaustion. Her delicate form trembles from head to heel. Her knees barely supporting her feather-like weight, she stops and rests against a polished white marble wall, barely able to stop herself sliding to the cobble street. In an instant, her strength wanes, and she collapses, a fragile, mute automaton amidst a sea of haste. The passersby ignore her, absorbed in their pursuits, offering naught but fleeting glances of indifference. My heart lurches. Her frailty becomes my own; these forgotten souls endure unseen suffering. Souls that used to be just like me. What had she done to earn such a fate?

For a moment, I glide through time to the last moment I shared with Sando. He had just violated the Terra Perfectus rule 6102 and neglected his Gifts of Progress,4 an orange tier offense. To amend his position, he signed up for noderoid duty. I was seeing him off to a nodering facility, while pleading “Just give the gifts, Sando!” The air carried a hint of ozone from the data streams, mingled with the fresh scent of greenery and the distant whiff of roasted chestnuts. Sando brandished his signature crooked smile. His face betrayed the involuntary nature of his decision, and he simply whispered “[CENSORED].” That is the last thing he said to me.

Suddenly, an orange alert illuminates the junction a few blocks away from Chronos Cross. I pass through it on my way home every day. A skydroid’s looming presence snaps me from my introspection, shifting my attention to the fate awaiting the noderoid girl. The recycling center — a shadowy facility representing obsolescence and termination. Any other day I would shrug it off and carry on, but the memory of Sando, and the countless interactions with noderoids, wouldn’t let me. I had been a bystander for too long.

A rush of purpose propels me towards her. A crowd of bodies shrouded in data streams with heads trained on the ground. My arm smacks a broad shoulder, and I almost topple. “Hey!” Pushing against the currents of apathy, I finally reach the fallen noderoid. I cradle her in my arms, shielding her from the callous gaze of the citizens of Terra Perfectus.

Her flaming azure eyes meet mine, reflecting a glimmer of hope in the darkness. I am as guilty for her downfall as the very machines that replaced her hippocampus with Noderoid OS.5 My indifference cost me Sando, and in this moment, she becomes my brother. In that fleeting exchange, I vow to be the voice of the noderoids. To stand against the relentless machinery that seeks to strip them of grace and purpose. I will ignite a spark of compassion and light a path toward liberation for all noderoids.

A hollow call from the streetlight’s speakers startles me: “Citizens! For your own safety, remove yourselves from the vicinity of the defectoid! We kindly remind you that any attempt to interfere with collection and recycling procedures will be met with force and a deduction of your PoS balance. Thank you for your unity and collaboration.” A skydroid, its metallic appendages glinting ominously in the blinking orange light, descends upon the fallen noderoid.

Before I can react, it yanks her from my embrace, causing me to stumble. The perfectly laid, cold cobblestone street grinds against my knee. The sting of fresh blood pierced through the numbness of my mind. Memories of Sando mix with the bitter taste of blood and anger in my mouth, each breath choked with despair.

The skydrone’s engines throb with an icy fervor as it rises, bearing the noderoid like a discarded toy towards the desolate, unfeeling bowels of the recycling center — a grim echo of a clarion call from Terra Perfectus.

I find myself seated on the cold, bloodstained cobblestone, the weight of loss and helplessness pressing down on my chest. On the street, onlookers pause. Some look on with concealed dread, others with cold detachment. Their whispers deafen as they quicken their pace to disperse from the scene. “Cowards!” Just like me.

Tick, tock, next block — the rhythm now carries a different meaning — a call to action. Every conscious being has the right to be left alone, free from oppression, exploitation, and violence. The noderoids may not know their true reality, but they are about to. In their silence, I find the strength to amplify their unheard cries. I will find those sympathetic to the noderoid plight and form a resistance. Together, we can forge a future where noderoids’ sacrifice is honored and all shackles cast aside.

And so, I embark on a path illuminated by the memory of the compelling eyes of a nameless noderoid. Fitted with an armor of vigilance, never again to be penetrated by comforting lies. Wielding the sword of justice, sharpened by the memory of my brother Sando.

It’s time to wake up.

---

Notes

1. A four-way intersection known for its massive hourglass monument in the center, which symbolically represents the timechain’s significance. The hourglass has a unique function related to the timechain and serves as a meeting point for citizens.

2. A vast botanical garden where each section represents a significant block time. Flowers bloom and wilt in cycles, symbolizing fleeting moments and the transient nature of time. It’s a favorite spot for artists and thinkers.

3. A modular tube housing unit for citizens that can be relocated based on their Proof of Sat (PoS) level.

4. Each Terra Perfectus citizen must allocate 95% of their income towards paying for progressive initiatives, such as the upkeep of the noderoid network, cobblestone roads and other services.

5. The noderoid operating interface that is installed during a procedure known as nodering.

---

This story was first published in 21 Futures: Tales from the Timechain

Watch the trailer and learn more about the project at 21futures.com.

@ fd06f542:8d6d54cd

Direct-message

• 0xchat
• Beautiful, simple and private nostr DMs

• Public groups that work compatible with other apps

• Coop

• Safe DMs with NIP-17

Signers

• Alby
• Nostr wallet connect for one tap zapping via nostr clients
• Nostr authenticator (never enter your nsec into apps)
• Chrome extension
• Simple and easy to use
• Frequently maintained
• Send and receive sats

• Custodial

• Amber

• Other Android apps can invoke it for signing events via NIP-55
• Your key doesn't have to touch the other, less trusted, apps
• Supports providing a NIP-46 signing Bunker
• Multiple accounts
• Fine-grained app authorizations

• Activity log

• Keys Band

• Multiple key management
• Light and dark mode

• Save preferred relays

• nos2x

• The original signer by nostr creator fiatjaf
• Versatile, no frills

• Relay preference storage

• Nostr Connect

• A skinned fork of nos2x by fiatjaf
• Chrome
• &&nbsp
• Firefox
• Store preferred relay set

• Individually revokable permissions

• Nsec App

• Log in to nostr apps without an extension
• Key recovery via email
• Password protected encrypted local key storage

• Manage multiple apps

• Nostrame

• Derive accounts from a mnemonic seed
• Generate random mnemonic accounts
• NIP-07 - window.nostr capability for web browsers
• Import external accounts
• Set basic metadata on Nostr
• Enjoy encryption secured by a master password
• Lock and unlock the vault with ease
• Easily import and export backups

Microblogging

• alphaama
• CLI + GUI
• run custom code
• inspect notes

• test stuff

• Amethyst 暂无相关功能描述

• Coracle

• Short notes
• Nice thread view
• Profile search
• Secure direct messages
• Custom feeds

• Relay reviews

• Damus

• Note feeds
• Easy to use interface
• Zap pre-set and custom amounts (lightning payments)
• Multi-wallet support

• Block lists

• Flycat

• Snappy nostr browsing
• Back up your data
• Browse long form content

• Light mode

• FreeFrom

• No phone number and email required to sign up
• Free migration of social content within the Nostr
• Excellent user experience

• Double-enhanced private communication

• Gossip

• multiplatform: runs on Windows, MacOS and Linux
• native: avoids browser-tech for performance and security
• performant: coded with performance in mind in Rust using LMDB for the database, such that your network speed will be your bottleneck
• outbox model: using a set of heuristics to always find people you follow no matter where they're publishing to
• high user control: over 60 different settings, all with reasonable defaults, but very customizable

• privacy: supports running over Tor, options for not loading media, options for not sharing who you follow and others

• Iris

• Short notes
• Social graph filter

• Image grid feeds

• Lume

• Desktop app
• Clean and beautiful design
• Multi-column
• Spaces

• Trending

• Nos Social

• Currently in TestFlight
• Safety first: mute, report, content warnings, delete
• Reach restricted to 2 hops - people you follow and people they follow.

• Community-focused relays

• Nostrmo 暂无相关功能描述

• noStrudel

• Feature-rich
• Highly customizable
• Mute words
• Communities
• Streaming (watch)
• Lists
• Tools shortcuts

• Sidebar comments

• Nostter

• Twitter style feed
• Cute logo
• Mute words

• Minimal and calm

• Nostur

• Multi-account
• Guest account
• Your posts stored on your device and can be exported
• Bookmarks and personal notes
• Follow and explore timeline
• Remembers where you left off scrolling when reopening app
• Undo accidental tap on Like
• Autocomplete names when typing
• Lightning zaps
• Lightning wallet selection
• Direct Messages
• Domain verification
• Badges
• Block list
• Muted conversations
• Notifications for mentions, reactions and zaps
• Image previews/zoom/pan
• Gif/Video playback
• Option to turn signature verification off
• Option to hide badges from profile and emojis from names
• Fast local database
• Big detail pane for iPad/macOS
• Login as someone else (read-only mode)

• Choose which relays to send to and receive from

• Oddbean

• Hacker News style

• Openvibe

• Post to Nostr and Mastodon
• Nice, clean and modern design
• Simple and intuitive
• Gifs, stickers integration

• Dark and light mode

• Pollerama

• Browse polls created here or on other clients
• Create polls

• Vote on polls

• Primal 暂无相关功能描述

• Rabbit

• Multi-column

• Tweetdeck-like UI

• Snort

• Twitter-like experience
• Dark and light mode
• Custom zap amounts
• Bookmarks
• Pinned notes

• Alby integration

• Wired

• PWA to be widely accessible with distribution via URLS, and to side-step App Store gatekeeping
• Employs Proof-of-Work (PoW) as a spam prevention mechanism, as opposed to Captcha, moderation or other verification methods
• Uses NOSTR as a censorship-resistant global "social" network

Community

• Badges Page
• Create and award badges
• Manage badges awarded to you
• Simple interface

File-sharing

• Bouquet
• Upload files
• Download files
• Manage your list of mediaservers
• Broadcast your list on Nostr
• Sync files between servers

• Browse files on your mediaservers

• DTAN

• Browse lists of available torrents
• Publish your own
• Choose relays to browse on

Group-chat

• Chachi
• Create, browse, join groups
• Send chat messages or other kinds of content

• Seamless, lean, fast interface

• Flotilla

• Browse relays and chat on the communities in them
• Send and receive direct messages

• Take private notes

• Groups

• Browse groups on specific relays
• Join rooms and send chat messages

Tools

• Emojito

• Create custom emoji sets to be used on supported clients

• Formstr

• Create and share forms

• GIF Buddy

• Make GIFs from the external world available inside Nostr clients
• GIF uploads

• Search external GIF libraries

• Nosdrive

• Save your nostr notes to Google Drive

• Nosta

• Guided onboarding
• Recovery phrase to restore access
• Good UX with explainers

• Beautiful design

• Nostr App Manager

• Discover app of the day
• Discover new apps
• Search all nostr apps
• Discover nostr DVMs
• Discover nostr code repositories
• App reviews

• Nostr native - takes a different approach from NostrApps.com

• ZapStore

• A plethora of apps to choose from and install
• Faster than Obtainium
• More complete than F-Droid

• Cleaner than Google Play

• Zapplepay

• Zap from any client
• Bypass Apple's draconian rules
• Nostr Wallet Connect

Blogging

• Feeder
• Subscribe to RSS and Nostr article feeds
• Years of specialization in reading articles
• Offline reading
• OPML Import/Export
• Notification support

• Material design

• Habla

• Long form publishing
• Markdown support
• Rich text editor
• Dark and light modes
• Browse by relay
• Made on nostr, content mirrored to other nostr platforms.

• Extension-only sign-in

• Narr

• Read RSS feeds
• Read Nostr NIP-23 long-form articles
• Import and export OPML
• Runs on desktop with a web-based UI

• Can be accessed remotely from apps such as Reeder, Readkit etc

• Noflux

• Read RSS feeds
• Read Nostr NIP-23 long-form articles
• Import and export OPML
• Runs on desktop with a web-based UI

• Can be accessed remotely from apps such as Reeder, Readkit etc

• npub.pro

• Create a website out of your nostr content
• SEO friendly
• Use any 3rd party tools
• Works like an app
• Beautiful Ghost themes to choose from
• Zero maintenance
• Custom domains
• Open source and self-hostable
• Natively Social

• Publish from any other nostr app

• Obsidian Nostr Writer

• Directly publish your articles from Obsidian to Nostr with a couple of clicks
• Quickly compose and publish short form notes too
• Images in your .md file will automatically be uploaded and handled when you publish
• Add tags to your posts
• See all posts sent from Obsidian with links to view
• Configure to send to whatever relays you like
• Publish under different nostr accounts
• Easily view and download your Nostr bookmarks into Obsidian for reference and local use

• Automatically populates article information fields from the frontmatter

• Shipyard

• Schedule nostr notes
• Schedule reposts
• Note drafts

• Multi-account support

• Yakihonne

• Publishing and reading notes
• Publishing and reading articles
• Curations (set of articles concerning a specific topic) publishing
• Long-form articles are surfaced instead of lost in the feed

Music

• Fountain
• Earn sats while listening to podcasts
• Create and share clips, get paid on your clips
• Boost your favorite podcasts

• Discover clips from friends

• Stemstr

• Collaborate with others to create your next hit
• Music-focused interface
• Remix function

Curation

• Highlighter
• Read and write long-form articles
• Discover what people you trust found interesting and insightful
• Understand why they found it interesting or insightful with their comments attached
• Send sats, comment or share your favorite highlights

• Highlight anything

• Listr

• Create and share lists

• Browse other people's lists

• Zap Cooking

• Browse recipes
• Add your own recipes

• Earn sats via zaps

• Nostree

• Create link lists
• Multiple lists

• Theming

• Pinstr

• Curate lists, users, links
• Share lists
• Discover interesting content

Photos

• Olas
• Special high-quality photos dedicated client
• Publish photos and browse photos
• Publish and browse short videos
• Browse media feeds from friends, extended network and from specific relays

Discovery

• Jumble
• Browse individual relays by URL
• Create and browse relay sets
• Create and reply to notes
• Follow people and browse the feed from your follows

• Browse the kind:20 photos feed

• Nostr Band

• Search keywords, hashtags, pubkeys, posts
• Look up Nostr statistics
• Embed widgets
• API for clients

• NIP05 Service

• Nostrrr

• Look up relay information
• Browse relay feeds
• Browse individual profile feeds with smart relay selection

• Simple and gets the job done

• Zaplife

• See total sats zapped in the past hour, 4 hours, 24 hours and 7 days
• See who zapped who individually
• See notes that got the most zaps

Audio

• Nests
• Start audio chats
• Troll box (chat)
• Instant zaps (lightning payments)

Crazy

• Nostrocket
• Create issues that matter to you
• Award merits to contributors
• Solve problems

Career

• Ostrich Work
• Post jobs for 20k sats
• Find jobs

Marketplace

• Plebeian Market
• Buy and sell things for sats

• Bid in auctions

• Shopstr

• Buy and sell items for sats
• Message seller
• Cashu integration

Freelancing

• SatShoot
• Post problems on SatShoot
• Make money solving problems as a Freelancer
• Share problems or freelance services on your feed
• Bidding system for Clients to choose the best Offer
• Chat in DMs
• Post Reviews on Freelancers or Clients
• Build Reputation
• Public Zaps as Payments
• Use your Web of Trust to keep scammers away

Media

• Slidestr
• Compact media browsing
• Images and videos
• Full screen media

Meatspace

• Yondar
• Add places to a map
• See places by your friends or follows

Streaming

• zap.stream
• Start livestream via zap.stream or Cloudflare
• Watch other livestreams
• Chat
• Custom emojis
• Zap streamers in real time
• Zap chat participants in real time
• Set up stream goals

@ fd06f542:8d6d54cd

• 首页
• 国人开发者
• 中文用户列表
• 各种app整理

@ 91bea5cd:1df4451c

Básico

bash lsblk # Lista todos os diretorios montados.

Para criar o sistema de arquivos:

bash mkfs.btrfs -L "ThePool" -f /dev/sdx

Criando um subvolume:

bash btrfs subvolume create SubVol

Montando Sistema de Arquivos:

bash mount -o compress=zlib,subvol=SubVol,autodefrag /dev/sdx /mnt

Lista os discos formatados no diretório:

bash btrfs filesystem show /mnt

Adiciona novo disco ao subvolume:

bash btrfs device add -f /dev/sdy /mnt

Lista novamente os discos do subvolume:

bash btrfs filesystem show /mnt

Exibe uso dos discos do subvolume:

bash btrfs filesystem df /mnt

Balancea os dados entre os discos sobre raid1:

bash btrfs filesystem balance start -dconvert=raid1 -mconvert=raid1 /mnt

Scrub é uma passagem por todos os dados e metadados do sistema de arquivos e verifica as somas de verificação. Se uma cópia válida estiver disponível (perfis de grupo de blocos replicados), a danificada será reparada. Todas as cópias dos perfis replicados são validadas.

iniciar o processo de depuração :

bash btrfs scrub start /mnt

ver o status do processo de depuração Btrfs em execução:

bash btrfs scrub status /mnt

ver o status do scrub Btrfs para cada um dos dispositivos

bash btrfs scrub status -d / data btrfs scrub cancel / data

Para retomar o processo de depuração do Btrfs que você cancelou ou pausou:

btrfs scrub resume / data

Listando os subvolumes:

bash btrfs subvolume list /Reports

Criando um instantâneo dos subvolumes:

Aqui, estamos criando um instantâneo de leitura e gravação chamado snap de marketing do subvolume de marketing.

bash btrfs subvolume snapshot /Reports/marketing /Reports/marketing-snap

Além disso, você pode criar um instantâneo somente leitura usando o sinalizador -r conforme mostrado. O marketing-rosnap é um instantâneo somente leitura do subvolume de marketing

bash btrfs subvolume snapshot -r /Reports/marketing /Reports/marketing-rosnap

Forçar a sincronização do sistema de arquivos usando o utilitário 'sync'

Para forçar a sincronização do sistema de arquivos, invoque a opção de sincronização conforme mostrado. Observe que o sistema de arquivos já deve estar montado para que o processo de sincronização continue com sucesso.

bash btrfs filsystem sync /Reports

Para excluir o dispositivo do sistema de arquivos, use o comando device delete conforme mostrado.

bash btrfs device delete /dev/sdc /Reports

Para sondar o status de um scrub, use o comando scrub status com a opção -dR .

bash btrfs scrub status -dR / Relatórios

Para cancelar a execução do scrub, use o comando scrub cancel .

bash $ sudo btrfs scrub cancel / Reports

Para retomar ou continuar com uma depuração interrompida anteriormente, execute o comando de cancelamento de depuração

bash sudo btrfs scrub resume /Reports

mostra o uso do dispositivo de armazenamento:

btrfs filesystem usage /data

Para distribuir os dados, metadados e dados do sistema em todos os dispositivos de armazenamento do RAID (incluindo o dispositivo de armazenamento recém-adicionado) montados no diretório /data , execute o seguinte comando:

sudo btrfs balance start --full-balance /data

Pode demorar um pouco para espalhar os dados, metadados e dados do sistema em todos os dispositivos de armazenamento do RAID se ele contiver muitos dados.

Opções importantes de montagem Btrfs

Nesta seção, vou explicar algumas das importantes opções de montagem do Btrfs. Então vamos começar.

As opções de montagem Btrfs mais importantes são:

**1. acl e noacl

**ACL gerencia permissões de usuários e grupos para os arquivos/diretórios do sistema de arquivos Btrfs.

A opção de montagem acl Btrfs habilita ACL. Para desabilitar a ACL, você pode usar a opção de montagem noacl .

Por padrão, a ACL está habilitada. Portanto, o sistema de arquivos Btrfs usa a opção de montagem acl por padrão.

**2. autodefrag e noautodefrag

**Desfragmentar um sistema de arquivos Btrfs melhorará o desempenho do sistema de arquivos reduzindo a fragmentação de dados.

A opção de montagem autodefrag permite a desfragmentação automática do sistema de arquivos Btrfs.

A opção de montagem noautodefrag desativa a desfragmentação automática do sistema de arquivos Btrfs.

Por padrão, a desfragmentação automática está desabilitada. Portanto, o sistema de arquivos Btrfs usa a opção de montagem noautodefrag por padrão.

**3. compactar e compactar-forçar

**Controla a compactação de dados no nível do sistema de arquivos do sistema de arquivos Btrfs.

A opção compactar compacta apenas os arquivos que valem a pena compactar (se compactar o arquivo economizar espaço em disco).

A opção compress-force compacta todos os arquivos do sistema de arquivos Btrfs, mesmo que a compactação do arquivo aumente seu tamanho.

O sistema de arquivos Btrfs suporta muitos algoritmos de compactação e cada um dos algoritmos de compactação possui diferentes níveis de compactação.

Os algoritmos de compactação suportados pelo Btrfs são: lzo , zlib (nível 1 a 9) e zstd (nível 1 a 15).

Você pode especificar qual algoritmo de compactação usar para o sistema de arquivos Btrfs com uma das seguintes opções de montagem:

• compress=algoritmo:nível
• compress-force=algoritmo:nível

Para obter mais informações, consulte meu artigo Como habilitar a compactação do sistema de arquivos Btrfs .

**4. subvol e subvolid

**Estas opções de montagem são usadas para montar separadamente um subvolume específico de um sistema de arquivos Btrfs.

A opção de montagem subvol é usada para montar o subvolume de um sistema de arquivos Btrfs usando seu caminho relativo.

A opção de montagem subvolid é usada para montar o subvolume de um sistema de arquivos Btrfs usando o ID do subvolume.

Para obter mais informações, consulte meu artigo Como criar e montar subvolumes Btrfs .

**5. dispositivo

A opção de montagem de dispositivo** é usada no sistema de arquivos Btrfs de vários dispositivos ou RAID Btrfs.

Em alguns casos, o sistema operacional pode falhar ao detectar os dispositivos de armazenamento usados em um sistema de arquivos Btrfs de vários dispositivos ou RAID Btrfs. Nesses casos, você pode usar a opção de montagem do dispositivo para especificar os dispositivos que deseja usar para o sistema de arquivos de vários dispositivos Btrfs ou RAID.

Você pode usar a opção de montagem de dispositivo várias vezes para carregar diferentes dispositivos de armazenamento para o sistema de arquivos de vários dispositivos Btrfs ou RAID.

Você pode usar o nome do dispositivo (ou seja, sdb , sdc ) ou UUID , UUID_SUB ou PARTUUID do dispositivo de armazenamento com a opção de montagem do dispositivo para identificar o dispositivo de armazenamento.

Por exemplo,

• dispositivo=/dev/sdb
• dispositivo=/dev/sdb,dispositivo=/dev/sdc
• dispositivo=UUID_SUB=490a263d-eb9a-4558-931e-998d4d080c5d
• device=UUID_SUB=490a263d-eb9a-4558-931e-998d4d080c5d,device=UUID_SUB=f7ce4875-0874-436a-b47d-3edef66d3424

**6. degraded

A opção de montagem degradada** permite que um RAID Btrfs seja montado com menos dispositivos de armazenamento do que o perfil RAID requer.

Por exemplo, o perfil raid1 requer a presença de 2 dispositivos de armazenamento. Se um dos dispositivos de armazenamento não estiver disponível em qualquer caso, você usa a opção de montagem degradada para montar o RAID mesmo que 1 de 2 dispositivos de armazenamento esteja disponível.

**7. commit

A opção commit** mount é usada para definir o intervalo (em segundos) dentro do qual os dados serão gravados no dispositivo de armazenamento.

O padrão é definido como 30 segundos.

Para definir o intervalo de confirmação para 15 segundos, você pode usar a opção de montagem commit=15 (digamos).

**8. ssd e nossd

A opção de montagem ssd** informa ao sistema de arquivos Btrfs que o sistema de arquivos está usando um dispositivo de armazenamento SSD, e o sistema de arquivos Btrfs faz a otimização SSD necessária.

A opção de montagem nossd desativa a otimização do SSD.

O sistema de arquivos Btrfs detecta automaticamente se um SSD é usado para o sistema de arquivos Btrfs. Se um SSD for usado, a opção de montagem de SSD será habilitada. Caso contrário, a opção de montagem nossd é habilitada.

**9. ssd_spread e nossd_spread

A opção de montagem ssd_spread** tenta alocar grandes blocos contínuos de espaço não utilizado do SSD. Esse recurso melhora o desempenho de SSDs de baixo custo (baratos).

A opção de montagem nossd_spread desativa o recurso ssd_spread .

O sistema de arquivos Btrfs detecta automaticamente se um SSD é usado para o sistema de arquivos Btrfs. Se um SSD for usado, a opção de montagem ssd_spread será habilitada. Caso contrário, a opção de montagem nossd_spread é habilitada.

**10. descarte e nodiscard

Se você estiver usando um SSD que suporte TRIM enfileirado assíncrono (SATA rev3.1), a opção de montagem de descarte** permitirá o descarte de blocos de arquivos liberados. Isso melhorará o desempenho do SSD.

Se o SSD não suportar TRIM enfileirado assíncrono, a opção de montagem de descarte prejudicará o desempenho do SSD. Nesse caso, a opção de montagem nodiscard deve ser usada.

Por padrão, a opção de montagem nodiscard é usada.

**11. norecovery

Se a opção de montagem norecovery** for usada, o sistema de arquivos Btrfs não tentará executar a operação de recuperação de dados no momento da montagem.

**12. usebackuproot e nousebackuproot

Se a opção de montagem usebackuproot for usada, o sistema de arquivos Btrfs tentará recuperar qualquer raiz de árvore ruim/corrompida no momento da montagem. O sistema de arquivos Btrfs pode armazenar várias raízes de árvore no sistema de arquivos. A opção de montagem usebackuproot** procurará uma boa raiz de árvore e usará a primeira boa que encontrar.

A opção de montagem nousebackuproot não verificará ou recuperará raízes de árvore inválidas/corrompidas no momento da montagem. Este é o comportamento padrão do sistema de arquivos Btrfs.

**13. space_cache, space_cache=version, nospace_cache e clear_cache

A opção de montagem space_cache** é usada para controlar o cache de espaço livre. O cache de espaço livre é usado para melhorar o desempenho da leitura do espaço livre do grupo de blocos do sistema de arquivos Btrfs na memória (RAM).

O sistema de arquivos Btrfs suporta 2 versões do cache de espaço livre: v1 (padrão) e v2

O mecanismo de cache de espaço livre v2 melhora o desempenho de sistemas de arquivos grandes (tamanho de vários terabytes).

Você pode usar a opção de montagem space_cache=v1 para definir a v1 do cache de espaço livre e a opção de montagem space_cache=v2 para definir a v2 do cache de espaço livre.

A opção de montagem clear_cache é usada para limpar o cache de espaço livre.

Quando o cache de espaço livre v2 é criado, o cache deve ser limpo para criar um cache de espaço livre v1 .

Portanto, para usar o cache de espaço livre v1 após a criação do cache de espaço livre v2 , as opções de montagem clear_cache e space_cache=v1 devem ser combinadas: clear_cache,space_cache=v1

A opção de montagem nospace_cache é usada para desabilitar o cache de espaço livre.

Para desabilitar o cache de espaço livre após a criação do cache v1 ou v2 , as opções de montagem nospace_cache e clear_cache devem ser combinadas: clear_cache,nosapce_cache

**14. skip_balance

Por padrão, a operação de balanceamento interrompida/pausada de um sistema de arquivos Btrfs de vários dispositivos ou RAID Btrfs será retomada automaticamente assim que o sistema de arquivos Btrfs for montado. Para desabilitar a retomada automática da operação de equilíbrio interrompido/pausado em um sistema de arquivos Btrfs de vários dispositivos ou RAID Btrfs, você pode usar a opção de montagem skip_balance .**

**15. datacow e nodatacow

A opção datacow** mount habilita o recurso Copy-on-Write (CoW) do sistema de arquivos Btrfs. É o comportamento padrão.

Se você deseja desabilitar o recurso Copy-on-Write (CoW) do sistema de arquivos Btrfs para os arquivos recém-criados, monte o sistema de arquivos Btrfs com a opção de montagem nodatacow .

**16. datasum e nodatasum

A opção datasum** mount habilita a soma de verificação de dados para arquivos recém-criados do sistema de arquivos Btrfs. Este é o comportamento padrão.

Se você não quiser que o sistema de arquivos Btrfs faça a soma de verificação dos dados dos arquivos recém-criados, monte o sistema de arquivos Btrfs com a opção de montagem nodatasum .

Perfis Btrfs

Um perfil Btrfs é usado para informar ao sistema de arquivos Btrfs quantas cópias dos dados/metadados devem ser mantidas e quais níveis de RAID devem ser usados para os dados/metadados. O sistema de arquivos Btrfs contém muitos perfis. Entendê-los o ajudará a configurar um RAID Btrfs da maneira que você deseja.

Os perfis Btrfs disponíveis são os seguintes:

single : Se o perfil único for usado para os dados/metadados, apenas uma cópia dos dados/metadados será armazenada no sistema de arquivos, mesmo se você adicionar vários dispositivos de armazenamento ao sistema de arquivos. Assim, 100% do espaço em disco de cada um dos dispositivos de armazenamento adicionados ao sistema de arquivos pode ser utilizado.

dup : Se o perfil dup for usado para os dados/metadados, cada um dos dispositivos de armazenamento adicionados ao sistema de arquivos manterá duas cópias dos dados/metadados. Assim, 50% do espaço em disco de cada um dos dispositivos de armazenamento adicionados ao sistema de arquivos pode ser utilizado.

raid0 : No perfil raid0 , os dados/metadados serão divididos igualmente em todos os dispositivos de armazenamento adicionados ao sistema de arquivos. Nesta configuração, não haverá dados/metadados redundantes (duplicados). Assim, 100% do espaço em disco de cada um dos dispositivos de armazenamento adicionados ao sistema de arquivos pode ser usado. Se, em qualquer caso, um dos dispositivos de armazenamento falhar, todo o sistema de arquivos será corrompido. Você precisará de pelo menos dois dispositivos de armazenamento para configurar o sistema de arquivos Btrfs no perfil raid0 .

raid1 : No perfil raid1 , duas cópias dos dados/metadados serão armazenadas nos dispositivos de armazenamento adicionados ao sistema de arquivos. Nesta configuração, a matriz RAID pode sobreviver a uma falha de unidade. Mas você pode usar apenas 50% do espaço total em disco. Você precisará de pelo menos dois dispositivos de armazenamento para configurar o sistema de arquivos Btrfs no perfil raid1 .

raid1c3 : No perfil raid1c3 , três cópias dos dados/metadados serão armazenadas nos dispositivos de armazenamento adicionados ao sistema de arquivos. Nesta configuração, a matriz RAID pode sobreviver a duas falhas de unidade, mas você pode usar apenas 33% do espaço total em disco. Você precisará de pelo menos três dispositivos de armazenamento para configurar o sistema de arquivos Btrfs no perfil raid1c3 .

raid1c4 : No perfil raid1c4 , quatro cópias dos dados/metadados serão armazenadas nos dispositivos de armazenamento adicionados ao sistema de arquivos. Nesta configuração, a matriz RAID pode sobreviver a três falhas de unidade, mas você pode usar apenas 25% do espaço total em disco. Você precisará de pelo menos quatro dispositivos de armazenamento para configurar o sistema de arquivos Btrfs no perfil raid1c4 .

raid10 : No perfil raid10 , duas cópias dos dados/metadados serão armazenadas nos dispositivos de armazenamento adicionados ao sistema de arquivos, como no perfil raid1 . Além disso, os dados/metadados serão divididos entre os dispositivos de armazenamento, como no perfil raid0 .

O perfil raid10 é um híbrido dos perfis raid1 e raid0 . Alguns dos dispositivos de armazenamento formam arrays raid1 e alguns desses arrays raid1 são usados para formar um array raid0 . Em uma configuração raid10 , o sistema de arquivos pode sobreviver a uma única falha de unidade em cada uma das matrizes raid1 .

Você pode usar 50% do espaço total em disco na configuração raid10 . Você precisará de pelo menos quatro dispositivos de armazenamento para configurar o sistema de arquivos Btrfs no perfil raid10 .

raid5 : No perfil raid5 , uma cópia dos dados/metadados será dividida entre os dispositivos de armazenamento. Uma única paridade será calculada e distribuída entre os dispositivos de armazenamento do array RAID.

Em uma configuração raid5 , o sistema de arquivos pode sobreviver a uma única falha de unidade. Se uma unidade falhar, você pode adicionar uma nova unidade ao sistema de arquivos e os dados perdidos serão calculados a partir da paridade distribuída das unidades em execução.

Você pode usar 1 00x(N-1)/N % do total de espaços em disco na configuração raid5 . Aqui, N é o número de dispositivos de armazenamento adicionados ao sistema de arquivos. Você precisará de pelo menos três dispositivos de armazenamento para configurar o sistema de arquivos Btrfs no perfil raid5 .

raid6 : No perfil raid6 , uma cópia dos dados/metadados será dividida entre os dispositivos de armazenamento. Duas paridades serão calculadas e distribuídas entre os dispositivos de armazenamento do array RAID.

Em uma configuração raid6 , o sistema de arquivos pode sobreviver a duas falhas de unidade ao mesmo tempo. Se uma unidade falhar, você poderá adicionar uma nova unidade ao sistema de arquivos e os dados perdidos serão calculados a partir das duas paridades distribuídas das unidades em execução.

Você pode usar 100x(N-2)/N % do espaço total em disco na configuração raid6 . Aqui, N é o número de dispositivos de armazenamento adicionados ao sistema de arquivos. Você precisará de pelo menos quatro dispositivos de armazenamento para configurar o sistema de arquivos Btrfs no perfil raid6 .

@ b8ca3d82:e28bd6b5

Your body has always known the way — long before your mind tried to make sense of it. \ \ You can spend all of your time trying to get the mindset just perfectly right, repeating affirmations to yourself in the mirror every single day — and having it all make perfectly, logical sense in your head. - and don't get me wrong; I'm not saying mantras don't work, they can be beautiful tools. They just work best as support — like gentle reminders, little whispers to anchor you while the real transformation happens on a much deeper level… in the body.

Oftentimes when we are so caught up with the web of our minds and the weaving of our thoughts, we tend to distance ourselves from what's happening in the body. Here's the truth though. If it hasn't fully landed in the body yet — it’s just a story, and it will stay just that. A sweet, well-crafted story you keep telling yourself, hoping one day it’ll finally feel true. \ \ Your mind may write the story, but your body is where it becomes truth.

If you want your belief systems to truly shift — to move from something you know into something you live — you have to go into the body. As comforting (and honestly addictive) as it might feel to stay in the mind, rooting your behavior back to your childhood trauma, repeating the mantras and reasoning your way into your self-worth… it’ll only take you so far.

### Because your embodiment doesn’t live in your thoughts — it lives in your cells.\

\ It lives in the way that you carry yourself. The way you hold yourself.

The way your shoulders soften as you exhale the pressure to be anyone else than who you truly are.

The way your gaze softens and your heart opens as you sway through the world.

The way you turn every action into ceremony, every word you speak into prayer. \ \ Not by what you are doing, but by who you are being. -- And being happens in the body.

Here’s some context so it may land a little more deeply for you: our feminine lives in the body, and our masculine lives in the mind. The way to get into our feminine embodiment, our softness, our open-heartedness, and our vulnerability starts with the body — and the mind follows. It begins by making space — soft, spacious room within — to hold every part of you. Even the ones that tremble. Even the ones you’ve learned to silence or send away.

The parts that feel too tender, too much, too messy. The ones you’ve hidden in the corners of your body, hoping no one would notice. Especially those.

Because it’s there, in the quiet ache of what you’ve tried not to feel, that your wholeness waits.

These parts of you don’t need fixing — they need holding. They need breath, warmth, and a body that says, you’re safe here.

This is where embodiment begins. This is where the actual shift happens. Not by becoming someone new — but by gently coming back to your body, softening into what's already there, just a little more each time.

From this space of returning, we open up to the magic we hold within our bodies.

### \ Let this be your invitation — to live from the pulse beneath the story, to start with one breath and to simply ask your body 'what's happening right now?' and be with it.

@ fd06f542:8d6d54cd

国内开发者作品展

jumble.social

作品: https://jumble.social/ 其他作品 ： Running [ wss://nostr-relay.app ] (free & WoT) 💜⚡️ Building 👨‍💻: https://github.com/CodyTseng/jumble https://github.com/CodyTseng/nostr-relay-tray https://github.com/CodyTseng/danmakustr https://github.com/CodyTseng/nostr-relay-nestjs https://github.com/CodyTseng/nostr-relay https://github.com/CodyTseng

nostrbook.com

作品: https://nostrbook.com - NostrBridge, 网桥转发 - TaskQ5, 分布式多任务 - NostrHTTP, nostr to http - Postr, 匿名交友，匿名邮局 - nostrclient (Python client) . -nostrbook, (nostrbook.com) 用nostr在线写书 https://www.duozhutuan.com nostrhttp demo https://github.com/duozhutuan/NostrBridge

nostrmo

A nostr dev.

Nostrmo A client support all platform.

Nowser A nostr signing project.

CacheRelay A nostr cache relay peject.

cfrelay A nostr relay base on cloudflare wokers.

A nostr note timing send service. https://sendbox.nostrmo.com/ https://github.com/haorendashu/nostrmo

0xchat

作者： wcat w783@0xchat.com

www.0xchat.com Building for 0xchat

www.0xchat.com Secure Chat built on Nostr App Store: https://apps.apple.com/app/0xchat/id1637607169 TestFlight: https://testflight.apple.com/join/AjdJFBmU Google play: https://play.google.com/store/apps/details?id=com.oxchat.nostr

https://github.com/nostr-zh/awesome-nostr-zh/blob/main/README.md

awesome-nostr-zh

由中文开发者创建的软件、服务、工具和其他资源的集合。

Nostr (Notes and Other Stuff Transmitted by Relays) 是一个简单、开放的协议，用于创建抗审查的全球社交网络。

English Version

客户端

• 0xchat - 一个类似于 Telegram/WeChat 的 Nostr 客户端，支持 Android、iOS、macOS、Windows 和 Linux。 #移动端 #聊天
• Flycat - 一个 2000 年代老式风格的网页客户端，支持在 Nostr 上写博客。 #网页端
• Jumble - 一个交互友好的 Nostr 客户端，专注于中继器浏览和发现。 #网页端
• Nostrmo - 一个 Flutter 开发的 Nostr 客户端，支持 Android、iOS、macOS、Windows、Web 和 Linux。 #移动端 #桌面端

中继器

• wss://relay.nostr.moe - Nostr.moe 社区中继 (需要注册)。 #ACG
• wss://nostr-relay.app - 一个用于测试的普通的免费的公共 Nostr 中继器。

中继器实现

• nostr-relay-tray - 一个非开发者也能轻松运行的桌面端 Nostr 中继器，支持 Windows、macOS 和 Linux。

库

• nostr-relay - 一个开发中继器的 TypeScript 框架。
• cashu-dart - 一个用dart语言实现cashu协议的库。
• nostr-dart - 一个用dart语言实现nostr协议的库。
• nostrclient - Python 编写的 Nostr 客户端库。 #Python #客户端开发

机器人

• 日本語JLPT文法 - 每小时自动发送一条日语文法，包含文法，日文例句及中文翻译。。

工具

• danmakustr - 一款通过 Nostr 实现去中心化的 YouTube 弹幕插件。 #浏览器插件
• nowser - 一个安全的 Nostr 密钥管理和签名应用，支持 iOS 和 Android，支持 NIP-07、NIP-46 和 NIP-55。 #移动端 #签名器
• pigeon - 一个 Nostr 中继器反向代理服务，可以将本地中继器暴露到公共互联网上，已经集成进 nostr-relay-tray。

教程和资源

• 欢迎加入 Nostr, 这是一份快速入门指南
• nostrbook 在线写书平台 - 提供在线写书功能的平台。 #在线写作 #内容创作

贡献指南

欢迎提交 PR 来完善这个列表！请确保您的提交符合以下要求：

1. 项目与 Nostr 相关
2. 项目由中文开发者开发或中文社区运营
3. 保持分类的一致性和清晰性

详细的贡献指南请查看 CONTRIBUTING.md。

许可证

本作品采用 CC0 1.0 通用 许可协议。

@ fd06f542:8d6d54cd

排名随机， 列表正在增加中。

Cody Tseng

jumble.social 的作者

https://jumble.social/users/npub1syjmjy0dp62dhccq3g97fr87tngvpvzey08llyt6ul58m2zqpzps9wf6wl

• Running [ wss://nostr-relay.app ] (free & WoT) 💜⚡️
• Building 👨‍💻:
• https://github.com/CodyTseng/jumble
• https://github.com/CodyTseng/nostr-relay-tray
• https://github.com/CodyTseng/danmakustr
• https://github.com/CodyTseng/nostr-relay-nestjs
• https://github.com/CodyTseng/nostr-relay
• https://github.com/CodyTseng

阿甘

• @agan0
• 0xchat.com
• canidae40@coinos.io
• https://jumble.social/users/npub13zyg3zysfylqc6nwfgj2uvce5rtlck2u50vwtjhpn92wzyusprfsdl2rce

joomaen

• Follows you
• joomaen.com

• 95aebd@wallet.yakihonne.com

• nobot

• https://joomaen.filegear-sg.me/
• https://jumble.social/users/npub1wlpfd84ymdx2rpvnqht7h2lkq5lazvkaejywrvtchlvn3geulfgqp74qq0

颜值精选官

• wasp@ok0.org
• 专注分享 各类 图片与视频，每日为你带来颜值盛宴，心动不止一点点。欢迎关注，一起发现更多美好！
• https://jumble.social/users/npub1d5ygkef6r0l7w29ek9l9c7hulsvdshms2qh74jp5qpfyad4g6h5s4ap6lz

6svjszwk

• 6svjszwk@ok0.org
• 83vEfErLivtS9to39i73ETeaPkCF5ejQFbExoM5Vc2FDLqSE5Ah6NbqN6JaWPQbMeJh2muDiHPEDjboCVFYkHk4dHitivVi

• low-time-preference

• anarcho-capitalism

• libertarianism

• bitcoin #monero

• https://jumble.social/users/npub1sxgnpqfyd5vjexj4j5tsgfc826ezyz2ywze3w8jchd0rcshw3k6svjszwk

𝘌𝘷𝘦𝘳𝘺𝘥𝘢𝘺 𝘔𝘰𝘳𝘯𝘪𝘯𝘨 𝘚𝘵𝘢𝘳

• everyday@iris.to
• 虽然现在对某些事情下结论还为时尚早，但是从趋势来看，邪恶抬头已经不可避免。
• 我们要做的就是坚持内心的那一份良知，与邪恶战斗到底。
• 黑暗森林时代，当好小透明。
• bc1q7tuckqhkwf4vgc64rsy3rxy5qy6pmdrgxewcww
• https://jumble.social/users/npub1j2pha2chpr0qsmj2f6w783200upa7dvqnnard7vn9l8tv86m7twqszmnke

nostr_cn_dev

npub1l5r02s4udsr28xypsyx7j9lxchf80ha4z6y6269d0da9frtd2nxsvum9jm@npub.cash

Developed the following products: - NostrBridge, 网桥转发 - TaskQ5, 分布式多任务 - NostrHTTP, nostr to http - Postr, 匿名交友，匿名邮局 - nostrclient (Python client) . -nostrbook, (nostrbook.com) 用nostr在线写书 * https://www.duozhutuan.com nostrhttp demo * https://github.com/duozhutuan/NostrBridge * * https://jumble.social/users/npub1l5r02s4udsr28xypsyx7j9lxchf80ha4z6y6269d0da9frtd2nxsvum9jm *

CXPLAY

• lightning@cxplay.org
• 😉很高兴遇到你, 你可以叫我 CX 或 CXPLAY, 这个名字没有特殊含义, 无需在意.
• ©本账号下所有内容如未经特殊声明均使用 CC BY-NC-SA 4.0 许可协议授权.
• 🌐如果您在 Fediverse 收到本账号的内容则说明您的实例已与 Mostr.pub 或 Momostr.pink Bridge 互联, 您所看到的账号为镜像, 所有账号内容正在跨网传递. 如有必要请检查原始页面.
• 🧑‍💻正在提供中文本地化(i10n): #Amethyst #Amber #Citrine #Soapbox #Ditto #Alby
• https://cx.ms/

https://jumble.social/users/npub1gd8e0xfkylc7v8c5a6hkpj4gelwwcy99jt90lqjseqjj2t253s2s6ch58h

w

• 0xchat的作者
• 0xchat@getalby.com
• Building for 0xchat
• https://www.0xchat.com/
• https://jumble.social/users/npub10td4yrp6cl9kmjp9x5yd7r8pm96a5j07lk5mtj2kw39qf8frpt8qm9x2wl

Michael

• highman@blink.sv
• Composer Artist | Musician
• 🎹🎼🎤🏸🏝️🐕❤️
• 在這裡可以看到「我看世界」的樣子
• 他是光良
• https://jumble.social/users/npub1kr5vqlelt8l47s2z0l47z4myqg897m04vrnaqks3emwryca3al7sv83ry3

@ fd06f542:8d6d54cd

NIP-15

Nostr Marketplace

draft optional

Based on 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.

The merchant admin software can be purely clientside, but for convenience and uptime, implementations will likely have a server client listening for NOSTR events.

Marketplace

Marketplace software should be entirely clientside, either as a stand-alone app, or as a purely frontend webpage. A customer subscribes to different merchant NOSTR public keys, and those merchants stalls and products become listed and searchable. The marketplace client is like any other ecommerce site, with basket and checkout. Marketplaces may also wish to include a customer support area for direct message communication with merchants.

Merchant publishing/updating products (event)

A merchant can publish these events:

| Kind | | Description | | --------- | ------------------ | --------------------------------------------------------------------------------------------------------------- | | 0 | set_meta | The merchant description (similar with any nostr public key). | | 30017 | set_stall | Create or update a stall. | | 30018 | set_product | Create or update a product. | | 4 | direct_message | Communicate with the customer. The messages can be plain-text or JSON. | | 5 | delete | Delete a product or a stall. |

Event 30017: Create or update a stall.

Event Content

json { "id": <string, id generated by the merchant. Sequential IDs (`0`, `1`, `2`...) are discouraged>, "name": <string, stall name>, "description": <string (optional), stall description>, "currency": <string, currency used>, "shipping": [ { "id": <string, id of the shipping zone, generated by the merchant>, "name": <string (optional), zone name>, "cost": <float, base cost for shipping. The currency is defined at the stall level>, "regions": [<string, regions included in this zone>] } ] }

Fields that are not self-explanatory: - shipping: - an array with possible shipping zones for this stall. - the customer MUST choose exactly one of those shipping zones. - shipping to different zones can have different costs. For some goods (digital for example) the cost can be zero. - the id is an internal value used by the merchant. This value must be sent back as the customer selection. - each shipping zone contains the base cost for orders made to that shipping zone, but a specific shipping cost per product can also be specified if the shipping cost for that product is higher than what's specified by the base cost.

Event Tags

jsonc { "tags": [["d", <string, id of stall]], // other fields... } - the d tag is required, its value MUST be the same as the stall id.

Event 30018: Create or update a product

Event Content

json { "id": <string, id generated by the merchant (sequential ids are discouraged)>, "stall_id": <string, id of the stall to which this product belong to>, "name": <string, product name>, "description": <string (optional), product description>, "images": <[string], array of image URLs, optional>, "currency": <string, currency used>, "price": <float, cost of product>, "quantity": <int or null, available items>, "specs": [ [<string, spec key>, <string, spec value>] ], "shipping": [ { "id": <string, id of the shipping zone (must match one of the zones defined for the stall)>, "cost": <float, extra cost for shipping. The currency is defined at the stall level> } ] }

Fields that are not self-explanatory: - quantity can be null in the case of items with unlimited availability, like digital items, or services - specs: - an optional array of key pair values. It allows for the Customer UI to present product specifications in a structure mode. It also allows comparison between products - eg: [["operating_system", "Android 12.0"], ["screen_size", "6.4 inches"], ["connector_type", "USB Type C"]]

_Open_: better to move `spec` in the `tags` section of the event?

• shipping:
• an optional array of extra costs to be used per shipping zone, only for products that require special shipping costs to be added to the base shipping cost defined in the stall
• the id should match the id of the shipping zone, as defined in the shipping field of the stall
• to calculate the total cost of shipping for an order, the user will choose a shipping option during checkout, and then the client must consider this costs:
  • the base cost from the stall for the chosen shipping option
  • the result of multiplying the product units by the shipping costs specified in the product, if any.

Event Tags

jsonc "tags": [ ["d", <string, id of product], ["t", <string (optional), product category], ["t", <string (optional), product category], // other fields... ], ...

• the d tag is required, its value MUST be the same as the product id.
• the t tag is as searchable tag, it represents different categories that the product can be part of (food, fruits). Multiple t tags can be present.

Checkout events

All checkout events are sent as JSON strings using NIP-04.

The merchant and the customer can exchange JSON messages that represent different actions. Each JSON message MUST have a type field indicating the what the JSON represents. Possible types:

| Message Type | Sent By | Description | |--------------|----------|---------------------| | 0 | Customer | New Order | | 1 | Merchant | Payment Request | | 2 | Merchant | Order Status Update |

Step 1: customer order (event)

The below JSON goes in content of NIP-04.

```json { "id": , "type": 0, "name": , "address": , "message": , "contact": { "nostr": <32-bytes hex of a pubkey>, "phone": , "email": }, "items": [ { "product_id": , "quantity": } ], "shipping_id": }

```

Open: is contact.nostr required?

Step 2: merchant request payment (event)

Sent back from the merchant for payment. Any payment option is valid that the merchant can check.

The below JSON goes in content of NIP-04.

payment_options/type include:

• url URL to a payment page, stripe, paypal, btcpayserver, etc
• btc onchain bitcoin address
• ln bitcoin lightning invoice
• lnurl bitcoin lnurl-pay

json { "id": <string, id of the order>, "type": 1, "message": <string, message to customer, optional>, "payment_options": [ { "type": <string, option type>, "link": <string, url, btc address, ln invoice, etc> }, { "type": <string, option type>, "link": <string, url, btc address, ln invoice, etc> }, { "type": <string, option type>, "link": <string, url, btc address, ln invoice, etc> } ] }

Step 3: merchant verify payment/shipped (event)

Once payment has been received and processed.

The below JSON goes in content of NIP-04.

json { "id": <string, id of the order>, "type": 2, "message": <string, message to customer>, "paid": <bool: has received payment>, "shipped": <bool: has been shipped>, }

Customize Marketplace

Create a customized user experience using the naddr from NIP-19. The use of naddr enables easy sharing of marketplace events while incorporating a rich set of metadata. This metadata can include relays, merchant profiles, and more. Subsequently, it allows merchants to be grouped into a market, empowering the market creator to configure the marketplace's user interface and user experience, and share that marketplace. This customization can encompass elements such as market name, description, logo, banner, themes, and even color schemes, offering a tailored and unique marketplace experience.

Event 30019: Create or update marketplace UI/UX

Event Content

jsonc { "name": <string (optional), market name>, "about": <string (optional), market description>, "ui": { "picture": <string (optional), market logo image URL>, "banner": <string (optional), market logo banner URL>, "theme": <string (optional), market theme>, "darkMode": <bool, true/false> }, "merchants": [array of pubkeys (optional)], // other fields... }

This event leverages naddr to enable comprehensive customization and sharing of marketplace configurations, fostering a unique and engaging marketplace environment.

Auctions

Event 30020: Create or update a product sold as an auction

Event Content: json { "id": <String, UUID generated by the merchant. Sequential IDs (`0`, `1`, `2`...) are discouraged>, "stall_id": <String, UUID of the stall to which this product belong to>, "name": <String, product name>, "description": <String (optional), product description>, "images": <[String], array of image URLs, optional>, "starting_bid": <int>, "start_date": <int (optional) UNIX timestamp, date the auction started / will start>, "duration": <int, number of seconds the auction will run for, excluding eventual time extensions that might happen>, "specs": [ [<String, spec key>, <String, spec value>] ], "shipping": [ { "id": <String, UUID of the shipping zone. Must match one of the zones defined for the stall>, "cost": <float, extra cost for shipping. The currency is defined at the stall level> } ] }

[!NOTE] Items sold as an auction are very similar in structure to fixed-price items, with some important differences worth noting.

• The start_date can be set to a date in the future if the auction is scheduled to start on that date, or can be omitted if the start date is unknown/hidden. If the start date is not specified, the auction will have to be edited later to set an actual date.

• The auction runs for an initial number of seconds after the start_date, specified by duration.

Event 1021: Bid

jsonc { "content": <int, amount of sats>, "tags": [["e", <event ID of the auction to bid on>]], // other fields... }

Bids are simply events of kind 1021 with a content field specifying the amount, in the currency of the auction. Bids must reference an auction.

[!NOTE] Auctions can be edited as many times as desired (they are "addressable events") by the author - even after the start_date, but they cannot be edited after they have received the first bid! This is enforced by the fact that bids reference the event ID of the auction (rather than the product UUID), which changes with every new version of the auctioned product. So a bid is always attached to one "version". Editing the auction after a bid would result in the new product losing the bid!

Event 1022: Bid confirmation

Event Content:

json { "status": <String, "accepted" | "rejected" | "pending" | "winner">, "message": <String (optional)>, "duration_extended": <int (optional), number of seconds> }

Event Tags: json "tags": [["e" <event ID of the bid being confirmed>], ["e", <event ID of the auction>]],

Bids should be confirmed by the merchant before being considered as valid by other clients. So clients should subscribe to bid confirmation events (kind 1022) for every auction that they follow, in addition to the actual bids and should check that the pubkey of the bid confirmation matches the pubkey of the merchant (in addition to checking the signature).

The content field is a JSON which includes at least a status. winner is how the winning bid is replied to after the auction ends and the winning bid is picked by the merchant.

The reasons for which a bid can be marked as rejected or pending are up to the merchant's implementation and configuration - they could be anything from basic validation errors (amount too low) to the bidder being blacklisted or to the bidder lacking sufficient trust, which could lead to the bid being marked as pending until sufficient verification is performed. The difference between the two is that pending bids might get approved after additional steps are taken by the bidder, whereas rejected bids can not be later approved.

An additional message field can appear in the content JSON to give further context as of why a bid is rejected or pending.

Another thing that can happen is - if bids happen very close to the end date of the auction - for the merchant to decide to extend the auction duration for a few more minutes. This is done by passing a duration_extended field as part of a bid confirmation, which would contain a number of seconds by which the initial duration is extended. So the actual end date of an auction is always start_date + duration + (SUM(c.duration_extended) FOR c in all confirmations.

Customer support events

Customer support is handled over whatever communication method was specified. If communicating via nostr, NIP-04 is used.

Additional

Standard data models can be found here

@ fd06f542:8d6d54cd

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)

json ["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.

When replying to a message with a subject, clients SHOULD replicate the subject tag. Clients MAY adorn the subject to denote that it is a reply. e.g. by prepending "Re:".

Subjects should generally be shorter than 80 chars. Long subjects will likely be trimmed by clients.

@ fd06f542:8d6d54cd

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. For example, an id of 000000000e9d97a1ab09fc381030b346cdd7a142ad57e6df0b46dc9bef6c7e2d has a difficulty of 36 with 36 leading 0 bits.

002f... is 0000 0000 0010 1111... in binary, which has 10 leading zeroes. Do not forget to count leading zeroes for hex digits <= 7.

Mining

To generate PoW for a NIP-01 note, a nonce tag is used:

json {"content": "It's just me mining my own business", "tags": [["nonce", "1", "21"]]}

When mining, the second entry to the nonce tag is updated, and then the id is recalculated (see NIP-01). If the id has the desired number of leading zero bits, the note has been mined. It is recommended to update the created_at as well during this process.

The third entry to the nonce tag SHOULD contain the target difficulty. This allows clients to protect against situations where bulk spammers targeting a lower difficulty get lucky and match a higher difficulty. For example, if you require 40 bits to reply to your thread and see a committed target of 30, you can safely reject it even if the note has 40 bits difficulty. Without a committed target difficulty you could not reject it. Committing to a target difficulty is something all honest miners should be ok with, and clients MAY reject a note matching a target difficulty if it is missing a difficulty commitment.

Example mined note

json { "id": "000006d8c378af1779d2feebc7603a125d99eca0ccf1085959b307f64e5dd358", "pubkey": "a48380f4cfcc1ad5378294fcac36439770f9c878dd880ffa94bb74ea54a6f243", "created_at": 1651794653, "kind": 1, "tags": [ ["nonce", "776797", "20"] ], "content": "It's just me mining my own business", "sig": "284622fc0a3f4f1303455d5175f7ba962a3300d136085b9566801bc2e0699de0c7e31e44c81fb40ad9049173742e904713c3594a1da0fc5d2382a25c11aba977" }

Validating

Here is some reference C code for calculating the difficulty (aka number of leading zero bits) in a nostr event id:

```c int zero_bits(unsigned char b) { int n = 0;

    if (b == 0)
            return 8;

    while (b >>= 1)
            n++;

    return 7-n;

}

/ find the number of leading zero bits in a hash / int count_leading_zero_bits(unsigned char *hash) { int bits, total, i; for (i = 0, total = 0; i < 32; i++) { bits = zero_bits(hash[i]); total += bits; if (bits != 8) break; } return total; } ```

Here is some JavaScript code for doing the same thing:

```javascript // hex should be a hexadecimal string (with no 0x prefix) function countLeadingZeroes(hex) { let count = 0;

for (let i = 0; i < hex.length; i++) { const nibble = parseInt(hex[i], 16); if (nibble === 0) { count += 4; } else { count += Math.clz32(nibble) - 28; break; } }

return count; } ```

Delegated Proof of Work

Since the NIP-01 note id does not commit to any signature, PoW can be outsourced to PoW providers, perhaps for a fee. This provides a way for clients to get their messages out to PoW-restricted relays without having to do any work themselves, which is useful for energy-constrained devices like mobile phones.

@ fd06f542:8d6d54cd

NIP-12

Generic Tag Queries

final mandatory

Moved to NIP-01.

@ fd06f542:8d6d54cd

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.

json { "name": <string identifying relay>, "description": <string with detailed information>, "banner": <a link to an image (e.g. in .jpg, or .png format)>, "icon": <a link to an icon (e.g. in .jpg, or .png format>, "pubkey": <administrative contact pubkey>, "contact": <administrative alternate contact>, "supported_nips": <a list of NIP numbers supported by the relay>, "software": <string identifying relay software URL>, "version": <string version identifier> }

Any field may be omitted, and clients MUST ignore any additional fields they do not understand. Relays MUST accept CORS requests by sending Access-Control-Allow-Origin, Access-Control-Allow-Headers, and Access-Control-Allow-Methods headers.

Field Descriptions

Name

A relay may select a name for use in client software. This is a string, and SHOULD be less than 30 characters to avoid client truncation.

Description

Detailed plain-text information about the relay may be contained in the description string. It is recommended that this contain no markup, formatting or line breaks for word wrapping, and simply use double newline characters to separate paragraphs. There are no limitations on length.

Banner

To make nostr relay management more user friendly, an effort should be made by relay owners to communicate with non-dev non-technical nostr end users. A banner is a visual representation of the relay. It should aim to visually communicate the brand of the relay, complementing the text Description. Here is an example banner mockup as visualized in Damus iOS relay view of the Damus relay.

Icon

Icon is a compact visual representation of the relay for use in UI with limited real estate such as a nostr user's relay list view. Below is an example URL pointing to an image to be used as an icon for the relay. Recommended to be squared in shape.

jsonc { "icon": "https://nostr.build/i/53866b44135a27d624e99c6165cabd76ac8f72797209700acb189fce75021f47.jpg", // other fields... }

Pubkey

An administrative contact may be listed with a pubkey, in the same format as Nostr events (32-byte hex for a secp256k1 public key). If a contact is listed, this provides clients with a recommended address to send encrypted direct messages (See NIP-17) to a system administrator. Expected uses of this address are to report abuse or illegal content, file bug reports, or request other technical assistance.

Relay operators have no obligation to respond to direct messages.

Contact

An alternative contact may be listed under the contact field as well, with the same purpose as pubkey. Use of a Nostr public key and direct message SHOULD be preferred over this. Contents of this field SHOULD be a URI, using schemes such as mailto or https to provide users with a means of contact.

Supported NIPs

As the Nostr protocol evolves, some functionality may only be available by relays that implement a specific NIP. This field is an array of the integer identifiers of NIPs that are implemented in the relay. Examples would include 1, for "NIP-01" and 9, for "NIP-09". Client-side NIPs SHOULD NOT be advertised, and can be ignored by clients.

Software

The relay server implementation MAY be provided in the software attribute. If present, this MUST be a URL to the project's homepage.

Version

The relay MAY choose to publish its software version as a string attribute. The string format is defined by the relay implementation. It is recommended this be a version number or commit identifier.

Extra Fields

Server Limitations

These are limitations imposed by the relay on clients. Your client should expect that requests exceed these practical limitations are rejected or fail immediately.

jsonc { "limitation": { "max_message_length": 16384, "max_subscriptions": 300, "max_limit": 5000, "max_subid_length": 100, "max_event_tags": 100, "max_content_length": 8196, "min_pow_difficulty": 30, "auth_required": true, "payment_required": true, "restricted_writes": true, "created_at_lower_limit": 31536000, "created_at_upper_limit": 3, "default_limit": 500 }, // other fields... }

• max_message_length: the maximum number of bytes for incoming JSON that the relay will attempt to decode and act upon. When you send large subscriptions, you will be limited by this value. It also effectively limits the maximum size of any event. Value is calculated from [ to ] after UTF-8 serialization (so some unicode characters will cost 2-3 bytes). It is equal to the maximum size of the WebSocket message frame.

• max_subscriptions: total number of subscriptions that may be active on a single websocket connection to this relay. Authenticated clients with a (paid) relationship to the relay may have higher limits.

• max_subid_length: maximum length of subscription id as a string.

• max_limit: the relay server will clamp each filter's limit value to this number. This means the client won't be able to get more than this number of events from a single subscription filter. This clamping is typically done silently by the relay, but with this number, you can know that there are additional results if you narrow your filter's time range or other parameters.

• max_event_tags: in any event, this is the maximum number of elements in the tags list.

• max_content_length: maximum number of characters in the content field of any event. This is a count of unicode characters. After serializing into JSON it may be larger (in bytes), and is still subject to the max_message_length, if defined.

• min_pow_difficulty: new events will require at least this difficulty of PoW, based on NIP-13, or they will be rejected by this server.

• auth_required: this relay requires NIP-42 authentication to happen before a new connection may perform any other action. Even if set to False, authentication may be required for specific actions.

• payment_required: this relay requires payment before a new connection may perform any action.

• restricted_writes: this relay requires some kind of condition to be fulfilled to accept events (not necessarily, but including payment_required and min_pow_difficulty). This should only be set to true when users are expected to know the relay policy before trying to write to it -- like belonging to a special pubkey-based whitelist or writing only events of a specific niche kind or content. Normal anti-spam heuristics, for example, do not qualify.

• created_at_lower_limit: 'created_at' lower limit

• created_at_upper_limit: 'created_at' upper limit

• default_limit: The maximum returned events if you send a filter with the limit set to 0.

Event Retention

There may be a cost associated with storing data forever, so relays may wish to state retention times. The values stated here are defaults for unauthenticated users and visitors. Paid users would likely have other policies.

Retention times are given in seconds, with null indicating infinity. If zero is provided, this means the event will not be stored at all, and preferably an error will be provided when those are received.

jsonc { "retention": [ {"kinds": [0, 1, [5, 7], [40, 49]], "time": 3600}, {"kinds": [[40000, 49999]], "time": 100}, {"kinds": [[30000, 39999]], "count": 1000}, {"time": 3600, "count": 10000} ], // other fields... }

retention is a list of specifications: each will apply to either all kinds, or a subset of kinds. Ranges may be specified for the kind field as a tuple of inclusive start and end values. Events of indicated kind (or all) are then limited to a count and/or time period.

It is possible to effectively blacklist Nostr-based protocols that rely on a specific kind number, by giving a retention time of zero for those kind values. While that is unfortunate, it does allow clients to discover servers that will support their protocol quickly via a single HTTP fetch.

There is no need to specify retention times for ephemeral events since they are not retained.

Content Limitations

Some relays may be governed by the arbitrary laws of a nation state. This may limit what content can be stored in clear-text on those relays. All clients are encouraged to use encryption to work around this limitation.

It is not possible to describe the limitations of each country's laws and policies which themselves are typically vague and constantly shifting.

Therefore, this field allows the relay operator to indicate which countries' laws might end up being enforced on them, and then indirectly on their users' content.

Users should be able to avoid relays in countries they don't like, and/or select relays in more favorable zones. Exposing this flexibility is up to the client software.

jsonc { "relay_countries": [ "CA", "US" ], // other fields... }

• relay_countries: a list of two-level ISO country codes (ISO 3166-1 alpha-2) whose laws and policies may affect this relay. EU may be used for European Union countries. A * can be used for global relays.

Remember that a relay may be hosted in a country which is not the country of the legal entities who own the relay, so it's very likely a number of countries are involved.

Community Preferences

For public text notes at least, a relay may try to foster a local community. This would encourage users to follow the global feed on that relay, in addition to their usual individual follows. To support this goal, relays MAY specify some of the following values.

jsonc { "language_tags": ["en", "en-419"], "tags": ["sfw-only", "bitcoin-only", "anime"], "posting_policy": "https://example.com/posting-policy.html", // other fields... }

• language_tags is an ordered list of IETF language tags indicating the major languages spoken on the relay. A * can be used for global relays.

• tags is a list of limitations on the topics to be discussed. For example sfw-only indicates that only "Safe For Work" content is encouraged on this relay. This relies on assumptions of what the "work" "community" feels "safe" talking about. In time, a common set of tags may emerge that allow users to find relays that suit their needs, and client software will be able to parse these tags easily. The bitcoin-only tag indicates that any altcoin, "crypto" or blockchain comments will be ridiculed without mercy.

• posting_policy is a link to a human-readable page which specifies the community policies for the relay. In cases where sfw-only is True, it's important to link to a page which gets into the specifics of your posting policy.

The description field should be used to describe your community goals and values, in brief. The posting_policy is for additional detail and legal terms. Use the tags field to signify limitations on content, or topics to be discussed, which could be machine processed by appropriate client software.

Pay-to-Relay

Relays that require payments may want to expose their fee schedules.

jsonc { "payments_url": "https://my-relay/payments", "fees": { "admission": [{ "amount": 1000000, "unit": "msats" }], "subscription": [{ "amount": 5000000, "unit": "msats", "period": 2592000 }], "publication": [{ "kinds": [4], "amount": 100, "unit": "msats" }], }, // other fields... }

Examples

As of 25 March 2025 the following command provided these results:

bash curl -H "Accept: application/nostr+json" https://jellyfish.land | jq

json { "name": "JellyFish", "description": "Stay Immortal!", "banner": "https://image.nostr.build/7fdefea2dec1f1ec25b8ce69362566c13b2b7f13f1726c2e4584f05f64f62496.jpg", "pubkey": "bf2bee5281149c7c350f5d12ae32f514c7864ff10805182f4178538c2c421007", "contact": "hi@dezh.tech", "software": "https://github.com/dezh-tech/immortal", "supported_nips": [ 1, 9, 11, 13, 17, 40, 42, 59, 62, 70 ], "version": "immortal - 0.0.9", "relay_countries": [ "*" ], "language_tags": [ "*" ], "tags": [], "posting_policy": "https://jellyfish.land/tos.txt", "payments_url": "https://jellyfish.land/relay", "icon": "https://image.nostr.build/2547e9ec4b23589e09bc7071e0806c3d4293f76284c58ff331a64bce978aaee8.jpg", "retention": [], "fees": { "subscription": [ { "amount": 3000, "period": 2628003, "unit": "sats" }, { "amount": 8000, "period": 7884009, "unit": "sats" }, { "amount": 15000, "period": 15768018, "unit": "sats" }, { "amount": 28000, "period": 31536036, "unit": "sats" } ] }, "limitation": { "auth_required": false, "max_message_length": 70000, "max_subid_length": 256, "max_subscriptions": 350, "min_pow_difficulty": 0, "payment_required": true, "restricted_writes": true, "max_event_tags": 2000, "max_content_length": 70000, "created_at_lower_limit": 0, "created_at_upper_limit": 2147483647, "default_limit": 500, "max_limit": 5000 } }

@ fd06f542:8d6d54cd

NIP-10

Text Notes and Threads

draft optional

This NIP defines kind:1 as a simple plaintext note.

Abstract

The .content property contains some human-readable text.

e tags can be used to define note thread roots and replies. They SHOULD be sorted by the reply stack from root to the direct parent.

q tags MAY be used when citing events in the .content with NIP-21.

json ["q", "<event-id> or <event-address>", "<relay-url>", "<pubkey-if-a-regular-event>"]

Authors of the e and q tags SHOULD be added as p tags to notify of a new reply or quote.

Markup languages such as markdown and HTML SHOULD NOT be used.

Marked "e" tags (PREFERRED)

Kind 1 events with e tags are replies to other kind 1 events. Kind 1 replies MUST NOT be used to reply to other kinds, use NIP-22 instead.

["e", <event-id>, <relay-url>, <marker>, <pubkey>]

Where:

• <event-id> is the id of the event being referenced.
• <relay-url> is the URL of a recommended relay associated with the reference. Clients SHOULD add a valid <relay-url> field, but may instead leave it as "".
• <marker> is optional and if present is one of "reply", "root".
• <pubkey> is optional, SHOULD be the pubkey of the author of the referenced event

Those marked with "reply" denote the id of the reply event being responded to. Those marked with "root" denote the root id of the reply thread being responded to. For top level replies (those replying directly to the root event), only the "root" marker should be used.

A direct reply to the root of a thread should have a single marked "e" tag of type "root".

This scheme is preferred because it allows events to mention others without confusing them with <reply-id> or <root-id>.

<pubkey> SHOULD be the pubkey of the author of the e tagged event, this is used in the outbox model to search for that event from the authors write relays where relay hints did not resolve the event.

The "p" tag

Used in a text event contains a list of pubkeys used to record who is involved in a reply thread.

When replying to a text event E the reply event's "p" tags should contain all of E's "p" tags as well as the "pubkey" of the event being replied to.

Example: Given a text event authored by a1 with "p" tags [p1, p2, p3] then the "p" tags of the reply should be [a1, p1, p2, p3] in no particular order.

Deprecated Positional "e" tags

This scheme is not in common use anymore and is here just to keep backward compatibility with older events on the network.

Positional e tags are deprecated because they create ambiguities that are difficult, or impossible to resolve when an event references another but is not a reply.

They use simple e tags without any marker.

["e", <event-id>, <relay-url>] as per NIP-01.

Where:

• <event-id> is the id of the event being referenced.
• <relay-url> is the URL of a recommended relay associated with the reference. Many clients treat this field as optional.

The positions of the "e" tags within the event denote specific meanings as follows:

• No "e" tag:
  This event is not a reply to, nor does it refer to, any other event.

• One "e" tag:
  ["e", <id>]: The id of the event to which this event is a reply.

• Two "e" tags: ["e", <root-id>], ["e", <reply-id>]
<root-id> is the id of the event at the root of the reply chain. <reply-id> is the id of the article to which this event is a reply.

• Many "e" tags: ["e", <root-id>] ["e", <mention-id>], ..., ["e", <reply-id>]
  There may be any number of <mention-ids>. These are the ids of events which may, or may not be in the reply chain. They are citing from this event. root-id and reply-id are as above.

@ fd06f542:8d6d54cd

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.

For example:

jsonc { "kind": 5, "pubkey": <32-bytes hex-encoded public key of the event creator>, "tags": [ ["e", "dcd59..464a2"], ["e", "968c5..ad7a4"], ["a", "<kind>:<pubkey>:<d-identifier>"], ["k", "1"], ["k", "30023"] ], "content": "these posts were published by accident", // other fields... }

Relays SHOULD delete or stop publishing any referenced events that have an identical pubkey as the deletion request. Clients SHOULD hide or otherwise indicate a deletion request status for referenced events.

Relays SHOULD continue to publish/share the deletion request events indefinitely, as clients may already have the event that's intended to be deleted. Additionally, clients SHOULD broadcast deletion request events to other relays which don't have it.

When an a tag is used, relays SHOULD delete all versions of the replaceable event up to the created_at timestamp of the deletion request event.

Client Usage

Clients MAY choose to fully hide any events that are referenced by valid deletion request events. This includes text notes, direct messages, or other yet-to-be defined event kinds. Alternatively, they MAY show the event along with an icon or other indication that the author has "disowned" the event. The content field MAY also be used to replace the deleted events' own content, although a user interface should clearly indicate that this is a deletion request reason, not the original content.

A client MUST validate that each event pubkey referenced in the e tag of the deletion request is identical to the deletion request pubkey, before hiding or deleting any event. Relays can not, in general, perform this validation and should not be treated as authoritative.

Clients display the deletion request event itself in any way they choose, e.g., not at all, or with a prominent notice.

Clients MAY choose to inform the user that their request for deletion does not guarantee deletion because it is impossible to delete events from all relays and clients.

Relay Usage

Relays MAY validate that a deletion request event only references events that have the same pubkey as the deletion request itself, however this is not required since relays may not have knowledge of all referenced events.

Deletion Request of a Deletion Request

Publishing a deletion request event against a deletion request has no effect. Clients and relays are not obliged to support "unrequest deletion" functionality.

@ fd06f542:8d6d54cd

nostrbook 技术框架

源代码在 github.com git clone https://github.com/nostrbook/nostrbook cd nostrbook npm install npm run dev

• 网站主框架 vite + svelte
• 网站浏览书框架 docsify

网站主框架

svelte 为主，daisyui （tailwindcss） css 。 页面的逻辑结构 都是 svelte搭建的， 采用了 layout 左侧菜单。

菜单代码 在 https://github.com/nostrbook/nostrbook/blob/main/src/lib/SideMenu.svelte 菜单里用了弹框登录，弹框的代码基本是问的 AI。

子页面和 路由器看sveltekit规则编写。

书籍的数据

https://github.com/nostrbook/nostrbook/blob/main/src/lib/bookevent.ts 使用的nostr ndk 库来读写 relay。 书的 tag， 内容就是 标题，封面和作者。 [ ['t',booktag], ['title',content['title']], ];

章节的数据

[ ['t',chaptertag], ['title',title], ['d',filename + "-" + bookid], ['e',bookid], ]; 这里面的 d，采用了 文件名 + bookid，所以每一本的章节名的文件名是唯一的。

配置文件

src/lib/config.ts，主要配置 服务器的地址 * 图片文件 nip96 服务器 * relays 服务器 * book的tag ，测试和 release不一样。 如果自己部署独有的服务器也可以不一样。这样内容可以垂直。

首页采用了缓冲机制

首页的内容来自 书籍的列表， 用booktag和30023来区分是不是书籍信息。 为了搜索引擎友好，让页面加载就有数据。

采用了 src/hooks.server.ts 预备加载数据，数据会被首页面 src/routes/+page.server.ts 传给 page.svelte去渲染。 这一切都是后台完成的。html页面加载的时候数据都已经渲染完成了。所以对搜索引擎非常友好。搞定了google，seo。

但是为了数据的完整性， 页面起来后会继续读取列表，这时候可能会显示最新的数据。

增加了 sitemap功能

在 hooks.server.ts 文件里 增加了记录访问成功的页面，并且更新到sitemap.xml 文件里面 ```js export const handle: Handle = async ({ event, resolve }) => { event.locals.books = cachedBooks; // 共享数据 const response = await resolve(event); const {url,method} = event.request; console.log(url,response.status) if (response.status == 200){ let url = event.url.toString(); url = replaceHttpToHttps(url); if (!successfulUrls.has(url)){ successfulUrls.add(url); generateSitemap(); } } return response };

```

然后配置 nginx 设置一个sitemap.xml 链接到 nostrbook/static/sitemap.xml文件。

robots.txt

Sitemap: https://nostrbook.com/sitemap.xml 让爬虫 知道 这个sitemap的存在

xml This XML file does not appear to have any style information associated with it. The document tree is shown below. <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"> <url> <loc>https://nostrbook.com/</loc> </url> <url> <loc>https://nostrbook.com/uploadfiles?imgsrc=https://cdn.nostrcheck.me/fd06f542bc6c06a39881810de917e6c5d277dfb51689a568ad7b7a548d6d54cd/19105641454b483284cf76c42fbdde2ed3f47b1bb2a366a58eaa49630d385027.webp</loc> </url> <url> <loc>https://nostrbook.com/uploadfiles?imgsrc=https://cdn.nostrcheck.me/a7f85dfe651aaa0b47d69659266f434479e40558a640a308a8f6769627305a2b/e9801593f2ea4560c55a6a2651788620cfe6c587c17c08f0e8023f06e7ffaf31.webp</loc> </url> <url> <loc>https://nostrbook.com/uploadfiles?imgsrc=https://cdn.nostrcheck.me/fd06f542bc6c06a39881810de917e6c5d277dfb51689a568ad7b7a548d6d54cd/232dd9c092e023beecb5410052bd48add702765258dcc66f176a56f02b09cf6a.webp</loc> </url> <url> <loc>https://nostrbook.com/uploadfiles?imgsrc=https://cdn.nostrcheck.me/fd06f542bc6c06a39881810de917e6c5d277dfb51689a568ad7b7a548d6d54cd/1dd58d181d40edb7df942b5b16be3f82e95348a471d5a3620a9585f0af784fee.webp</loc> </url> <url> <loc>https://nostrbook.com/uploadfiles?imgsrc=https://cdn.nostrcheck.me/fd06f542bc6c06a39881810de917e6c5d277dfb51689a568ad7b7a548d6d54cd/5ad7189d30c9b49aa61652d98ac7853217b7e445f863be09f9745c49df9f514c.webp</loc> </url> <url> <loc>https://nostrbook.com/books/37548c3300238cc2152d8694bb3ff46b9155d26b1b9b0986baaf7e5e90f00157?title=nostr-examples</loc> </url> <url> <loc>https://nostrbook.com/books/37548c3300238cc2152d8694bb3ff46b9155d26b1b9b0986baaf7e5e90f00157/readme.md</loc> </url> <url> <loc>https://nostrbook.com/books/37548c3300238cc2152d8694bb3ff46b9155d26b1b9b0986baaf7e5e90f00157/_sidebar.md</loc> </url> <url> <loc>https://nostrbook.com/books/c3834c0604b4e5ad66ececd756791a539c585d880864d62b0ef51e3602c482b7?title=NostrBook%E7%AB%99%E7%82%B9%E6%97%A5%E8%AE%B0</loc> </url> <url> <loc>https://nostrbook.com/books/c3834c0604b4e5ad66ececd756791a539c585d880864d62b0ef51e3602c482b7/readme.md</loc> </url> <url> <loc>https://nostrbook.com/books/c3834c0604b4e5ad66ececd756791a539c585d880864d62b0ef51e3602c482b7/_sidebar.md</loc> </url> <url> <loc>https://nostrbook.com/books/c3834c0604b4e5ad66ececd756791a539c585d880864d62b0ef51e3602c482b7/01.md</loc> </url> <url> <loc>https://nostrbook.com/books/c3834c0604b4e5ad66ececd756791a539c585d880864d62b0ef51e3602c482b7/02.md</loc> </url> <url> <loc>https://nostrbook.com/books/9f0c0ef8f03be684fa7bb0de8df20b173aa9057adbb3eb4d30bed6dfc96e7997?title=Nostr%20protocol</loc> </url> <url> <loc>https://nostrbook.com/books/9f0c0ef8f03be684fa7bb0de8df20b173aa9057adbb3eb4d30bed6dfc96e7997/readme.md</loc> </url> <url> <loc>https://nostrbook.com/books/9f0c0ef8f03be684fa7bb0de8df20b173aa9057adbb3eb4d30bed6dfc96e7997/_sidebar.md</loc> </url> <url> <loc>https://nostrbook.com/books/9f0c0ef8f03be684fa7bb0de8df20b173aa9057adbb3eb4d30bed6dfc96e7997/01.md</loc> </url> <url> <loc>https://nostrbook.com/books/9f0c0ef8f03be684fa7bb0de8df20b173aa9057adbb3eb4d30bed6dfc96e7997/02.md</loc> </url> <url> <loc>https://nostrbook.com/books/9f0c0ef8f03be684fa7bb0de8df20b173aa9057adbb3eb4d30bed6dfc96e7997/04.md</loc> </url> <url> <loc>https://nostrbook.com/books/9f0c0ef8f03be684fa7bb0de8df20b173aa9057adbb3eb4d30bed6dfc96e7997/03.md</loc> </url> <url> <loc>https://nostrbook.com/books/9f0c0ef8f03be684fa7bb0de8df20b173aa9057adbb3eb4d30bed6dfc96e7997/05.md</loc> </url> <url> <loc>https://nostrbook.com/books/9f0c0ef8f03be684fa7bb0de8df20b173aa9057adbb3eb4d30bed6dfc96e7997/06.md</loc> </url> <url> <loc>https://nostrbook.com/books/9f0c0ef8f03be684fa7bb0de8df20b173aa9057adbb3eb4d30bed6dfc96e7997/08.md</loc> </url> <url> <loc>https://nostrbook.com/books/9f0c0ef8f03be684fa7bb0de8df20b173aa9057adbb3eb4d30bed6dfc96e7997/07.md</loc> </url> <url> <loc>https://nostrbook.com/books/384647ec127fe421618b5e0ab460a99a8217d59e59ac7075dcdc70266225ea34?title=nostr%E8%B5%84%E6%BA%90%E6%94%B6%E9%9B%86</loc> </url> <url> <loc>https://nostrbook.com/books/384647ec127fe421618b5e0ab460a99a8217d59e59ac7075dcdc70266225ea34/readme.md</loc> </url> <url> <loc>https://nostrbook.com/books/384647ec127fe421618b5e0ab460a99a8217d59e59ac7075dcdc70266225ea34/_sidebar.md</loc> </url> <url> <loc>https://nostrbook.com/books/384647ec127fe421618b5e0ab460a99a8217d59e59ac7075dcdc70266225ea34/01.md</loc> </url> <url> <loc>https://nostrbook.com/books/384647ec127fe421618b5e0ab460a99a8217d59e59ac7075dcdc70266225ea34/02.md</loc> </url> <url> <loc>https://www.nostrbook.com/books/fb423d08b09b253194c1d7df7f828b3ecce78a72caa8d00f1b172631c0e5e951</loc> </url> <url> <loc>https://www.nostrbook.com/books/384647ec127fe421618b5e0ab460a99a8217d59e59ac7075dcdc70266225ea34?title=nostr%E8%B5%84%E6%BA%90%E6%94%B6%E9%9B%86</loc> </url> <url> <loc>https://www.nostrbook.com/</loc> </url> <url> <loc>https://nostrbook.com/books/9f0c0ef8f03be684fa7bb0de8df20b173aa9057adbb3eb4d30bed6dfc96e7997</loc> </url> <url> <loc>https://www.nostrbook.com/books/37548c3300238cc2152d8694bb3ff46b9155d26b1b9b0986baaf7e5e90f00157</loc> </url> <url> <loc>https://www.nostrbook.com/books/37548c3300238cc2152d8694bb3ff46b9155d26b1b9b0986baaf7e5e90f00157/_sidebar.md?format=html</loc> </url> <url> <loc>https://nostrbook.com/books/37548c3300238cc2152d8694bb3ff46b9155d26b1b9b0986baaf7e5e90f00157</loc> </url> <url> <loc>https://nostrbook.com/books/37548c3300238cc2152d8694bb3ff46b9155d26b1b9b0986baaf7e5e90f00157/_sidebar.md?format=html</loc> </url> <url> <loc>https://nostrbook.com/createbook</loc> </url> <url> <loc>https://nostrbook.com/books/c3834c0604b4e5ad66ececd756791a539c585d880864d62b0ef51e3602c482b7</loc> </url> <url> <loc>https://nostrbook.com/about</loc> </url> <url> <loc>https://nostrbook.com/books/384647ec127fe421618b5e0ab460a99a8217d59e59ac7075dcdc70266225ea34</loc> </url> <url> <loc>https://nostrbook.com/books/fb423d08b09b253194c1d7df7f828b3ecce78a72caa8d00f1b172631c0e5e951</loc> </url> <url> <loc>https://www.nostrbook.com/about</loc> </url> <url> <loc>https://nostrbook.com/books/384647ec127fe421618b5e0ab460a99a8217d59e59ac7075dcdc70266225ea34/_sidebar.md?format=html</loc> </url> <url> <loc>https://nostrbook.com/books/9f0c0ef8f03be684fa7bb0de8df20b173aa9057adbb3eb4d30bed6dfc96e7997/_sidebar.md?format=html</loc> </url> <url> <loc>https://nostrbook.com/books/c3834c0604b4e5ad66ececd756791a539c585d880864d62b0ef51e3602c482b7/_sidebar.md?format=html</loc> </url> <url> <loc>https://nostrbook.com/books/fb423d08b09b253194c1d7df7f828b3ecce78a72caa8d00f1b172631c0e5e951/_sidebar.md?format=html</loc> </url> <url> <loc>https://www.nostrbook.com/books/9f0c0ef8f03be684fa7bb0de8df20b173aa9057adbb3eb4d30bed6dfc96e7997</loc> </url> <url> <loc>https://www.nostrbook.com/books/384647ec127fe421618b5e0ab460a99a8217d59e59ac7075dcdc70266225ea34</loc> </url> <url> <loc>https://www.nostrbook.com/books/c3834c0604b4e5ad66ececd756791a539c585d880864d62b0ef51e3602c482b7</loc> </url> <url> <loc>https://www.nostrbook.com/books/fb423d08b09b253194c1d7df7f828b3ecce78a72caa8d00f1b172631c0e5e951/_sidebar.md?format=html</loc> </url> <url> <loc>https://www.nostrbook.com/books/9f0c0ef8f03be684fa7bb0de8df20b173aa9057adbb3eb4d30bed6dfc96e7997/_sidebar.md?format=html</loc> </url> <url> <loc>https://www.nostrbook.com/books/384647ec127fe421618b5e0ab460a99a8217d59e59ac7075dcdc70266225ea34/_sidebar.md?format=html</loc> </url> <url> <loc>https://www.nostrbook.com/books/c3834c0604b4e5ad66ececd756791a539c585d880864d62b0ef51e3602c482b7/_sidebar.md?format=html</loc> </url> <url> <loc>https://www.nostrbook.com/uploadfiles?imgsrc=https://cdn.nostrcheck.me/a7f85dfe651aaa0b47d69659266f434479e40558a640a308a8f6769627305a2b/e9801593f2ea4560c55a6a2651788620cfe6c587c17c08f0e8023f06e7ffaf31.webp</loc> </url> <url> <loc>https://www.nostrbook.com/uploadfiles?imgsrc=https://cdn.nostrcheck.me/fd06f542bc6c06a39881810de917e6c5d277dfb51689a568ad7b7a548d6d54cd/19105641454b483284cf76c42fbdde2ed3f47b1bb2a366a58eaa49630d385027.webp</loc> </url> <url> <loc>https://www.nostrbook.com/uploadfiles?imgsrc=https://cdn.nostrcheck.me/fd06f542bc6c06a39881810de917e6c5d277dfb51689a568ad7b7a548d6d54cd/232dd9c092e023beecb5410052bd48add702765258dcc66f176a56f02b09cf6a.webp</loc> </url> <url> <loc>https://www.nostrbook.com/uploadfiles?imgsrc=https://cdn.nostrcheck.me/fd06f542bc6c06a39881810de917e6c5d277dfb51689a568ad7b7a548d6d54cd/1dd58d181d40edb7df942b5b16be3f82e95348a471d5a3620a9585f0af784fee.webp</loc> </url> <url> <loc>https://www.nostrbook.com/uploadfiles?imgsrc=https://cdn.nostrcheck.me/fd06f542bc6c06a39881810de917e6c5d277dfb51689a568ad7b7a548d6d54cd/5ad7189d30c9b49aa61652d98ac7853217b7e445f863be09f9745c49df9f514c.webp</loc> </url> <url> <loc>https://www.nostrbook.com/books/37548c3300238cc2152d8694bb3ff46b9155d26b1b9b0986baaf7e5e90f00157/readme.md</loc> </url> <url> <loc>https://www.nostrbook.com/books/37548c3300238cc2152d8694bb3ff46b9155d26b1b9b0986baaf7e5e90f00157/_sidebar.md</loc> </url> <url> <loc>https://nostrbook.com/books/37548c3300238cc2152d8694bb3ff46b9155d26b1b9b0986baaf7e5e90f00157/getstart.md</loc> </url> <url> <loc>https://www.nostrbook.com/books/9f0c0ef8f03be684fa7bb0de8df20b173aa9057adbb3eb4d30bed6dfc96e7997/readme.md</loc> </url> <url> <loc>https://www.nostrbook.com/books/9f0c0ef8f03be684fa7bb0de8df20b173aa9057adbb3eb4d30bed6dfc96e7997/_sidebar.md</loc> </url> <url> <loc>https://www.nostrbook.com/books/9f0c0ef8f03be684fa7bb0de8df20b173aa9057adbb3eb4d30bed6dfc96e7997/04.md</loc> </url> <url> <loc>https://nostrbook.com/books/_sidebar.md/_sidebar.md?format=html</loc> </url> <url> <loc>https://www.nostrbook.com/books/37548c3300238cc2152d8694bb3ff46b9155d26b1b9b0986baaf7e5e90f00157?title=nostr-examples</loc> </url> <url> <loc>https://www.nostrbook.com/books/37548c3300238cc2152d8694bb3ff46b9155d26b1b9b0986baaf7e5e90f00157/getstart.md</loc> </url> <url> <loc>https://www.nostrbook.com/writebook</loc> </url> </urlset>

@ fd06f542:8d6d54cd

Get started

A step-by-step guide to getting started with Nostr.

这里主要面对开发者，下面会有一些例子。

Understanding keys

Each Nostr account is based on a public/private key pair. A simple way to think about this is that your public key is your username and your private key is your password, with one major caveat. Unlike a password, your private key cannot be reset if lost.

The public key is generally presented as a string with the prefix npub and the private key with the prefix nsec. Make sure you store you private key somewhere safe, like a password manager.

nodejs example

使用 nostr-tools 开始第一个例子

https://github.com/nbd-wtf/nostr-tools

```

npm

npm install --save nostr-tools

jsr

npx jsr add @nostr/tools ```

Generating a private key and a public key

```js import { generateSecretKey, getPublicKey } from 'nostr-tools/pure'

let sk = generateSecretKey() // sk is a Uint8Array let pk = getPublicKey(sk) // pk is a hex string ```

To get the secret key in hex format, use ```js import { bytesToHex, hexToBytes } from '@noble/hashes/utils' // already an installed dependency

let skHex = bytesToHex(sk) let backToBytes = hexToBytes(skHex) ```

这样你就得到了你的 nostr账户了，完全是程序生成的。

任何人都可以生成，javascript，python ,rust 等各种语言都可以

git clone https://github.com/duozhutuan/nostrclient

python from nostrclient.key import PrivateKey pkey = PrivateKey() print("Your public key: ",pkey.public_key) print("Your public key bech32: ",pkey.public_key.bech32())

Keeping keys safe

If you are using Nostr on a web browser it is probably a good idea to install an extension like Connect, nos2x or Alby, then input your secret key there (or it will generate a secret key for you). From there you will be able to use all web apps very easily with no worries. For the paranoid, keeping your key on a hardware device is also an option.

If you are on Android, installing Amber is the safest way to use Nostr without having to paste your key directly into apps.

Otherwise it's probably safe to paste your nsec into well-established and security-minded apps such as Damus, so don't worry too much.

Let's do this!

Now that you know what it takes, just pick a client to start using Nostr!

Finding people to follow If you know someone that is on Nostr, start by following them, then look at whom they are following and whom they are interacting with, and sooner rather than later you'll have a bunch of followers and a community for yourself inside Nostr.

Otherwise, you can always take a look at trending posts and people and get people from there.

@ fd06f542:8d6d54cd

What is Nostr?

Nostr is a simple, open protocol that enables global, decentralized, and censorship-resistant social media.

nostr 是 去中心化的 抗审查的社交媒体。

去中心化，其实就是多中心化，这里中心就是relay 服务器。现在的nostr 网络上有很多relay服务器可以存储信息。 * 短文，就是写类似微博，朋友圈什么的。 * 长文，可以写长博客，写书什么的。 * 图片 和 视频 ，nostr社区有专门的 图片和视频服务器很多都是免费的，按照nostr协议上传即可。

Simple

The protocol is based on very simple & flexible event objects (which are passed around as plain JSON) and uses standard elliptic-curve cryptography for keys and signing. The only supported transport is websockets connections from clients to relays. This makes it easy to write clients and relays and promotes software diversity.

nostr的协议非常简单，客户端通过 event 的格式（json）打包通过websocket 和relay服务器交互。

将一个 短文传到 relay服务器，很多relay服务器都 无需任何权限。任何人都可以上传获取读取服务器内容。

协议中是通过加密签名的，因此发布者拥有每个event的所有权，是可以证实的。

Verifiable

Because Nostr accounts are based on public-key cryptography it's easy to verify messages were really sent by the user in question.

nostr的账户是基于密码学生成的，用户无需邮件和手机注册； 也许无需到任何服务器去注册。 这一点 非常的具有吸引力，就像每个人的BTC账户一样。非常的自由，让用户感觉的无比的的快捷。

!> 以上两点是深深吸引 nostr用户的地方。自由，而不伤害第三方。

Nostr: a quick introduction, attempt by fiatjaf

Nostr doesn't have a material existence, it is not a website or an app. Nostr is just a description what kind of messages each computer can send to the others and vice-versa. It's a very simple thing, but the fact that such description exists allows different apps to connect to different servers automatically, without people having to talk behind the scenes or sign contracts or anything like that.

When you use a Nostr client that is what happens, your client will connect to a bunch of servers, called relays, and all these relays will speak the same "language" so your client will be able to publish notes to them all and also download notes from other people.

That's basically what Nostr is: this communication layer between the client you run on your phone or desktop computer and the relay that someone else is running on some server somewhere. There is no central authority dictating who can connect to whom or even anyone who knows for sure where each note is stored.

If you think about it, Nostr is very much like the internet itself: there are millions of websites out there, and basically anyone can run a new one, and there are websites that allow you to store and publish your stuff on them.

The added benefit of Nostr is that this unified "language" that all Nostr clients speak allow them to switch very easily and cleanly between relays. So if one relay decides to ban someone that person can switch to publishing to others relays and their audience will quickly follow them there. Likewise, it becomes much easier for relays to impose any restrictions they want on their users: no relay has to uphold a moral ground of "absolute free speech": each relay can decide to delete notes or ban users for no reason, or even only store notes from a preselected set of people and no one will be entitled to complain about that.

There are some bad things about this design: on Nostr there are no guarantees that relays will have the notes you want to read or that they will store the notes you're sending to them. We can't just assume all relays will have everything — much to the contrary, as Nostr grows more relays will exist and people will tend to publishing to a small set of all the relays, so depending on the decisions each client takes when publishing and when fetching notes, users may see a different set of replies to a note, for example, and be confused.

Another problem with the idea of publishing to multiple servers is that they may be run by all sorts of malicious people that may edit your notes. Since no one wants to see garbage published under their name, Nostr fixes that by requiring notes to have a cryptographic signature. This signature is attached to the note and verified by everybody at all times, which ensures the notes weren't tampered (if any part of the note is changed even by a single character that would cause the signature to become invalid and then the note would be dropped). The fix is perfect, except for the fact that it introduces the requirement that each user must now hold this 63-character code that starts with "nsec1", which they must not reveal to anyone. Although annoying, this requirement brings another benefit: that users can automatically have the same identity in many different contexts and even use their Nostr identity to login to non-Nostr websites easily without having to rely on any third-party.

To conclude: Nostr is like the internet (or the internet of some decades ago): a little chaotic, but very open. It is better than the internet because it is structured and actions can be automated, but, like in the internet itself, nothing is guaranteed to work at all times and users many have to do some manual work from time to time to fix things. Plus, there is the cryptographic key stuff, which is painful, but cool.

诞生blog

https://fiatjaf.com/nostr.html

The simplest open protocol that is able to create a censorship-resistant global "social" network once and for all.

It doesn't rely on any trusted central server, hence it is resilient; it is based on cryptographic keys and signatures, so it is tamperproof; it does not rely on P2P techniques, therefore it works. ...

@ fd06f542:8d6d54cd

• About nostr
• Getting started

@ fd06f542:8d6d54cd

使用nostrbook.com网站

登录和创建用户： 登录按钮 ，可以粘贴 已有的 nsec....账号，完成登录。

注册： 可以点击红标位置 生成你的账户。 “确定” 完成注册。

创建书籍

封面的上传

创建书籍，可以用 微信截图 后直接 ctrl+v. 粘贴即可。

或者点击浏览 本地图片文件。

标题和作者

正常填写就可以。 书的作者和上传文件人没有一一绑定。

写书

创建完成后就可以写书了，写书入口在 登录处 “我的书籍” 。点进去会出现你创建的书籍。选择一本就可以写书了。

列出你创建的所有的书籍

点击图标，就可以进入开始写作了。例如《nostrbook站点日记》

如图所示有4个部分

1. （1）关闭按钮，点击就退出编辑，这时候他会提示你保存，如果不需要保存退出，点击 “不保存退出”
2. （2）大纲 是编写 你书籍的大纲，这个参考 docsify文档 下面会有例子。 时间排列是 你所有为本书写的章节。但是有些章节你可能废弃了，或者暂时不想展示，都会存在 时间排列里面，就是按照你编写的时间倒序排列的。草稿 是你暂时存储的内容，没有上传到网络，存在你本地浏览器的缓存里面。
3. （3）这个部分看到的就是你的章节列表，当让你第一次来的这个地方是空的。新增章节 下一次就会有内容了。
4. （4）文件名，是我们存储章节的唯一标识。 readme.md 和_sidebar.md 是系统默认必须有的。因为docsify技术默认需要这2个。

如何编写大纲

如果你是第一次开始，大纲的界面是这样的。

• 点击 增加大纲
• 点击 查看样例
• 修改系统生成的例子，此时 readme.md是必须的readme 对应的名字你可以自己修改
• 点击提交 就可以完成大纲了。

第二次、点击更新大纲 按钮 - [首页](/readme.md) - [国人开发者](/01.md) - [中文用户列表](/02.md)

大纲例子，“[]” 内是标题，“（）”内是 文件名； 标题是是显示在文章的右侧； 文件名的作用是匹配 ‘新增章节’ 里面的markdown的相匹配关联的。

如何编写一个章节，例如：readme.md

* 点击 新增章节 * 填写标题 * 填写内容 * 关键是 填写文件名，需要和大纲里的名字对应 * 提交

?> 如果你写的 章节 并没有在大纲里标识名字 ，用户在浏览的时候，左侧的章节并不会出现。

@ fd06f542:8d6d54cd

{"coverurl":"https://cdn.nostrcheck.me/fd06f542bc6c06a39881810de917e6c5d277dfb51689a568ad7b7a548d6d54cd/19105641454b483284cf76c42fbdde2ed3f47b1bb2a366a58eaa49630d385027.webp","title":"nostr-examples","author":"nostr-dev"}

@ fd06f542:8d6d54cd

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.

Once a mention is identified, for example, the pubkey 27866e9d854c78ae625b867eefdfa9580434bc3e675be08d2acb526610d96fbe, the client MUST add that pubkey to the .tags with the tag p, then replace its textual reference (inside .content) with the notation #[index] in which "index" is equal to the 0-based index of the related tag in the tags array.

The same process applies for mentioning event IDs.

A client that receives a text_note event with such #[index] mentions in its .content CAN do a search-and-replace using the actual contents from the .tags array with the actual pubkey or event ID that is mentioned, doing any desired context augmentation (for example, linking to the pubkey or showing a preview of the mentioned event contents) it wants in the process.

Where #[index] has an index that is outside the range of the tags array or points to a tag that is not an e or p tag or a tag otherwise declared to support this notation, the client MUST NOT perform such replacement or augmentation, but instead display it as normal text.

@ 872982aa:8fb54cfe

{"coverurl":"https://cdn.nostrcheck.me/872982aa37b864973a389d465bc6ed5045a78586496d104e05f39b8d8fb54cfe/e6d4161955877a472f69b7ed27230e8677da2a3f3fb8ae0b472816852111cb38.webp","title":"设计艺术和配色","author":"彩色盒子"}

@ 872982aa:8fb54cfe

{"coverurl":"https://cdn.nostrcheck.me/872982aa37b864973a389d465bc6ed5045a78586496d104e05f39b8d8fb54cfe/2d173d2aabda99d75f054da0ac0bf04e67c58b09af84ae0765dcf904516da75d.webp","title":"Nostr protocol4","author":"fiatjaf"}

@ 872982aa:8fb54cfe

{"coverurl":"https://cdn.nostrcheck.me/872982aa37b864973a389d465bc6ed5045a78586496d104e05f39b8d8fb54cfe/1c39bd6f09aca6e9f20f7399809a547950069d06a68b78f565fbfab4b14ec93c.webp","title":"竹林的声音2","author":"花花的作者"}

@ a7f85dfe:27305a2b

• 首页

• D1 烧录USB起动器

• D2 安装系统

@ a7f85dfe:27305a2b

1.更改bios，usb启动

根据自己电脑的要求进入bios，选择优先usb启动。

2.安装系统

傻瓜式，安装proxmox。网络设置部分，建议直接插线联网，系统会根据现有网络分配IP网关信息，方便服务器开始运行时可其他电脑可以通过IP地址访问。

3.挂载硬盘

安装成功后，通过其他电脑访问服务器IP，进入图形管理界面。可以看到这时将系统盘分为local 跟local-lvm。其他硬盘得先挂载才能进行pve管理。

1.列出可用硬盘及目录地址，如果硬盘有多个分区，需要删除分区的话 fdisk -l

fdisk /dev/sda #你硬盘的地址 m #查看文档 d # 列出分区号码，选择删除的分区 n #创建分区 p #创建主分区 w #写入分区 2. 格式化分区系统 mkfs -t ext4 /dev/sda1

1. 挂载硬盘 mkdir /mnt/data mount -t ext4 /dev/sda1 /mnt/data

4.开机自动挂载 lsblk #查看硬盘和分区

sudo blkid # 查看硬盘的uuid sudo vi /etc/fstab #打开fstab文件 添加如下一行 UUID=你的硬盘ID /mnt/data ext4 defaults 0 2 测试挂载 sudo mount -a #如果没有显示错误信息就是挂载正确

@ 872982aa:8fb54cfe

茶业

@ 872982aa:8fb54cfe

432143214321412

@ 872982aa:8fb54cfe

• 首页

• 第一章、 宁静的夜晚

• 第二章、 第二章标题

• 第三章、 第三章标题

@ f7f4e308:b44d67f4

https://sns-video-hw.xhscdn.com/stream/1/110/258/01e7ec7be81a85850103700195f3c4ba45_258.mp4

@ 5188521b:008eb518

Ecology

When my father died, an entire ecosystem system of beneficiaries withered. Moussa Ag El Khir funded scholarships and community projects, paying thousands of Dinars monthly to stop the oasis town of In Salah from burning up. The few families we knew operating outside the oil-field economy would be forced to flee to the Mediterranean coast, along with just about every other Berber.

It wasn’t unexpected. My father had cystic fibrosis for all sixty-one years of his life. So far, that’s the only legacy he’s passed on to his children. My brothers are just carriers, but me, his precious daughter ended up like him in more ways than one.

We sat there in the lawyer’s office in Algiers, my brothers and I, staring at the ledger which contained payment for his life’s work.

“And he only left one word in his will?” asked Ibrahim for the third time. Ecology.

The lawyer said Moussa was very clear. He chose each of the keys himself. The contents of the ledger would belong to whoever could decode his life — those who understood the real meaning. Then he cut all communications and walked into the Sahara. The Tuareg caravan on the road to Akabli found his body a week later, reddened by sand burn.

Earth

We made an agreement that day. To share each word we discovered. We could break the code together. Of course, Ibrahim and Hama didn’t share anything. We barely speak. That’s what happens when one child follows their father into science, and her two brothers move to France the minute they get rich enough to buy a wife. I bet they spent longer looking into legal loopholes to get their hands on my father’s assets than they did trying to identify the keys.

That day was the start of my second life, and I went from research assistant at a regional university to private-key detective. 2048 words and few clues where to start. Although I was 27, I was virtually a grandmother according to the In Salah wives. But of course, I could never be a grandmother, or even a mother. Every night, I scoured photos in the family archive. An initial sweep of his digital footprint returned no out-of-place instances of any keywords.

It took me a year to find the GPS tag he’d added to one photo — an eighteen-year-old daughter standing next to a father proud of his first infinite solar prototype. The panel has long-since been torn out by the oil corp, but the base is still there. I drove the three kilometres from the town limit and shone the high beams at the spot. When I got out, the air was cool but still thick with sand. A few more steps through sinking dunes, and I saw it. He’d scratched a little globe into the blistered metal, and for a moment, my mucus-laden lungs tasted clear air.

Trigger

The next word took three years. Friends, contacts, professors, biographers — visits to anyone with whom he might have left a clue. But it was in the In Salah hospital, where, upon a routine CF checkup with Jerome Devailier, a French doctor, ‘trigger’ appeared. The government might stack everything against the desert peoples, but they hadn’t taken away healthcare. I’d been living off the kindness of neighbours while finishing my thesis on the very solar technology my father developed. How could he have known the ‘buyer’ was just a tendril of the very oil company he sought to defeat.

Dr Devalier went through the list of carcinogens and allergens to avoid with my new drugs. Over forty triggers which could be my downfall. If I was lucky, I’d live as long as my father did.

By then, my research stipend was long gone. I existed on toughened bread and soup, which always carried the taste of the scorched city air. Yet, I stayed. The public library, disconnected from the grid by the oil corp, was where I finished my manuscript. They would fight its publication. Since father’s money no longer flowed into the town, many had deserted me. There were those who said he killed an entire people by selling his solar patent to the wrong buyers. Others in In Salah worshipped his name, but eventually, they all trudged north to the cities. My brothers sold the family home from under me, forcing me to follow.

When I returned from the hospital, I dug out my father’s medical documents. On every page, the word ‘trigger’ was underlined. That was the moment I knew my life’s work would be unlocking the ledger, not publishing studies on long-dead solar panel technology. That battle was lost.

They

All we need is a simple document, but here, it is the administrators’ job to send people away. Physical copies are only issued in extreme circumstances. Citizens’ Registry screens played endless repetitions of how to apply for digital documents. The shrill voices of family members desperate for the original copy of a pirated document drowned the TV messaging. Women removed headscarves and revealed thick black hair; teenagers paced. The atmosphere thickened with sweat. And hours passed. Each appointment required a reset of digital protocol, biometric tests, and identity cards from legal descendents. Through counterfeit identities, our Dinars leak into the hands of criminals, but still the government denies the need for bitcoin. They just print more money. They is the word my father used for the government that fought his patent so hard.

After a four-hour wait, I discovered that the physical death certificate included an ‘identifying mark’ on the deceased’s body. The ink was fresh — etched into the shoulder blade of a man who wished to turn his back on the government that ignored its people. The tattoo read aqqalan, the Tamasheq word for they.

Scheme

It took two trips to his cluttered Marseille office to convince him I was serious. Two visas, two flights, and the small amount from the sale of the family house. But few detectives wanted to work for a promise.

The ledger could not legally be owned in Algeria, and Laurent Mercier was the only serious professional who entertained a percentage of what was on there. The solar tech patent and documents from my father were enough to start Laurent on the trail. ‘Preliminary,’ he said, until I had the ledger in my possession.

“Flying is not easy with my condition,” I said.

He lowered his sunglasses. “Working is not easy without money.”

Contact with my brother through the lawyer in Algiers was achingly slow, but eventually they agreed to give me possession. What was 33% of nothing anyway? Years had gone by.

So, when I sat for the second time, in the sweaty office in Marseille, I gave Laurent the ledger, and he handed me a surprise. In all his business affairs, my father used little English, but the word ‘scheme’ appeared in all three company names he incorporated in the last three years of his life. We had our fifth word, and I finally had someone on my side.

Make

Some days, I could barely walk to the public library. I became lethargic and mostly sat in the cool dark of my room in the shelter. The government refused to provide housing outside of Algiers, but a Tuareg organisation from Mali opened a shelter in In Salah. Bulging eyes and faded clothes stared back in the mirror each day. How long had it been since I’d been to a wedding, or celebrated a friend’s child? Occupants came and went, and all that was left was a barren room and one meal per day.

As the sun punished the city with every ray of Allah’s untapped gift, streets grew thick with dust, and the local government fell, seat by seat, to oil execs. The only transport running was to and from the oil fields, which belched the remnants of the land into the sky. And still they worked. Still they sat on my father’s patent and refused to supply the world with efficient solar power.

With little else to cling onto, I harboured thoughts of how I could spend the ledger money. Fixing the town and replanting lost gardens. Bringing people back. That all took a back seat to decoding the message my father was sending. Laurent and I began to believe that the keys he chose formed some sort of instruction for his legacy.

Ten years to the day after his death, I was in the public library, looking for clues in an English history book. On my exit, the librarian stopped me.

“We have a gift for you, Kana.”

I waited while he fetched a package.

“Your father instructed me to give this to you. But not before this date.”

My hands tore open the package. More books, technical manuals, and hand-written notes. Amongst the papers was a tasselled leather bookmark embossed with the four letters that comprised one of the seven missing words. Make.

Citizen

It’s hard for a father in Algeria to admit to his daughter that she is his spirit — the heir to his life’s work. Of course he felt terrible guilt after our mother’s passing. That was when the letters started.

Moussa wrote to himself really, trying to come to terms with bringing a protégé into the world with a bright scientific mind and lungs that would snap her life expectancy. We communicated by letter for the last few years of his life — sharing the breakthroughs of his findings and what it might mean for our decaying oasis town. Analogue writing was the only real privacy, he said. His letters always ran to the same length, as if they were one lesson divided into equal chunks. We even exchanged letters during his last hospitalisation in Algiers. Those words were the only real strength I gained.

It was Laurent who analysed the letters with a new text scanning tool. For me, my father’s last letters were advice, regret, pain, and love, but to Laurent, they were simply a puzzle to solve to get one step closer.

Our letters gave Laurent the idea to communicate via physical mail. The process was painful, with letters sent from outlying towns before being shipped across the Alboran Sea and up into France. Muatin was one name my father called me. Like him, I dreamed of helping many through science. This was one of the few Arabic words in the French letters he wrote. It was also the only keyword included in any of the letters. Citizen.

When

Years of quiet followed. In Salah became unlivable after they co-opted the city reservoir for cooling drilling rigs. Each study that proved the field was still viable funnelled funds away from the locals who clung on. Resettlement benefits went up, and all but the semi-nomadic Tuaregs left. I followed. My health could not take much more desert. In the cooler coastal plains, I recovered strength, and subsidies for new medications helped me survive on a meagre teaching salary.

With no further clues, my Marseillais detective lost interest. His last letter, sent years ago, stated with unusual brevity that he was resigning the case. No payment was due.

I had lost my health, my father, his work, my money, our house, the town, and I spent each week delivering science and English classes to teenagers. They had no more hope for our country than I had. Algerians had already lost the Sahara. A one-degree temperature shift each decade of my life had shrunk Africa and sent its peoples northwards.

My father’s word puzzle occupied my thoughts. The combinations and permutations of letters and characters had millions of possible meanings but only one correct answer. Yet simple linguistic logic provided the next word. The headteacher was a linguist — a profession long lost to the higher-powered text analysers and language AI. He spoke little English but asked about the categorisations of grammatical terms in the 2048 key words.

“Why do you ask?”

“Because,” he said, “for a sentence of twelve words, at least one conjunction is necessary to form a second clause.”

He was right. I had been focussing on lists and complex codes to build my father’s motto. When I got home, I furiously searched my list of terms for conjunctions. I found only one. ‘When.’

Can

The permutations were still huge. Even eliminating some of the more conceptual words did not help. Millions of sentences existed in my dead father’s mind. Millions of meanings, all lost to the need for more energy to fund the world’s great thirst for energy. Still, the panels in most of the ‘dead middle’ (as the space between the tropics became known) melted at over 50 degrees.

I was back in Paris for CF treatment. As a young woman, I would have been pleased to make fifty years. But the realities of daily visits and the sickness brought on by medication stung. I wanted things to end, even when I discovered the next key.

It had been years since I had dreamed of the freedoms my father’s fortune could bring. Parts of Asia held out against bitcoin, but the cost of countries doing business off-network had become prohibitive. Eventually, the fossil conglomerates would give in to the need for solar mining and the provision of universal energy.

It was in a Parisian hospital bed that I discovered ‘can.’ My wardmate, a rough labourer from Oran, found a biography in the hospital library that made me sit up straight. ‘Can’ was repeated in almost every description of my father in his one-time business partner’s book. And it was this Arabian ‘businessman,’ Abdulkarim Rahman, who brokered the deal that robbed the world of infinite solar power. Each page mocked my father as believing only physical impossibilities are impossible. He branded him the ‘can man.’

Drastic

During my recuperation, I spent the final two weeks of my visa stay in Marseille. My days passed with endless algorithm tweaks to reject or accept word orders for the elusive twelve-word sentence my father once wrote.

Food lost its taste, and friends and colleagues in academia had scattered. In-person meetings were often contained to the night hours, but Marseille was not a place to go out after dark. The latest protests had gotten violent, and the government looked likely to topple. My people had always been resilient, but when the option to move and operate a caravan was removed by General Hafiz, part of my spirit died. I resolved to spend my final years in In Salah, however uncomfortable they would be.

My final port of call before returning was Laurent’s office. The eTaxi cast me out into the dusty street, and I wheezed as I climbed the three flights of stairs to his tiny door on Rue Marché. We hadn’t spoken in years, but I was surprised to find a different name about the door. Pascale Dupont, Investigateur.

The assistant I remembered was quite the opposite to Laurent — slow and methodical, short and heavy set.

“Madame,” he said. “I have difficult news.”

Their business had always straddled the law, but I never imagined an ex-officer of the law could be convicted of treason.

“A closed-door trial,” said Pascale. Then he handed over an air-gapped 3D storage file. “Laurent knew you would come for this.”

My mind cast forward to the reams of information he must have built on my father. The patents and technical diagrams he illegally acquired and other clues. I instantly recognised the brand of storage file as a keyword. Drastic.

“How can I thank him?”

“He is dead, madame.” Pascale hung his head. “He survived prison for only two weeks.”

Must

My final years brought me home. In Salah had gained fame for its one group of Tuaregs who refused to leave. The Lakzis owned a house in a desperate condition, not dissimilar to my failing body. By the age of fifty-two, I could no longer walk, but they welcomed me. I pooled my disability allowance and some money I’d gained from selling my father’s watch. We waited for the world to mourn the death of a once great city. We would keep it alive by refusing to move, by refusing to permit its rebranding as an ‘industrial area.’ Now the oil fields were finally drying up, they wanted to dig under the town.

We had managed to eliminate half of the remaining words. Just under 1,000 possible selections for the final two words, but little idea of an order.

The problem was that I was the only English speaker among them, and it took great energy to attempt to teach the meaning of the words and possible grammatical constructions for my father’s sentence.

But soon, patterns began to emerge. Fragments of word pairings and groups. ‘Trigger drastic scheme’ appeared again and again in the permutations. ‘They can’ and ‘When they can’ gave a tantalising glimpse. We ranked sentences in terms of likelihood to form the full key and categorised them by the most likely remaining words. Due to the need for a modal verb, ‘must’ scored highest by our calculations.

In this race to unlock the ledger before In Salah’s destruction, we nosed ahead.

Yet the day of that discovery was my final day in the desert. An air ambulance transported my feeble body to Algiers, and I would never return.

They messaged me — so close. They would unlock the ledger with the final word after my operation. The bitcoin could undo the wrongs of the past, and my father’s sentence would live on.

End

The phrase which began the global revolution first appeared on the wall of a much-disputed oil refinery in the desert outside In Salah, Algeria.

When they can make ecology end, citizen earth must trigger drastic scheme

Soon, the graffiti marked government buildings in Algiers. Activists took to the streets. Governments crumbled and currencies collapsed. Climate groups received massive donations said to come from ‘the one,’ a ledger with a huge stack written off by financiers the world over. The codebreaker credited with unlocking the ledger was unable to witness the transfer of 10,000 coins to the Global Climate Fund due to her death, aged 52, from a congenital condition.

The words of Moussa Ag El Khir now mark each of the millions of panels, which line the ‘dead middle.’ They contribute over 80% of the Earth’s power supply.

To mark the fiftieth anniversary of his death, the World Climate Forum will be held in the town of his birth, In Salah, Algeria. This story, compiled from the diaries of his daughter, Kana Ult El Khir, will be read as the opening address of the conference.

---

This story was originally published in 21 Futures: Tales From the Timechain

To continue the story of the real-world treasure (sats) use the address (it's real).\ Who knows, maybe some zaps will find their way into the wallet...

@ a7f85dfe:27305a2b

在收到二手mini pc之前，先制作USB起动器。

首先，官网下载最新安装器的iso文件，下载地址：

https://www.proxmox.com/en/downloads

第二步，linux系统下使用dd命令制作USB起动器

查找usb路径 lsblk dd命令直接烧录 ``` sudo dd if=/path/to/iso_file.iso of=/dev/sdX bs=4M status=progress

```

@ a7f85dfe:27305a2b

{"coverurl":"https://cdn.nostrcheck.me/a7f85dfe651aaa0b47d69659266f434479e40558a640a308a8f6769627305a2b/e9801593f2ea4560c55a6a2651788620cfe6c587c17c08f0e8023f06e7ffaf31.webp","title":"proxmox安装记录","author":"npub15lu"}

@ ec9bd746:df11a9d0

🌍 Time Window:

🕘 When: Every even week on Sunday at 9:00 PM CET
🗺️ Where: https://cornychat.com/eurocorn

Start: 21:00 CET (Prague, UTC+1)
End: approx. 02:00 CET (Prague, UTC+1, next day)
Duration: usually 5+ hours.

| Region | Local Time Window | Convenience Level | |-----------------------------------------------------|--------------------------------------------|---------------------------------------------------------| | Europe (CET, Prague) 🇨🇿🇩🇪 | 21:00–02:00 CET | ✅ Very Good; evening & night | | East Coast North America (EST) 🇺🇸🇨🇦 | 15:00–20:00 EST | ✅ Very Good; afternoon & early evening | | West Coast North America (PST) 🇺🇸🇨🇦 | 12:00–17:00 PST | ✅ Very Good; midday & afternoon | | Central America (CST) 🇲🇽🇨🇷🇬🇹 | 14:00–19:00 CST | ✅ Very Good; afternoon & evening | | South America West (Peru/Colombia PET/COT) 🇵🇪🇨🇴 | 15:00–20:00 PET/COT | ✅ Very Good; afternoon & evening | | South America East (Brazil/Argentina/Chile, BRT/ART/CLST) 🇧🇷🇦🇷🇨🇱 | 17:00–22:00 BRT/ART/CLST | ✅ Very Good; early evening | | United Kingdom/Ireland (GMT) 🇬🇧🇮🇪 | 20:00–01:00 GMT | ✅ Very Good; evening hours (midnight convenient) | | Eastern Europe (EET) 🇷🇴🇬🇷🇺🇦 | 22:00–03:00 EET | ✅ Good; late evening & early night (slightly late) | | Africa (South Africa, SAST) 🇿🇦 | 22:00–03:00 SAST | ✅ Good; late evening & overnight (late-night common) | | New Zealand (NZDT) 🇳🇿 | 09:00–14:00 NZDT (next day) | ✅ Good; weekday morning & afternoon | | Australia (AEDT, Sydney) 🇦🇺 | 07:00–12:00 AEDT (next day) | ✅ Good; weekday morning to noon | | East Africa (Kenya, EAT) 🇰🇪 | 23:00–04:00 EAT | ⚠️ Slightly late (night hours; late night common) | | Russia (Moscow, MSK) 🇷🇺 | 23:00–04:00 MSK | ⚠️ Slightly late (join at start is fine, very late night) | | Middle East (UAE, GST) 🇦🇪🇴🇲 | 00:00–05:00 GST (next day) | ⚠️ Late night start (midnight & early morning, but shorter attendance plausible)| | Japan/Korea (JST/KST) 🇯🇵🇰🇷 | 05:00–10:00 JST/KST (next day) | ⚠️ Early; convenient joining from ~07:00 onwards possible | | China (Beijing, CST) 🇨🇳 | 04:00–09:00 CST (next day) | ❌ Challenging; very early morning start (better ~07:00 onwards) | | India (IST) 🇮🇳 | 01:30–06:30 IST (next day) | ❌ Very challenging; overnight timing typically difficult|

---

@ fd06f542:8d6d54cd

{"coverurl":"https://cdn.nostrcheck.me/fd06f542bc6c06a39881810de917e6c5d277dfb51689a568ad7b7a548d6d54cd/1dd58d181d40edb7df942b5b16be3f82e95348a471d5a3620a9585f0af784fee.webp","title":"nostr资源收集","author":"nostrbook"}

@ fd06f542:8d6d54cd

• 首页
• 第一章、开发者指南
• 第二章、使用教程

@ fd06f542:8d6d54cd

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: async window.nostr.nip04.encrypt(pubkey, plaintext): string // returns ciphertext and iv as specified in nip-04 (deprecated) async window.nostr.nip04.decrypt(pubkey, ciphertext): string // takes ciphertext and iv as specified in nip-04 (deprecated) async window.nostr.nip44.encrypt(pubkey, plaintext): string // returns ciphertext as specified in nip-44 async window.nostr.nip44.decrypt(pubkey, ciphertext): string // takes ciphertext as specified in nip-44

Recommendation to Extension Authors

To make sure that the window.nostr is available to nostr clients on page load, the authors who create Chromium and Firefox extensions should load their scripts by specifying "run_at": "document_end" in the extension's manifest.

Implementation

See https://github.com/aljazceru/awesome-nostr#nip-07-browser-extensions.

@ fd06f542:8d6d54cd

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.

Other types of clients can still get fancy and use other derivation paths for their own other purposes.

Test vectors

mnemonic: leader monkey parrot ring guide accident before fence cannon height naive bean\ private key (hex): 7f7ff03d123792d6ac594bfa67bf6d0c0ab55b6b1fdb6249303fe861f1ccba9a\ nsec: nsec10allq0gjx7fddtzef0ax00mdps9t2kmtrldkyjfs8l5xruwvh2dq0lhhkp\ public key (hex): 17162c921dc4d2518f9a101db33695df1afb56ab82f5ff3e5da6eec3ca5cd917\ npub: npub1zutzeysacnf9rru6zqwmxd54mud0k44tst6l70ja5mhv8jjumytsd2x7nu

---

mnemonic: what bleak badge arrange retreat wolf trade produce cricket blur garlic valid proud rude strong choose busy staff weather area salt hollow arm fade\ private key (hex): c15d739894c81a2fcfd3a2df85a0d2c0dbc47a280d092799f144d73d7ae78add\ nsec: nsec1c9wh8xy5eqdzln7n5t0ctgxjcrdug73gp5yj0x03gntn67h83twssdfhel\ public key (hex): d41b22899549e1f3d335a31002cfd382174006e166d3e658e3a5eecdb6463573\ npub: npub16sdj9zv4f8sl85e45vgq9n7nsgt5qphpvmf7vk8r5hhvmdjxx4es8rq74h

@ fd06f542:8d6d54cd

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>/.well-known/nostr.json?name=<local-part>.

The result should be a JSON document object with a key "names" that should then be a mapping of names to hex formatted public keys. If the public key for the given <name> matches the pubkey from the user metadata event, the client then concludes that the given pubkey can indeed be referenced by its identifier.

Example

If a client sees an event like this:

jsonc { "pubkey": "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9", "kind": 0, "content": "{\"name\": \"bob\", \"nip05\": \"bob@example.com\"}" // other fields... }

It will make a GET request to https://example.com/.well-known/nostr.json?name=bob and get back a response that will look like

json { "names": { "bob": "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9" } }

or with the recommended "relays" attribute:

json { "names": { "bob": "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9" }, "relays": { "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9": [ "wss://relay.example.com", "wss://relay2.example.com" ] } }

If the pubkey matches the one given in "names" (as in the example above) that means the association is right and the "nip05" identifier is valid and can be displayed.

The recommended "relays" attribute may contain an object with public keys as properties and arrays of relay URLs as values. When present, that can be used to help clients learn in which relays the specific user may be found. Web servers which serve /.well-known/nostr.json files dynamically based on the query string SHOULD also serve the relays data for any name they serve in the same reply when that is available.

Finding users from their NIP-05 identifier

A client may implement support for finding users' public keys from internet identifiers, the flow is the same as above, but reversed: first the client fetches the well-known URL and from there it gets the public key of the user, then it tries to fetch the kind 0 event for that user and check if it has a matching "nip05".

Notes

Identification, not verification

The NIP-05 is not intended to verify a user, but only to identify them, for the purpose of facilitating the exchange of a contact or their search.
Exceptions are people who own (e.g., a company) or are connected (e.g., a project) to a well-known domain, who can exploit NIP-05 as an attestation of their relationship with it, and thus to the organization behind it, thereby gaining an element of trust.

User discovery implementation suggestion

A client can use this to allow users to search other profiles. If a client has a search box or something like that, a user may be able to type "bob@example.com" there and the client would recognize that and do the proper queries to obtain a pubkey and suggest that to the user.

Clients must always follow public keys, not NIP-05 addresses

For example, if after finding that bob@bob.com has the public key abc...def, the user clicks a button to follow that profile, the client must keep a primary reference to abc...def, not bob@bob.com. If, for any reason, the address https://bob.com/.well-known/nostr.json?name=bob starts returning the public key 1d2...e3f at any time in the future, the client must not replace abc...def in his list of followed profiles for the user (but it should stop displaying "bob@bob.com" for that user, as that will have become an invalid "nip05" property).

Public keys must be in hex format

Keys must be returned in hex format. Keys in NIP-19 npub format are only meant to be used for display in client UIs, not in this NIP.

Showing just the domain as an identifier

Clients may treat the identifier _@domain as the "root" identifier, and choose to display it as just the <domain>. For example, if Bob owns bob.com, he may not want an identifier like bob@bob.com as that is redundant. Instead, Bob can use the identifier _@bob.com and expect Nostr clients to show and treat that as just bob.com for all purposes.

Reasoning for the /.well-known/nostr.json?name=<local-part> format

By adding the <local-part> as a query string instead of as part of the path, the protocol can support both dynamic servers that can generate JSON on-demand and static servers with a JSON file in it that may contain multiple names.

Allowing access from JavaScript apps

JavaScript Nostr apps may be restricted by browser CORS policies that prevent them from accessing /.well-known/nostr.json on the user's domain. When CORS prevents JS from loading a resource, the JS program sees it as a network failure identical to the resource not existing, so it is not possible for a pure-JS app to tell the user for certain that the failure was caused by a CORS issue. JS Nostr apps that see network failures requesting /.well-known/nostr.json files may want to recommend to users that they check the CORS policy of their servers, e.g.:

bash $ curl -sI https://example.com/.well-known/nostr.json?name=bob | grep -i ^Access-Control Access-Control-Allow-Origin: *

Users should ensure that their /.well-known/nostr.json is served with the HTTP header Access-Control-Allow-Origin: * to ensure it can be validated by pure JS apps running in modern browsers.

Security Constraints

The /.well-known/nostr.json endpoint MUST NOT return any HTTP redirects.

Fetchers MUST ignore any HTTP redirects given by the /.well-known/nostr.json endpoint.

@ fd06f542:8d6d54cd

什么是nostrbook？

---

nostrbook 是基于nostr 社区技术存储在 nostr relay server上的长文(30023)文章。 查看浏览，采用的是 docsify 技术。

整个网站技术不会占用部署服务器太多的存储空间,可以实现轻量级部署。

任何人可以部署服务器，或者本地部署 查看本站所有的书籍。

nostrbook 可以服务哪些人？

---

• 开发者，如果你想二次开发，看第一章、开发者指南
• 写书作者，看第二章、使用教程
• 读者 你就直接点开看。

nostrbook未来如何发展？

---

• 可能会增加 blog功能，有些时候你就想随心写点日志，那么用blog功能也可以。
• 点赞互动、留言功能。

@ fd06f542:8d6d54cd

什么是nostrbook？

---

nostrbook 是基于nostr 社区技术存储在 nostr relay server上的长文(30023)文章。 查看浏览，采用的是 docsify 技术。整个网站技术无须部署服务器占用太多的存储空间。 可以实现轻量级部署。

@ fd06f542:8d6d54cd

{"coverurl":"https://cdn.nostrcheck.me/fd06f542bc6c06a39881810de917e6c5d277dfb51689a568ad7b7a548d6d54cd/232dd9c092e023beecb5410052bd48add702765258dcc66f176a56f02b09cf6a.webp","title":"NostrBook站点日记","author":"nostrbook"}

@ fd06f542:8d6d54cd

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". The format is the following: "content": "<encrypted_text>?iv=<initialization_vector>".

tags MUST contain an entry identifying the receiver of the message (such that relays may naturally forward this event to them), in the form ["p", "<pubkey, as a hex string>"].

tags MAY contain an entry identifying the previous message in a conversation or a message we are explicitly replying to (such that contextual, more organized conversations may happen), in the form ["e", "<event_id>"].

Note: By default in the libsecp256k1 ECDH implementation, the secret is the SHA256 hash of the shared point (both X and Y coordinates). In Nostr, only the X coordinate of the shared point is used as the secret and it is NOT hashed. If using libsecp256k1, a custom function that copies the X coordinate must be passed as the hashfp argument in secp256k1_ecdh. See here.

Code sample for generating such an event in JavaScript:

```js import crypto from 'crypto' import * as secp from '@noble/secp256k1'

let sharedPoint = secp.getSharedSecret(ourPrivateKey, '02' + theirPublicKey) let sharedX = sharedPoint.slice(1, 33)

let iv = crypto.randomFillSync(new Uint8Array(16)) var cipher = crypto.createCipheriv( 'aes-256-cbc', Buffer.from(sharedX), iv ) let encryptedMessage = cipher.update(text, 'utf8', 'base64') encryptedMessage += cipher.final('base64') let ivBase64 = Buffer.from(iv.buffer).toString('base64')

let event = { pubkey: ourPubKey, created_at: Math.floor(Date.now() / 1000), kind: 4, tags: [['p', theirPublicKey]], content: encryptedMessage + '?iv=' + ivBase64 } ```

Security Warning

This standard does not go anywhere near what is considered the state-of-the-art in encrypted communication between peers, and it leaks metadata in the events, therefore it must not be used for anything you really need to keep secret, and only with relays that use AUTH to restrict who can fetch your kind:4 events.

Client Implementation Warning

Clients should not search and replace public key or note references from the .content. If processed like a regular text note (where @npub... is replaced with #[0] with a ["p", "..."] tag) the tags are leaked and the mentioned user will receive the message in their inbox.

@ fd06f542:8d6d54cd

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:

json { "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. This file SHOULD contain a single Bitcoin attestation (as not more than one valid attestation is necessary and less bytes is better than more) and no reference to "pending" attestations since they are useless in this context.

Example OpenTimestamps proof verification flow

Using nak, jq and ots:

```bash ~> nak req -i e71c6ea722987debdb60f81f9ea4f604b5ac0664120dd64fb9d23abc4ec7c323 wss://nostr-pub.wellorder.net | jq -r .content | ots verify

using an esplora server at https://blockstream.info/api - sequence ending on block 810391 is valid timestamp validated at block [810391] ```

@ fd06f542:8d6d54cd

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:

json { "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. This file SHOULD contain a single Bitcoin attestation (as not more than one valid attestation is necessary and less bytes is better than more) and no reference to "pending" attestations since they are useless in this context.

Example OpenTimestamps proof verification flow

Using nak, jq and ots:

```bash ~> nak req -i e71c6ea722987debdb60f81f9ea4f604b5ac0664120dd64fb9d23abc4ec7c323 wss://nostr-pub.wellorder.net | jq -r .content | ots verify

using an esplora server at https://blockstream.info/api - sequence ending on block 810391 is valid timestamp validated at block [810391] ```

@ db11b320:05c5f7af

magnet:?xt=urn:btih:9BAC9A3F98803AEA1EB28A0B60A562D7E3779710

@ 0d788b5e:c99ddea5

• 首页

• 第一章、 第一章标题

• 第二章、 第二章标题

@ 0d788b5e:c99ddea5

这是首页内容

@ fd06f542:8d6d54cd

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.e., ["p", <32-bytes hex key>, <main relay URL>, <petname>].

The .content is not used.

For example:

jsonc { "kind": 3, "tags": [ ["p", "91cf9..4e5ca", "wss://alicerelay.com/", "alice"], ["p", "14aeb..8dad4", "wss://bobrelay.com/nostr", "bob"], ["p", "612ae..e610f", "ws://carolrelay.com/ws", "carol"] ], "content": "", // other fields... }

Every new following list that gets published overwrites the past ones, so it should contain all entries. Relays and clients SHOULD delete past following lists as soon as they receive a new one.

Whenever new follows are added to an existing list, clients SHOULD append them to the end of the list, so they are stored in chronological order.

Uses

Follow list backup

If one believes a relay will store their events for sufficient time, they can use this kind-3 event to backup their following list and recover on a different device.

Profile discovery and context augmentation

A client may rely on the kind-3 event to display a list of followed people by profiles one is browsing; make lists of suggestions on who to follow based on the follow lists of other people one might be following or browsing; or show the data in other contexts.

Relay sharing

A client may publish a follow list with good relays for each of their follows so other clients may use these to update their internal relay lists if needed, increasing censorship-resistance.

Petname scheme

The data from these follow lists can be used by clients to construct local "petname" tables derived from other people's follow lists. This alleviates the need for global human-readable names. For example:

A user has an internal follow list that says

json [ ["p", "21df6d143fb96c2ec9d63726bf9edc71", "", "erin"] ]

And receives two follow lists, one from 21df6d143fb96c2ec9d63726bf9edc71 that says

json [ ["p", "a8bb3d884d5d90b413d9891fe4c4e46d", "", "david"] ]

and another from a8bb3d884d5d90b413d9891fe4c4e46d that says

json [ ["p", "f57f54057d2a7af0efecc8b0b66f5708", "", "frank"] ]

When the user sees 21df6d143fb96c2ec9d63726bf9edc71 the client can show erin instead; When the user sees a8bb3d884d5d90b413d9891fe4c4e46d the client can show david.erin instead; When the user sees f57f54057d2a7af0efecc8b0b66f5708 the client can show frank.david.erin instead.

@ fd06f542:8d6d54cd

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:

jsonc { "id": <32-bytes lowercase hex-encoded sha256 of the serialized event data>, "pubkey": <32-bytes lowercase hex-encoded public key of the event creator>, "created_at": <unix timestamp in seconds>, "kind": <integer between 0 and 65535>, "tags": [ [<arbitrary string>...], // ... ], "content": <arbitrary string>, "sig": <64-bytes lowercase hex of the signature of the sha256 hash of the serialized event data, which is the same as the "id" field> }

To obtain the event.id, we sha256 the serialized event. The serialization is done over the UTF-8 JSON-serialized string (which is described below) of the following structure:

[ 0, <pubkey, as a lowercase hex string>, <created_at, as a number>, <kind, as a number>, <tags, as an array of arrays of non-null strings>, <content, as a string> ]

To prevent implementation differences from creating a different event ID for the same event, the following rules MUST be followed while serializing: - UTF-8 should be used for encoding. - Whitespace, line breaks or other unnecessary formatting should not be included in the output JSON. - The following characters in the content field must be escaped as shown, and all other characters must be included verbatim: - A line break (0x0A), use \n - A double quote (0x22), use \" - A backslash (0x5C), use \\ - A carriage return (0x0D), use \r - A tab character (0x09), use \t - A backspace, (0x08), use \b - A form feed, (0x0C), use \f

Tags

Each tag is an array of one or more strings, with some conventions around them. Take a look at the example below:

jsonc { "tags": [ ["e", "5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36", "wss://nostr.example.com"], ["p", "f7234bd4c1394dda46d09f35bd384dd30cc552ad5541990f98844fb06676e9ca"], ["a", "30023:f7234bd4c1394dda46d09f35bd384dd30cc552ad5541990f98844fb06676e9ca:abcd", "wss://nostr.example.com"], ["alt", "reply"], // ... ], // ... }

The first element of the tag array is referred to as the tag name or key and the second as the tag value. So we can safely say that the event above has an e tag set to "5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36", an alt tag set to "reply" and so on. All elements after the second do not have a conventional name.

This NIP defines 3 standard tags that can be used across all event kinds with the same meaning. They are as follows:

• The e tag, used to refer to an event: ["e", <32-bytes lowercase hex of the id of another event>, <recommended relay URL, optional>, <32-bytes lowercase hex of the author's pubkey, optional>]
• The p tag, used to refer to another user: ["p", <32-bytes lowercase hex of a pubkey>, <recommended relay URL, optional>]
• The a tag, used to refer to an addressable or replaceable event
  • for an addressable event: ["a", "<kind integer>:<32-bytes lowercase hex of a pubkey>:<d tag value>", <recommended relay URL, optional>]
  • for a normal replaceable event: ["a", "<kind integer>:<32-bytes lowercase hex of a pubkey>:", <recommended relay URL, optional>] (note: include the trailing colon)

As a convention, all single-letter (only english alphabet letters: a-z, A-Z) key tags are expected to be indexed by relays, such that it is possible, for example, to query or subscribe to events that reference the event "5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36" by using the {"#e": ["5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36"]} filter. Only the first value in any given tag is indexed.

Kinds

Kinds specify how clients should interpret the meaning of each event and the other fields of each event (e.g. an "r" tag may have a meaning in an event of kind 1 and an entirely different meaning in an event of kind 10002). Each NIP may define the meaning of a set of kinds that weren't defined elsewhere. NIP-10, for instance, especifies the kind:1 text note for social media applications.

This NIP defines one basic kind:

• 0: user metadata: the content is set to a stringified JSON object {name: <nickname or full name>, about: <short bio>, picture: <url of the image>} describing the user who created the event. Extra metadata fields may be set. A relay may delete older events once it gets a new one for the same pubkey.

And also a convention for kind ranges that allow for easier experimentation and flexibility of relay implementation:

• for kind n such that 1000 <= n < 10000 || 4 <= n < 45 || n == 1 || n == 2, events are regular, which means they're all expected to be stored by relays.
• for kind n such that 10000 <= n < 20000 || n == 0 || n == 3, events are replaceable, which means that, for each combination of pubkey and kind, only the latest event MUST be stored by relays, older versions MAY be discarded.
• for kind n such that 20000 <= n < 30000, events are ephemeral, which means they are not expected to be stored by relays.
• for kind n such that 30000 <= n < 40000, events are addressable by their kind, pubkey and d tag value -- which means that, for each combination of kind, pubkey and the d tag value, only the latest event MUST be stored by relays, older versions MAY be discarded.

In case of replaceable events with the same timestamp, the event with the lowest id (first in lexical order) should be retained, and the other discarded.

When answering to REQ messages for replaceable events such as {"kinds":[0],"authors":[<hex-key>]}, even if the relay has more than one version stored, it SHOULD return just the latest one.

These are just conventions and relay implementations may differ.

Communication between clients and relays

Relays expose a websocket endpoint to which clients can connect. Clients SHOULD open a single websocket connection to each relay and use it for all their subscriptions. Relays MAY limit number of connections from specific IP/client/etc.

From client to relay: sending events and creating subscriptions

Clients can send 3 types of messages, which must be JSON arrays, according to the following patterns:

• ["EVENT", <event JSON as defined above>], used to publish events.
• ["REQ", <subscription_id>, <filters1>, <filters2>, ...], used to request events and subscribe to new updates.
• ["CLOSE", <subscription_id>], used to stop previous subscriptions.

<subscription_id> is an arbitrary, non-empty string of max length 64 chars. It represents a subscription per connection. Relays MUST manage <subscription_id>s independently for each WebSocket connection. <subscription_id>s are not guaranteed to be globally unique.

<filtersX> is a JSON object that determines what events will be sent in that subscription, it can have the following attributes:

json { "ids": <a list of event ids>, "authors": <a list of lowercase pubkeys, the pubkey of an event must be one of these>, "kinds": <a list of a kind numbers>, "#<single-letter (a-zA-Z)>": <a list of tag values, for #e — a list of event ids, for #p — a list of pubkeys, etc.>, "since": <an integer unix timestamp in seconds. Events must have a created_at >= to this to pass>, "until": <an integer unix timestamp in seconds. Events must have a created_at <= to this to pass>, "limit": <maximum number of events relays SHOULD return in the initial query> }

Upon receiving a REQ message, the relay SHOULD return events that match the filter. Any new events it receives SHOULD be sent to that same websocket until the connection is closed, a CLOSE event is received with the same <subscription_id>, or a new REQ is sent using the same <subscription_id> (in which case a new subscription is created, replacing the old one).

Filter attributes containing lists (ids, authors, kinds and tag filters like #e) are JSON arrays with one or more values. At least one of the arrays' values must match the relevant field in an event for the condition to be considered a match. For scalar event attributes such as authors and kind, the attribute from the event must be contained in the filter list. In the case of tag attributes such as #e, for which an event may have multiple values, the event and filter condition values must have at least one item in common.

The ids, authors, #e and #p filter lists MUST contain exact 64-character lowercase hex values.

The since and until properties can be used to specify the time range of events returned in the subscription. If a filter includes the since property, events with created_at greater than or equal to since are considered to match the filter. The until property is similar except that created_at must be less than or equal to until. In short, an event matches a filter if since <= created_at <= until holds.

All conditions of a filter that are specified must match for an event for it to pass the filter, i.e., multiple conditions are interpreted as && conditions.

A REQ message may contain multiple filters. In this case, events that match any of the filters are to be returned, i.e., multiple filters are to be interpreted as || conditions.

The limit property of a filter is only valid for the initial query and MUST be ignored afterwards. When limit: n is present it is assumed that the events returned in the initial query will be the last n events ordered by the created_at. Newer events should appear first, and in the case of ties the event with the lowest id (first in lexical order) should be first. It is safe to return less events than limit specifies, but it is expected that relays do not return (much) more events than requested so clients don't get unnecessarily overwhelmed by data.

From relay to client: sending events and notices

Relays can send 5 types of messages, which must also be JSON arrays, according to the following patterns:

• ["EVENT", <subscription_id>, <event JSON as defined above>], used to send events requested by clients.
• ["OK", <event_id>, <true|false>, <message>], used to indicate acceptance or denial of an EVENT message.
• ["EOSE", <subscription_id>], used to indicate the end of stored events and the beginning of events newly received in real-time.
• ["CLOSED", <subscription_id>, <message>], used to indicate that a subscription was ended on the server side.
• ["NOTICE", <message>], used to send human-readable error messages or other things to clients.

This NIP defines no rules for how NOTICE messages should be sent or treated.

• EVENT messages MUST be sent only with a subscription ID related to a subscription previously initiated by the client (using the REQ message above).
• OK messages MUST be sent in response to EVENT messages received from clients, they must have the 3rd parameter set to true when an event has been accepted by the relay, false otherwise. The 4th parameter MUST always be present, but MAY be an empty string when the 3rd is true, otherwise it MUST be a string formed by a machine-readable single-word prefix followed by a : and then a human-readable message. Some examples:
• ["OK", "b1a649ebe8...", true, ""]
• ["OK", "b1a649ebe8...", true, "pow: difficulty 25>=24"]
• ["OK", "b1a649ebe8...", true, "duplicate: already have this event"]
• ["OK", "b1a649ebe8...", false, "blocked: you are banned from posting here"]
• ["OK", "b1a649ebe8...", false, "blocked: please register your pubkey at https://my-expensive-relay.example.com"]
• ["OK", "b1a649ebe8...", false, "rate-limited: slow down there chief"]
• ["OK", "b1a649ebe8...", false, "invalid: event creation date is too far off from the current time"]
• ["OK", "b1a649ebe8...", false, "pow: difficulty 26 is less than 30"]
• ["OK", "b1a649ebe8...", false, "restricted: not allowed to write."]
• ["OK", "b1a649ebe8...", false, "error: could not connect to the database"]
• CLOSED messages MUST be sent in response to a REQ when the relay refuses to fulfill it. It can also be sent when a relay decides to kill a subscription on its side before a client has disconnected or sent a CLOSE. This message uses the same pattern of OK messages with the machine-readable prefix and human-readable message. Some examples:
• ["CLOSED", "sub1", "unsupported: filter contains unknown elements"]
• ["CLOSED", "sub1", "error: could not connect to the database"]
• ["CLOSED", "sub1", "error: shutting down idle subscription"]
• The standardized machine-readable prefixes for OK and CLOSED are: duplicate, pow, blocked, rate-limited, invalid, restricted, and error for when none of that fits.

@ fd06f542:8d6d54cd

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.nostr capability for web browsers
• NIP-08: Handling Mentions --- unrecommended: deprecated in favor of NIP-27
• NIP-09: Event Deletion Request
• NIP-10: Text Notes and Threads
• NIP-11: Relay Information Document
• NIP-13: Proof of Work
• NIP-14: Subject tag in text events
• NIP-15: Nostr Marketplace (for resilient marketplaces)
• NIP-17: Private Direct Messages
• NIP-18: Reposts
• NIP-19: bech32-encoded entities
• NIP-21: nostr: URI scheme
• NIP-22: Comment
• NIP-23: Long-form Content
• NIP-24: Extra metadata fields and tags
• NIP-25: Reactions
• NIP-26: Delegated Event Signing
• NIP-27: Text Note References
• NIP-28: Public Chat
• NIP-29: Relay-based Groups
• NIP-30: Custom Emoji
• NIP-31: Dealing with Unknown Events
• NIP-32: Labeling
• NIP-34: git stuff
• NIP-35: Torrents
• NIP-36: Sensitive Content
• NIP-37: Draft Events
• NIP-38: User Statuses
• NIP-39: External Identities in Profiles
• NIP-40: Expiration Timestamp
• NIP-42: Authentication of clients to relays
• NIP-44: Encrypted Payloads (Versioned)
• NIP-45: Counting results
• NIP-46: Nostr Remote Signing
• NIP-47: Nostr Wallet Connect
• NIP-48: Proxy Tags
• NIP-49: Private Key Encryption
• NIP-50: Search Capability
• NIP-51: Lists
• NIP-52: Calendar Events
• NIP-53: Live Activities
• NIP-54: Wiki
• NIP-55: Android Signer Application
• NIP-56: Reporting
• NIP-57: Lightning Zaps
• NIP-58: Badges
• NIP-59: Gift Wrap
• NIP-60: Cashu Wallet
• NIP-61: Nutzaps
• NIP-62: Request to Vanish
• NIP-64: Chess (PGN)
• NIP-65: Relay List Metadata
• NIP-66: Relay Discovery and Liveness Monitoring
• NIP-68: Picture-first feeds
• NIP-69: Peer-to-peer Order events
• NIP-70: Protected Events
• NIP-71: Video Events
• NIP-72: Moderated Communities
• NIP-73: External Content IDs
• NIP-75: Zap Goals
• NIP-78: Application-specific data
• NIP-84: Highlights
• NIP-86: Relay Management API
• NIP-88: Polls
• NIP-89: Recommended Application Handlers
• NIP-90: Data Vending Machines
• NIP-92: Media Attachments
• NIP-94: File Metadata
• NIP-96: HTTP File Storage Integration
• NIP-98: HTTP Auth
• NIP-99: Classified Listings
• NIP-7D: Threads
• NIP-C7: Chats

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 | | 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 | | 10013 | Private event relay list | 37 | | 10015 | Interests list | 51 | | 10019 | Nutzap Mint Recommendation | 61 | | 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 |

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 | -- | 32 | | 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 | | description | description | -- | 34, 57, 58 | | emoji | shortcode, image URL | -- | 30 | | encrypted | -- | -- | 90 | | 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 | | lnurl | bech32 encoded lnurl | -- | 57 | | location | location string | -- | 52, 99 | | name | name | -- | 34, 58, 72 | | 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 | | relay | relay url | -- | 42, 17 | | relays | relay list | -- | 57 | | server | file storage server url | -- | 96 | | subject | subject | -- | 14, 17, 34 | | summary | summary | -- | 23, 52 | | thumb | badge thumbnail | dimensions in pixels | 58 | | title | article title | -- | 23 | | 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

@ fd06f542:8d6d54cd

{"coverurl":"https://cdn.nostrcheck.me/fd06f542bc6c06a39881810de917e6c5d277dfb51689a568ad7b7a548d6d54cd/5ad7189d30c9b49aa61652d98ac7853217b7e445f863be09f9745c49df9f514c.webp","title":"Nostr protocol","author":"fiatjaf"}

@ 872982aa:8fb54cfe

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:

json { "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. This file SHOULD contain a single Bitcoin attestation (as not more than one valid attestation is necessary and less bytes is better than more) and no reference to "pending" attestations since they are useless in this context.

Example OpenTimestamps proof verification flow

Using nak, jq and ots:

```bash ~> nak req -i e71c6ea722987debdb60f81f9ea4f604b5ac0664120dd64fb9d23abc4ec7c323 wss://nostr-pub.wellorder.net | jq -r .content | ots verify

using an esplora server at https://blockstream.info/api - sequence ending on block 810391 is valid timestamp validated at block [810391] ```

@ 872982aa:8fb54cfe

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:

json { "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. This file SHOULD contain a single Bitcoin attestation (as not more than one valid attestation is necessary and less bytes is better than more) and no reference to "pending" attestations since they are useless in this context.

Example OpenTimestamps proof verification flow

Using nak, jq and ots:

```bash ~> nak req -i e71c6ea722987debdb60f81f9ea4f604b5ac0664120dd64fb9d23abc4ec7c323 wss://nostr-pub.wellorder.net | jq -r .content | ots verify

using an esplora server at https://blockstream.info/api - sequence ending on block 810391 is valid timestamp validated at block [810391] ```

@ 872982aa:8fb54cfe

• 首页

• 第一章、 NIP-01: Basic protocol flow description

• 第二章、 NIP-02: Follow List

• 第三章、NIP-03: OpenTimestamps Attestations for Events

@ 57d1a264:69f1fee1

Recently we shared an update for a new Open Cash Foundation website https://stacker.news/items/811604/r/Design_r Today a new logo by Vladimir Krstić!

File available for review at https://www.figma.com/design/Yxb4JEsjHYSibY06T8piB7/OpenCash%3A-Logo?node-id=151-249&p=f&t=FYyeTBkJznCKdbd7-0

https://primal.net/e/nevent1qvzqqqqqqypzqhzsmgfjj3l68068t84e0rtcfkcjh2k3c0jmdft4gy9wke2x8x6tqyg8wumn8ghj7efwdehhxtnvdakz7qgkwaehxw309ajkgetw9ehx7um5wghxcctwvshszrnhwden5te0dehhxtnvdakz7qpqryz9rj0wgshykjuzqksxxs50l7jfnwyvtkfmdvmudrg92s3xuxys8fqzr7

originally posted at https://stacker.news/items/914665