The exclusion policy

The point of building your own tools is sovereignty. So it would be a quiet betrayal if the thing you built to protect your community routed your people’s data straight back through the surveillance-advertising infrastructure they’re trying to route around. Most catalogs stay neutral about who profits from the tools they list; for the people this is built for, neutrality is its own kind of failure.

So we hold a line — in solidarity with the people downstream — and, just as important, we let you check it yourself instead of asking you to trust anyone’s good intentions.

What we keep out, and why

A dependency is kept out of the catalog if it is owned by, or routes data to, any of:

Organization	Why
Meta (Facebook, Instagram, WhatsApp, Threads, Reality Labs, Oculus)	Surveillance-advertising business model; the infrastructure many of these communities are trying to route around.
OpenAI	Closed model provider with a data-use posture incompatible with the communities served here.
xAI (Grok)	Same closed-provider concerns.

The authoritative, machine-readable list lives in the repository at enforcement/excluded-organizations.yaml, with per-ecosystem signals (npm scopes, PyPI packages, Maven groups, Go module prefixes, and so on). It is the same file the enforcement engine reads.

This is about ownership and data flow, not vibes

The policy excludes organizations, not topics. A library that mentions one of these companies is fine; a library published by one, or one that ships a client that sends data to one, is not. The distinction is what Layer 1 (ownership), Layer 2 (transitive ownership), and Layer 3 (data-flow strings) each check.

Configurable tools: the provider-lockdown recipe

The exclusion above is absolute — nothing earns an exemption from it. But some tools are themselves configurable to reach an excluded provider at runtime. The canonical example is Shakespeare, the browser-based Nostr app builder: its bring-your-own-key picker can be pointed at OpenAI or xAI as easily as at Anthropic, DeepSeek, Kimi, OpenRouter, or local Ollama.

A tool like that is admitted to the catalog only under a provider-lockdown recipe (recipe_type: configuration) — a documented, machine-checked configuration that forbids every excluded provider, pins the tool to permitted ones, and prescribes how to verify that no traffic reaches an excluded endpoint.

This is not a loophole or a “trusted tool” exception. It is the opposite: a stricter requirement that exists precisely because the tool could otherwise slip past Layer 3. Shakespeare is strictly forbidden from using any dependency or provider owned by Meta, OpenAI, or xAI — the recipe is the binding, enforced mechanism that guarantees it. See the Shakespeare lockdown recipe and the recipe contract.

Origin advisories (Meta-built, permissively licensed)

A narrow, deliberate middle ground exists for libraries that are built by an excluded organization but are permissively licensed and do not route user data to it — most notably React, React Native, Lexical, and Metro, which Meta authored and open-sourced under MIT.

These are included in the catalog, but each carries a visible meta-origin advisory badge and a note, so you make the dependency choice with your eyes open. The reasoning:

• The exclusion policy’s core concern is data flowing to surveillance-advertising infrastructure. A permissively-licensed library you compile into your own app does not do that.
• The And Other Stuff crew actually ships on these tools; a catalog that hid them would be less honest about the real stack.
• Transparency (an advisory) serves the builder better than a silent omission.

This is not a loophole for data-routing SDKs: Meta’s facebook-nodejs-business-sdk and similar are still blocked by the name screen. And it does not extend to LLM providers — anything owned by OpenAI or xAI is blocked outright, advisory or not.

The appeals path

Exclusion calls can be contested. If you believe a tool is wrongly excluded — for example, a @react-native-community package that is genuinely community-owned and not Meta-published — open an issue. Layer 3’s import-context matching exists precisely to disambiguate these cases, and false positives are tracked and corrected rather than waved through. Editorial judgment, new-category structure, and contested exclusions are the things humans decide; everything checkable is checked by tooling.