This project chose to disclose the moderation and detection methods that most platforms treat as trade secrets — but disclosure doesn't mean releasing everything at once. What can be published immediately, what needs to be held back, and what must be de-identified and released in tiers are all judged item by item against abuse risk, privacy risk, and public interest; no single rule can be applied across the board.

Even after the code is public, you still need documentation people can understand

When it comes to "disclosure," the question the project debated internally wasn't only whether to disclose, but whether — once disclosed — it can be understood, examined, and appealed. Putting code on GitHub is often treated as the finish line for transparency. But in the discussion at this year's (2026) g0v Summit, our consensus was that we need to go further and discuss the meaning behind the code in more accessible, everyday language. Ordinary users can't read the code because it presumes its reader is already an engineer＊g0v Summit 2026 校正版逐字稿（草案，非現場逐字）Simply dumping the code out there isn't the same as transparency. Ordinary users can't necessarily read the code, nor do they know where the data comes from, how the rules are applied, or how the model shapes the outcome..

"Simply dumping the code out there isn't the same as transparency… so open source is only the first step. Beyond it you still need documentation, examples, understandable explanations, an appeals channel, and workflows the community can take part in."

This "explainer" site could do even more — for instance, turning the system state values, database query rules, and decision thresholds inside the codebase into a form ordinary readers can read, discuss, and appeal. Another problem comes from the user side. Denken, a long-time user who also has self-governance experience from PTT, pointed out at the workshop that a gap still remains between "openness" and "co-creation." Matters has already opened up its application programming interface (API) and published spam-detection-scaffold, yet it still hasn't reached co-creation＊g0v Summit 2026 簡報文字記錄（Denken 觀察 2）Open source ≠ community participation; an open API ≠ users being able to influence governance decisions.Source link ↗. An API An external interface that lets other programs connect and automatically pull platform data or features. lets external programs connect and automatically pull platform data; but being able to pull data doesn't mean being able to take part in decisions. He has personally joined open development meetings across many different communities, and in the end often found it was "just me."

So public code isn't the same as transparency, because even after disclosure it may still be unreadable; and transparency isn't the same as co-creation, because being able to read it still doesn't mean being able to influence decisions. Different communities grow different forms of governance. For a platform, the more workable role is to support existing communities rather than to design their governance for them in advance. The truly laborious work comes after disclosure: keeping the data, documentation, cases, and appeals process continuously understood and used.

Why Matters chose to open-source its code

Most platforms don't disclose their moderation logic: once detection thresholds are public, attackers can adjust their evasion strategies accordingly. But Matters is willing to bear that risk, because the cost-benefit calculus differs for a small-to-medium platform. It was also openly discussed at the TWIGF 2026 workshop:

"We figured we're already so small that open-sourcing has brought back far more in feedback than it costs — a little bit more won't hurt."

For a small-to-medium platform, opening the code can buy community trust and outside feedback, while also raising the risk of being bypassed. Matters' judgment is that the former matters more to it. The same move on a hyperscale platform might lead to the opposite conclusion, because disclosing detection details there hands the evasion playbook to a huge pool of attackers; on a small platform, disclosure may instead bring the scrutiny and collaboration it otherwise lacks. This judgment depends on platform size, attack pressure, and community resources — it can't be turned directly into a rule that suits every platform.

Code is public; sensitive parameters are disclosed later

Choosing to publish the code doesn't mean publishing all of it. The compromise that actually lands is tiered disclosure. Governance workflows and code can be published and examined right away; but sensitive parameters that could be directly abused — such as spam-decision thresholds, account-clustering rules, and threshold-scan details — are held back for six to twelve months, or abstracted first.

This tiering has an engineering basis. The decision threshold spamThreshold lives in a feature-flag table (feature_flag) and takes effect through a Redis cache, so adjusting it requires no redeployment. In other words, it is itself an operational setting that can be changed on the fly, and publishing it is almost the same as publishing the walkthrough for getting around the rules. Our view: in theory everything should be public, but in practice, the moment the threshold is public, attackers can tune their inputs to dodge detection＊《自由與管制的天平》簡報（東吳法律研究所分享, 2026-05-26）Compromise: tiered open source — the code is public, but sensitive parameters are released with a 6–12 month delay..

"For a sustainable censorship-resistant platform, if it has to sacrifice transparency for security, it's better not to hold much personal information in the first place — that way you can disclose only the process and the anti-fraud formula."

That conclusion captures the core trade-off of tiered disclosure. It contrasts with the neighborhood-watch team's "fully public enforcement actions." The same platform pursues high transparency on enforcement actions to enable accountability, yet must delay disclosure on detection parameters to lower the risk of being evaded. Which should be transparent right away and which should wait is not only a technical question but a governance judgment. That's why the research report marks material as [Internal] throughout, carrying this tiering into the documentation itself.

How the not-yet-released dataset is designed

After the code is public, the next step is publishing the data. matters-spam-dataset is a research dataset whose goal is to de-identify the platform's accumulated spam-annotation corpus and release it publicly＊matters-spam-dataset READMESource link ↗. But its contents are still being adjusted and it hasn't been formally released. The team is still confirming whether the terms of service permit redistribution and derivative use, and legal is still reviewing the data card and the data use agreement. We welcome inquiries about how to release the spam dataset＊matters-spam-dataset README（分階段路線圖）P0 platform license ✅ / ToS redistribution-clause check + legal review of DUA ⬜ pending legalSource link ↗. So what follows describes a method that is already designed and already written into code, but not yet publicly released.

Scale & licensing

