跳轉到

D-20260706-04｜DMCA 維運補強包：admin 端點＋防濫用三件組＋反通知入口

背景與驅動力

部署討論延伸：使用者逐項問透 DMCA 維運（信箱申請、API 濫用、亂寄信、下架實操、反通知產生），照出缺口——DMCA_ADMIN_TOKEN 有了但可用它的端點沒定義，「通知維護者」「通知創作者」機制未釘死。

考慮過的選項

  • CAPTCHA 防濫用：第三方 script 違反 CSP 自架原則，不採。
  • GUI 管理介面：非必要；維運介面收斂為 HTTP 直呼（curl／Postman，指令範本隨部署 repo README）。
  • admin API＋email 確認關 ＋ 詳情頁反通知入口（採納）。

決定

  • admin 兩端點：GET /admin/notices?status= 查詢 ＋ POST /admin/notice/:id/decision（take_down｜reject｜restore）——單一呼叫完成即時層 unpin、索引與 gateway 排除、status 轉移、透明度計數；restore 同步 re-pin。認證釘死 Authorization: Bearer <DMCA_ADMIN_TOKEN>（secret 只存 token 本體、Bearer 前綴呼叫時加）。
  • 收件防濫用三件組：per-IP rate limit（掛既有骨架）／payload 過大回 413／email 確認關——點確認連結才成案並通知 Agent 信箱，未確認 72 小時清除；status 新增 pending-email-confirm。
  • 反通知入口 ＝ 詳情頁下架標示附 counter-notice 表單（client 以 TakedownEntry.noticeId 組連結、自動帶 originalNoticeId）——這就是「通知創作者」的實體：匿名 PeerId 無 email 可寄。
  • 代理人登記與信箱建置 runbook 文檔化（Cloudflare Email Routing、dmca.copyright.gov 登記與續期、公示三處同步；時程為正式對外上線前、playtest 不需）；直寄信罐頭範本三規則：導流非拒絕、要件齊全的直寄信仍屬合格通知須代錄入同一管線、不全者同範本回覆補齊前無義務。

後果與影響

DMCA 從「有 spec 無操作面」補到可實跑：收件、確認、裁決、恢復全走同一條 HTTP 管線。後續 D-20260720-01 在 pinning 架構改寫時再細化儲存位置、hold 與每日掃描制。權威見 程式架構/dmca.md 與 DMCA.md。