訂閱
REQ 裡的每個 filter 都必須說清楚要找什麼。會把整條車道倒出來的 filter 一律拒絕。
接受與拒絕的 filter
| Filter | 結果 |
|---|---|
{"kinds":[1078], "#t":["lobby"]} | 接受——#p 以外的任何標籤都可以 |
{"kinds":[31081], "#d":["deck"]} | 接受 |
{"authors":["<pubkey>"]} | 接受（最多 1024 位作者） |
{"#p":["<你的 pubkey>"]} | AUTH 之後接受 |
{"#p":["<別人>"]} | 拒絕，有沒有 AUTH 都一樣 |
{"kinds":[20000]}、{} | 拒絕——沒有指定範圍 |
{"#t":[]} | 拒絕——空的標籤清單什麼都比對不到 |
被拒的訂閱會收到 ["CLOSED", <id>, "restricted: …"]。一個 REQ 裡只要有一個 filter 被拒，整個 REQ 都會被拒。
為什麼有這些規則
沒有範圍的 filter 會讓中繼變成消防水管：成本最高，也讓旁觀者看到車道上發生的一切。#p 只能查自己，是因為它會洩漏「誰在什麼時候被誰聯絡」。
上限
- 每條連線最多同時 16 個訂閱；第 17 個會以
rate-limited:關閉。 - 每個 filter 最多回傳 1024 筆已存事件；更大的
limit會被夾到這個值。 - 已存事件由新到舊回傳，接著是
EOSE；之後符合的新事件會即時送達。