On September 17 the European Commission tabled COM(2026) 681 — the EU KIDS Act, procedure 2026/0286(COD) — and within weeks the fediverse got its death notice. Austrian digital-rights group epicenter.works headlined theirs "Bye Bye Fediverse": age verification on every single instance, the end of community-run networks in Europe. An iX analysis at heise read the text article by article and concluded the panic overshoots. Both are partly right. The part of the critique that survives fact-checking is the part with teeth for the people who run this site's kind of infrastructure: the draft deletes an exemption the DSA had, the duty lands on whoever operates the server, and the obligations collide with ActivityPub at the protocol level in ways a small operator cannot configure away.

First, the frame: this is a proposal, not a law in force. Parliament and Council can change every line below. Several outlets reported it as a done ban, which is wrong twice — wrong on procedure and wrong on content. What follows is what the draft actually says.

What the draft requires

The draft borrows the DSA's definition of a social network and attaches age rules to it. One risk feature is enough to qualify — for instance, the mere ability to contact strangers, which describes Mastodon.

  • Article 6 — age tiers. No accounts under 13. At 13-14, parents may create a restricted account: time limits capped at one hour per day, and parents pre-approve new contacts. From 15, an own account.
  • Article 8 — defaults. Protection duties apply by default to every account whose adulthood is not established. Self-declaration does not count.
  • Article 29 — verification. Age checks at account creation through a certified third-party solution. Existing accounts must be re-verified within six months of the law taking effect; accounts whose age cannot be established are deactivated.
  • Article 12 — minors' visibility. By default, only contacts the minor accepted may see profile and posts — and regardless of any setting, nobody may access a minor's profile or content without an account. Minors' account data and content must not be downloadable or screenshot-able. Article 20 adds parental-tooling duties for every minor account.
  • Extraterritoriality. Providers are captured if they offer the service to users in the EU (Article 2), wherever they sit, and must designate a legal representative in a member state (Article 24).

Three corrections to the coverage

1. The small-provider exemption is gone, on purpose. The DSA exempts small and micro enterprises from its youth-protection duties. The KIDS Act text does not, and the Commission's justification says so directly: small providers can also harm minors, and an exemption would undermine the law's aims. If you run a community instance, this is the clause that decides your future. The Commission's supporting economic analysis is a working paper, not a formal impact assessment — epicenter.works' "no impact assessment at all" is slightly overstated, but the paper exists and concedes the parts that matter: costs cannot be quantified for the many small providers, smaller services face relatively larger difficulties, and the estimate for plugging in a ready-made verification runs a few hundred to a few thousand euros. Per service. With no size floor.

2. Open source does not exempt you. Article 2 carves out non-profit online encyclopedias and platforms for developing and sharing open-source software — Wikipedia, Codeberg. A Mastodon instance is not a development platform. The software project carries no duties under this draft; the operator of each deployment does. "The code is free" answers the wrong question.

3. "Every instance must verify ages" overshoots. The draft's scope hangs on the information-society-service definition, which EU law treats as services normally provided for remuneration (recital 11). Whether a genuinely non-commercial hobby server is captured is a real legal question, answered per case — not an automatic yes. But notice what kind of open question this is: nobody has declared hobby servers out, the classification argument only helps if your facts genuinely support non-commerciality, and the duties, once they bite, do not shrink with size. The panic is overstated; the exposure is not imaginary.

What survives all three corrections: you are the regulated party, and the obligations were written for a provider that controls its whole stack.

Where the draft meets the protocol

This is the part the press releases will never contain.

ActivityPub's public addressing is defined as unauthenticated access. Section 5.6 of the W3C recommendation requires that anything addressed to the special Public recipient be readable by anyone, without an account. Mastodon's "Public" visibility maps exactly onto that address.

Article 12 then says the opposite: for every account whose adulthood is not established — which, until verification happens, is every account — nobody without an account may access profile or posts, and the default audience is only contacts the account holder accepted. A compliant instance cannot add a checkbox at signup. It must know each account's age class and enforce publication, contact, and visibility rules per class. A minor's account — or any account pending adult verification — cannot address Public at all.

Then federation breaks the enforcement model entirely. Your server delivers content to mine; my server renders it with my software, under my rules, possibly to logged-out visitors. The draft assumes "the platform" controls presentation and downstream reuse. The words federated and decentralized appear nowhere in the text. It never resolves whether a follower on another server is "a user of your service" for the law's purposes.