The first release, v2026.06, centers on articles, with comments and moments planned for incremental release. The scale and label distribution come from the data card and release manifest in the codebase (the platform's own account, not independently verified by a third party).

Licensing is split by output and source; no single clause can cover it. The dataset as a whole uses a CC BY-NC-ND 4.0-compatible license and is bound by a data use agreement (DUA); but an individual sample, inheriting its original content license, may be CC0, CC BY-NC-ND 2.0, or CC BY-NC-ND 4.0. v2026.06 therefore accepts only CC / CC0 sources and excludes All Rights Reserved content (ARR — that is, content whose author released no license for reuse). The release manifest records 436 ARR spam items removed for this reason that the old policy would have let through. the code uses the MIT license and the data uses CC BY-NC-ND 4.0 — the two licenses are deliberately kept separate＊matters-spam-dataset LICENSE / DATACARDData: CC BY-NC-ND 4.0-compatible license; individual sources include CC0, CC BY-NC-ND 2.0, CC BY-NC-ND 4.0, and must comply with the DUA.Source link ↗. The release channels come in two kinds. Bulk download and reproduction use the gated-access dataset on Hugging Face, where users must agree to the data use agreement and versions are marked with git tags; querying increments and contributing labels back use a purpose-built interface. The two needs differ, so they're handled separately.

Public de-identification ≠ internal de-identification

This dataset may be valuable to both the policy and developer communities because it treats "internal use" and "public release" as two different levels of de-identification. The internal training corpus only hashes ids and keeps the original text, because the LINE IDs, phone numbers, wallet addresses, and referral links in that text are both personal data and the strongest spam signals. The public version has to balance "preserving spam's structural signals" against "not leaking real people's contact details," and it does so in three layers.

The code comments in the de-identification pipeline hold plenty of small but crucial details that show de-identification isn't done after running a single regular expression. After contact details are turned into placeholders, a real account like "<LINE_ID>:abc888" often lingers behind, so it takes two more cleanup passes to also strip the account string immediately following a placeholder. Wallet addresses, QQ numbers, and URLs split apart by a space (https:// example.com) each have their own dedicated rules too. These details show that de-identification quality depends on how the edge cases are handled, not just on the main rules themselves.

Label structure & credibility tiers

The dataset doesn't treat every label as equally reliable. Besides the binary label spam / ham, each sample carries a research-oriented spam-category field spam_category, a label-source field label_source, and a suggested training weight label_weight. The weights follow the internal 2.0 / 1.0 / 0.5 convention. Source credibility is explicitly ranked: per-item admin decisions (admin_set_spam) and manual corrections (human_relabel) carry a weight of 2.0; overturned enforcement (reversed_moderation / restored_content) means "this is actually legitimate content" and is a strong corrective signal; purely model-assisted labels (model_assisted) carry the lowest weight, and the data card explicitly asks downstream users not to treat them as ground truth.

There's another easily overlooked but crucial design. Once the test set is split off, it stays fixed. The data split is stably partitioned by id hash, and once the test set is released it no longer changes — serving as a fixed referee set for collaborative evaluation, preventing different contributors from cherry-picking data to inflate their scores, and preventing the test set from leaking. For a dataset that invites outside contributors to annotate and train together, this is the foundation for keeping evaluation fair.

Honestly disclosing residual mislabeling

Some early positive samples came from a proxy judgment: "author restricted → all content under their name labeled spam." Even at a low rate, this can still wrongly sweep up legitimate political commentary and long-form academic and creative writing, especially long-form Chinese. The dataset has already used humans plus LLM Large AI models such as ChatGPT and Claude that can read, write, and understand language. assistance to re-read and correct roughly 5,000 items, with a full scan planned afterward.

the data card writes the known noise in the proxy labels into a "composition" section and uses label source and training weight to provide credibility tiers＊matters-spam-dataset DATACARD（已知標籤噪音）This dataset has already used humans + an LLM-judge to correct 4,980 items (human_relabel), of which 2,649 were flipped from spam back to ham, but uncorrected portions may still contain mislabeled long-form Chinese.Source link ↗. Samples flipped back to legitimate content are important counter-examples for reducing wrongful removal. They teach the model to recognize cases that "look like they were once enforced against but are actually legitimate." The data card also flags a blind spot: high-variation templates and cross-account ad rings ( Ring A group of accounts run by the same person or team that flood the platform with the same template en masse; the source code calls it a Ring. ) are under-detected at the pure-text level. Writing "where we might still be wrong" into public-facing documentation is itself part of transparency.

Usage boundaries: open, but not unconditional

The data use agreement spells out prohibited uses: any form of re-identification is prohibited (you may not restore or infer the real author or contact behind a sample, nor cross-reference other data to achieve re-identification), commercial use is prohibited (doubly bound by CC BY-NC-ND 4.0 and the DUA), harassment and doxxing are prohibited, and using it to train tools that generate spam or evade detection is prohibited. On the Hugging Face side it's designed as gated access: before downloading you must state your purpose and check a box agreeing to the DUA. It also preserves a removal request mechanism under the PDPA: a data subject can ask for a review or takedown; once the dataset publishes a removal record, users must delete the corresponding sample at their next sync and may not keep the original text. How "open" a de-identified dataset really is comes down, in the end, to these boundary conditions — not just the record count.

The principle of tiered disclosure

Transparency requires designing the mode of disclosure item by item; it can't be understood as a one-off, release-everything move. Code can be published immediately, sensitive parameters can be disclosed later, and data must be de-identified first and then released in tiers. After disclosure, you must keep organizing the data, documentation, cases, and appeals process into forms people can read, discuss, and take part in. What tiered disclosure sets out to answer is the question of "can we have both security and transparency." The way to do it is to rank item by item, design layer by layer, and leave an auditable reason behind every decision to disclose or to hold back.