發文、留言、檢舉、申訴
共同架構底圖
一則內容在社群平台裡怎麼走
- 01平台骨架
- 02Matters 模組
- 03ROOST 工具
- 04並排比較
內容、帳號、排序、通知
偵測、調查、審查、救濟
保存、存取、跨站流通
先看共同底圖
使用者發文後,平台要處理哪些事
讀者在前台發文、留言或檢舉,平台核心負責權限、內容狀態、排序與通知。資料庫和工作佇列保存紀錄,發布元件再把部分內容送到站外。
治理決定最後都要回到產品。摺疊留言、降低曝光、凍結帳號或恢復內容,都必須改變平台裡的實際狀態。
加上 Matters 的做法
偵測、審查與申訴直接接在產品上
垃圾模型找單篇內容,集團偵測找跨帳號行為,海巡把已知樣態送進候選清單。站務人員在里長室處理較廣的案件,守望相助隊則只處理權限範圍內的垃圾留言。
小黑屋調整內容曝光,救濟機制負責申訴、覆核與恢復。IPFS、Onion 與 Fediverse 位在發布端,處理保存、存取與跨站流通。
換看 ROOST
Model Community、Osprey、Coop 各接一段
Model Community 提供模型與評估材料。Osprey 接收平台事件,套用規則並協助調查。Coop 接收內容與檢舉,安排自動規則或人工審查,保存決定與申訴,再用 callback 請平台執行處置。
ROOST 不會替平台決定政策,也不會自動補上審查人員、權限、使用者通知或發布系統。這些工作仍由採用工具的平台負責。
把兩邊放在一起
ROOST 補工具,Matters 保留平台規則
Matters 的模組知道文章、留言、帳號、推薦面與社群角色。ROOST 提供可在不同平台重用的模型資源、事件調查與審查工具。
若要整合,可以先把 Model Community 與 Osprey 接到偵測、調查層,再用 Coop 管理 Queue、Decision 與 Appeal。最終處置、社群制度與抗審查發布仍由 Matters 負責。
Matters 治理模組
Matters 的治理模組各放在哪裡
這些名稱有的是程式模組,有的是操作介面或社群制度。以下逐項說明用途,以及從公開資料還無法確認的部分。
垃圾模型
文章、留言與動態可保存 spam_score 及人工標記。模型適合提供排序、分流與候選線索,實際排除範圍仍取決於內容類型、功能開關及產品查詢。
管理員標記、守望相助結果與申訴翻案可以留在本地資料中,繼續用來整理華語社群的垃圾樣態。
集團偵測
內容模型只看單篇文本,容易漏掉多個新帳號反覆張貼相似模板的行為。集團偵測改看跨帳號重複、近似內容、外部實體與帳號特徵,再建立可審查的 ring 候選。
後端已有候選、成員、事件、凍結、解凍與誤判處理資料流,里長室也有集團清單。自動凍結門檻與排程是否啟用仍屬正式環境設定。
Matters 里長室
matters-oss-next 是站務控制面,整理文章、留言、動態、帳號、垃圾排行、守望相助、集團偵測、限制名單、聯邦宇宙佇列與功能開關。
它把既有 GraphQL 能力變成可操作介面。程式庫可確認功能範圍,實際部署位置、權限與新舊後台切換仍需分開驗證。
守望相助隊
受信任成員可處理範圍明確的垃圾留言,公開紀錄包含理由、時間、執行者顯示名稱、申訴與站方覆核狀態。這項權限不包含刪除文章或停權帳號。
公開紀錄讓外界看得到處置,有限權限避免志工碰到過重的決定,站方則保留覆核與恢復權。
查看公開頁海巡與 Coastguard
海巡機器人使用留言垃圾模型與守望相助的既有移除樣本掃描候選,並保留候選來源及處置紀錄。社群過去做過的判斷因此可以再次用於篩選。
候選池、精度門檻、執行環境與人為核准模式會影響實際覆蓋率,不能只用模型檔案推斷目前自動處置範圍。
小黑屋
user_restriction 可限制作者進入熱門或最新等發現面。內容與帳號仍存在,治理介入點落在排序及曝光,與直接刪除內容不同。
它也與帳號 frozen 狀態不同。前者調節特定發現面,後者是更重的帳號狀態,兩者不應在政策說明或後台操作中混為一談。
申訴、覆核與透明度
救濟包含案件、事件、通知、申訴、人工覆核、恢復及透明度彙整。後端已有 moderation case/event 與彙整服務,公開頁也提供申訴入口及制度說明。
仍要確認三件事,原處置能否撤回、使用者是否收到結果,以及透明度數字是否排除敏感資料。
查看申訴與救濟中心抗審查與跨站流通
IPFS/IPNS 處理可驗證的靜態發布,Onion Gateway 提供 Tor 存取入口,Fediverse Gateway 承擔 ActivityPub 投遞、狀態與重試。三者處理的是保存、存取與互通,不是內容分類。
這些元件保護合法內容免於單點封鎖,也讓作者保有較長期的內容可攜性。
ROOST 工具對位
三個核心專案各自負責什麼
ROOST 的工具不綁定單一社群產品。可以只導入目前缺少的一段,也可以依序接上偵測資源、事件調查與審查處置。
Model Community
提供開放安全模型、政策套件、評估方法及導入資源。它供應偵測材料,本身不是平台的即時處置服務。
閱讀繁中資料 ↗Osprey
接收事件串流,以 SML 規則擷取 Features、辨識 Entities、套用 Labels、產生 Effects 與 Verdicts,並讓分析人員查詢及回看事件。
閱讀繁中指南 ↗Coop
管理 Item、Policy、Signal、Rule、Report、Queue、Decision、Action 與 Appeal。Action 透過 callback 回到平台,因此最終產品狀態仍由平台掌握。
閱讀 Coop 概念 →差異盤點
同一項工作,Matters 與 ROOST 怎麼做
兩邊有不少相似功能,負責的範圍卻不同。以下直接比較誰掌握產品資料、誰執行處置,以及整合時還要補哪些工作。
完整社群產品,治理直接連到內容、帳號、排序、通知與發布。
可獨立部署的治理工具與社群資源,不提供完整社群產品。
ROOST 接入 Matters API,產品狀態仍由 Matters 決定。
使用在地資料與人工回饋,模型與內容類型、查詢及功能開關緊密相連。
Model Community 提供跨平台模型、政策套件與評估資源,Coop 可接外部 Signals。
先用繁中資料重新評估,再把模型輸出轉成 Signal,不能直接沿用他處門檻。
集團偵測理解 Matters 的文章、動態、帳號歷史、發現面與凍結狀態。
Osprey 提供 Events、Entities、Labels、Rules 與調查能力,平台需自行定義資料及關係。
把 Matters 事件與帳號關係映射成 Osprey Entity schema,再保留本地護欄。
里長室服務站務人員,守望相助隊另有社群角色、有限權限與公開紀錄。
Coop 提供組織內 Queue、審查權限、Decision 與 Action,不預設志工制度。
可以用 Coop 管理工作流,成員資格、公開程度與問責規則仍由社群制定。
原生 mutation 可直接改變內容、帳號、限制與推薦查詢。
Coop 以 callback 要求平台執行 Action,Osprey 回傳 Verdict 或 Effect。
Action handler 必須冪等、有權限檢查,並可回報成功或失敗。
案件、事件、公開紀錄、站方覆核、恢復與透明度頁面都在產品內。
Coop 可路由 Appeal、記錄決策及回傳結果,外部通知與反向 Action 由平台完成。
將 Matters 案件識別、原決策及恢復結果對應到 Coop Appeal,避免稽核斷裂。
另有 IPFS/IPNS、Onion 與 Fediverse 元件,處理保存、存取及互通。
目前核心工具聚焦線上安全工作流,沒有直接對應的內容發布韌性層。
保留 Matters 發布元件。Mirror 只處理程式庫鏡像,不能代替內容可用性。
整合草圖
如果 Matters 要接 ROOST,資料可以這樣走
- 01
送出事件與內容
Matters 將必要且最小化的 Item、Report 或事件送至 Osprey/Coop。
- 02
加入本地訊號
垃圾模型、集團線索與社群處理結果轉成可追溯的 Signals 或 Labels。
- 03
調查與分流
Osprey 找出事件模式,Coop Rules 將案件送往站務、守望相助或專門 Queue。
- 04
回到產品執行
Matters Server 驗證 callback,再執行摺疊、限制、凍結、恢復或通知。
- 05
完成救濟與公開
把 Appeal、覆核、反向動作與匿名化透明度指標接回既有制度。
來源與限制
本頁查了哪些來源
本頁以 2026 年 8 月 8 日取得的公開程式庫預設分支為基準,也檢查公開頁面是否可存取。程式碼可用來確認功能放在哪裡,正式環境設定、資料品質與實際處置仍需營運端證據。
Matters 核心與治理來源
- matters-server GraphQL、領域服務、限制、案件、透明度、IPFS 發布
- matters-web 公開社群產品介面
- matters-oss-next 里長室與站務工作流
- community-watch 守望相助規則與公開紀錄
- spam-detection-scaffold 垃圾模型與集團偵測
- matters-coastguard-bot 留言候選與海巡自動化
ROOST 對位來源
- Coop 審查、規則、處置與申訴
- Osprey 事件規則與調查
- Model Community 開放安全模型與政策資源