And Article 12's screenshot clause — operators must ensure minors' content cannot be downloaded or screenshotted — is not implementable anywhere. You can remove download buttons. A native app may hinder screenshots on some operating systems. A web page cannot. A second phone pointed at the first screen is defeated by no protocol ever written. Once content has federated, the origin server has no say in what the recipient server shows anyone. This is not a Mastodon bug or a laziness gap; it is load-bearing protocol architecture meeting legislative assumptions that predate it.

The levers that exist, and what they cost

Mastodon ships configuration for exactly this problem, and every lever works by closing openness:

  • AUTHORIZED_FETCH (Secure Mode): content is served over ActivityPub only to servers that authenticate with a signature. It authenticates the other server, not the human behind it — whether that server shows the material to anonymous visitors remains its decision. It narrows exposure; it does not satisfy Article 12.
  • DISALLOW_UNAUTHENTICATED_API_ACCESS: logged-out visitors lose profile and post pages entirely. A server-wide switch — every anonymous visitor loses access, not just accounts belonging to minors.
  • LIMITED_FEDERATION_MODE: the instance federates only with an explicit allowlist of domains and turns off all public pages. The Mastodon documentation's own word for the result is data silo.

So compliance-as-configuration exists, and it functions by removing exactly the property these networks exist for. For a community instance, that is not a compliance update. It is the end of the feature set.

Fair credit, and the objection that stands

The Commission's verification stack deserves an honest look, because it is better than the caricature. The EU age-verification blueprint is open source and uses zero-knowledge proofs: per the Commission's FAQ, the service learns only that a threshold was crossed — no name, no birthdate. Article 28 prohibits age verification that renders the user identifiable, and every member state must offer its residents at least one free solution. If this layer ships as drafted, "upload your passport to a forum admin" is not what happens.

epicenter.works' structural objection stands against it anyway, and it is worth stating cleanly: an age gate at registration is still an identity gate in operation. People without matching documents are excluded outright. Patchwork and atypical families are structurally disadvantaged. Parent accounts — which the design of the 13-14 tier requires, meaning parents themselves must pass identity checks — normalize day-to-day surveillance of teenagers' digital lives, hitting hardest the minors who most need ungated community spaces. And the legal basis for this infrastructure rests on a working paper rather than a formal impact assessment. Their further claim that the proposal reaches into member states' birth registers, I could not verify against the text as published; score that claim accordingly.

Where it stands

The procedure is live; nothing is in force. Parliament and Council can rewrite any article above — and if the co-legislators that wrote the small/micro exemption into the DSA apply the same logic here, the entire outcome changes. Austria is running a parallel national law with a 14-year threshold and a 2027 target that could land before the EU act — its consultation closed with roughly 250 responses, many critical from child-protection organizations themselves. Same design on both fronts: access restriction treated as interchangeable with protection.

Two days before the KIDS Act was tabled, the sixth Chat Control trilogue drafted public-content scanning duties that reach hosting providers of any size. Notice the shared architecture: the duty reaches any size, the operator is the enforcement surface, and the text was written for service models that are centralized on purpose. Whoever is building the next decade's community infrastructure is watching the same question get answered twice, badly, by the same assumption.

The question that will actually decide how this ends, per the iX analysis: how do you regulate the provider of a network that has no provider? If the EU answers it by forcing every instance into platform-shaped duties, small instances will not rush to comply — they will close, and the death notice epicenter.works wrote turns out to be a forecast, arriving by attrition rather than by article.

What an operator actually does

  1. Read the text, not the coverage. COM(2026) 681 is a PDF and it is readable. Most secondary coverage, including the scary and the soothing versions, paraphrases it loosely.
  2. Know that you are the regulated party. The duties will never be the software project's to carry. Budget attention accordingly.
  3. The amendment that matters is the small-provider carve-out. If your community operates EU-facing infrastructure and you write exactly one letter to an MEP this year, it is about restoring the DSA's small/micro exemption in Article 2. The procedure is open.
  4. Do not panic-rewrite your registration flow. Nothing is in force, no application date exists, and the text can move in either direction.
  5. If your service is genuinely non-commercial, get the classification right before building anything. The information-society-service question is unresolved and runs in your favor only if your facts support it: who pays, whether accounts are offered commercially, what relationships exist. Document your own facts now.
  6. If you are ever captured, the zero-knowledge blueprint is the verification path that does not store identities. Your actual engineering problem will be Article 12 visibility and federation containment — budget for that, not for the age check.