事件系統詳解

{
  "id": "32字節十六進制，事件的唯一標識符",
  "pubkey": "32字節十六進制，創建者的公鑰",
  "created_at": 1234567890,  // Unix 時間戳（秒）
  "kind": 1,                 // 事件類型
  "tags": [                  // 標籤陣列
    ["e", "引用的事件ID", "中繼器URL"],
    ["p", "提及的公鑰"],
    ["t", "hashtag"],
    ...
  ],
  "content": "事件的主要內容",
  "sig": "64字節十六進制 Schnorr 簽名"
}

// 事件 ID 計算步驟

1. 序列化事件（不包含 id 和 sig）:
   [
     0,              // 固定值
     pubkey,         // 十六進制公鑰
     created_at,     // 整數時間戳
     kind,           // 整數類型
     tags,           // 標籤陣列
     content         // 內容字串
   ]

2. 計算 SHA256:
   id = sha256(JSON.stringify(serialized))

JavaScript 範例:
const serialized = JSON.stringify([
  0,
  event.pubkey,
  event.created_at,
  event.kind,
  event.tags,
  event.content
]);
const id = sha256(serialized);

Kind 範圍分類：

0-9999:     常規事件（Regular Events）
10000-19999: 可替換事件（Replaceable Events）
20000-29999: 臨時事件（Ephemeral Events）
30000-39999: 參數化可替換事件（Addressable Events）

行為差異：
- 常規事件：每個都是獨立的，永久保存
- 可替換事件：同 pubkey+kind 只保留最新
- 臨時事件：不儲存，僅轉發
- 參數化可替換：同 pubkey+kind+d標籤 只保留最新

參數化可替換事件使用 "d" 標籤作為標識符：

Kind 30023: 長篇文章
{
  "kind": 30023,
  "tags": [
    ["d", "my-article-slug"],  // 文章標識符
    ["title", "文章標題"],
    ["published_at", "1234567890"]
  ],
  "content": "文章的 Markdown 內容..."
}

同一用戶的 kind:30023 + d:"my-article-slug" 只會保留最新版本
這樣可以實現文章的更新功能

常見參數化可替換事件：
- Kind 30000: 自訂列表
- Kind 30023: 長篇文章
- Kind 30078: 應用特定數據

常用標籤類型：

["e", "<event_id>", "<relay_url>", "<marker>"]
  引用事件，marker 可以是 "reply", "root", "mention"

["p", "<pubkey>", "<relay_url>"]
  提及用戶

["a", "<kind>:<pubkey>:<d-tag>", "<relay_url>"]
  引用參數化可替換事件

["t", "hashtag"]
  話題標籤

["d", "identifier"]
  參數化可替換事件的標識符

["r", "url"]
  引用外部 URL

["nonce", "<nonce>", "<difficulty>"]
  工作量證明（NIP-13）

範例：回覆貼文
{
  "kind": 1,
  "tags": [
    ["e", "原始貼文ID", "wss://relay.example", "root"],
    ["e", "直接回覆的貼文ID", "wss://relay.example", "reply"],
    ["p", "原作者公鑰"]
  ],
  "content": "我的回覆..."
}

事件生命週期：

1. 創建 (Creation)
   ┌─────────────────────────────┐
   │ 客戶端構建事件              │
   │ - 設定 kind, content, tags │
   │ - 計算 created_at          │
   └─────────────────────────────┘
              ↓
2. 簽名 (Signing)
   ┌─────────────────────────────┐
   │ 計算事件 ID (SHA256)        │
   │ 使用私鑰簽名 ID             │
   │ 填入 id 和 sig 欄位         │
   └─────────────────────────────┘
              ↓
3. 發布 (Publishing)
   ┌─────────────────────────────┐
   │ 發送 ["EVENT", event]      │
   │ 到多個中繼器                │
   └─────────────────────────────┘
              ↓
4. 驗證 (Validation)
   ┌─────────────────────────────┐
   │ 中繼器驗證：                │
   │ - ID 計算正確？             │
   │ - 簽名有效？                │
   │ - 符合中繼器政策？          │
   └─────────────────────────────┘
              ↓
5. 儲存/轉發 (Storage/Relay)
   ┌─────────────────────────────┐
   │ 回覆 ["OK", id, true, ""]  │
   │ 儲存事件                    │
   │ 轉發給訂閱者                │
   └─────────────────────────────┘

刪除請求（Kind 5）：

{
  "kind": 5,
  "tags": [
    ["e", "要刪除的事件ID1"],
    ["e", "要刪除的事件ID2"],
    ["a", "30023:pubkey:article-id"]  // 刪除參數化事件
  ],
  "content": "刪除原因（可選）"
}

重要注意事項：
- 只能刪除自己的事件
- 中繼器可以選擇是否遵守刪除請求
- 已被其他用戶快取的事件無法真正刪除
- 這是「請求刪除」而非「強制刪除」

驗證步驟：

1. 驗證 ID
   - 重新計算 SHA256
   - 比對 id 欄位

2. 驗證簽名
   - 使用 pubkey 驗證 Schnorr 簽名
   - 簽名必須對應事件 ID

3. 驗證格式
   - kind 是非負整數
   - created_at 是合理的時間戳
   - tags 格式正確

JavaScript 範例（使用 nostr-tools）：
import { verifySignature, getEventHash } from 'nostr-tools'

function validateEvent(event) {
  // 驗證 ID
  const expectedId = getEventHash(event);
  if (event.id !== expectedId) {
    return false;
  }

  // 驗證簽名
  return verifySignature(event);
}