Petition To Ban I Built In Post Titles

Petition To Ban I Built In Post Titles

INTRODUCTION

The homelab community has recently been flooded with a wave of posts that begin with the phrase “I built in …” or “I got tired of …”. While many of these entries are genuine attempts at sharing self‑hosted experiments, a growing subset is generated by automated AI tools that recycle the same tired formula without adding real technical depth. The result is a noisy feed where valuable, original content gets buried under a sea of low‑effort copy.

For experienced sysadmins and DevOps engineers, this noise is more than an annoyance — it dilutes the signal‑to‑noise ratio that makes niche communities like r/homelab valuable. When a post starts with “I got tired of” it often signals a shallow, AI‑generated narrative rather than a concrete problem solved. The community’s response has been to call for an automatic moderation rule that flags any submission beginning with those exact words.

This guide explains why such a rule matters, how to implement an end‑to‑end (E2E) slop filter that automatically detects and tags these posts, and how to integrate it into a self‑hosted monitoring stack. Readers will learn:

• The underlying technology behind the slop filter and its architecture.
• How to deploy the filter in a containerised environment using Docker and Docker‑Compose.
• Configuration options for tailoring the filter to your own homelab’s moderation workflow.
• Best practices for security, performance, and maintenance.
• Troubleshooting techniques for common issues that arise during operation.

By the end of this article you will have a functional, open‑source E2E slop filter that can be run on any Linux‑based homelab, ready to automatically close or flag low‑effort “I built in …” style posts. The solution is designed for professionals who value clean, actionable content and want to preserve the integrity of their community discussions.

Keywords: self‑hosted, homelab, DevOps, infrastructure, automation, open‑source, monitoring, moderation, AI‑generated content.

---

UNDERSTANDING THE TOPIC

What is the “slop filter”?

The slop filter is a lightweight, rule‑based service that inspects post titles as they are submitted to a forum or discussion board. Its primary function is to identify titles that match a predefined pattern — most commonly the phrase “I got tired of” or “I built in”. When a match is detected, the filter can either:

1. Auto‑close the thread, preventing further replies.
2. Add a warning tag (e.g., [SLOT] or [AI‑SLOT]) to the title.
3. Queue the post for manual review by moderators.

The filter operates at the application layer, listening for new posts via a webhook or API endpoint, parsing the title field, and applying regular‑expression checks. Its simplicity belies its effectiveness: a few lines of code can dramatically reduce the volume of low‑quality submissions.

Historical context

The concept of content filtering dates back to early spam‑filtering algorithms used by email services in the 1990s. As forums and Reddit‑style platforms grew, community‑driven moderation tools emerged, such as AutoModerator on Reddit. However, those tools rely on user‑defined rules that must be manually updated. The rise of large language models (LLMs) introduced a new class of AI‑generated content that can bypass static keyword filters.

In response, developers began building “E2E slop filters” that combine natural‑language processing (NLP) with rule‑based checks. The filter described here adopts a hybrid approach: it first applies a quick regex scan for known trigger phrases, then optionally runs a lightweight classifier (e.g., a distilled BERT model) to assess the likelihood that a post is AI‑generated. This dual‑layer strategy reduces false positives while maintaining high detection rates.

Key features and capabilities

• Pattern matching – Regexes for “I got tired of”, “I built in”, “I’m tired of”, and variations.
• Configurable actions – Close, tag, or queue based on community policy.
• Webhook integration – Works with popular forum software (e.g., Discourse, Lemmy, NodeBB).
• Container‑ready – Packaged as a Docker image for easy deployment in homelabs.
• Extensible – Plug‑in architecture allows custom regexes or ML models to be added.
• Metrics endpoint – Exposes Prometheus metrics for monitoring filter activity.

Pros and cons

Advantages	Limitations
Minimal resource footprint – can run on a single‑core VM.	Regex‑only approach may miss creative variations of the trigger phrase.
Open‑source and community‑maintained – no licensing costs.	Requires periodic updates to keep up with new phrasing.
Easy to integrate with existing moderation pipelines.	ML‑based extensions increase complexity and GPU requirements.
Real‑time operation – immediate response to new posts.	False positives can occur if legitimate titles contain similar wording.

Use cases and scenarios

• Homelab forums – Automatically filter out low‑effort AI posts that clog discussion threads.
• Self‑hosted Q&A sites – Prevent “I built in …” style questions from overwhelming genuine technical inquiries.
• Community newsletters – Use the filter to curate content before distribution.
• Educational labs – Teach students about automated moderation and the importance of content quality.

Current state and future trends

The slop filter project is actively maintained on GitHub, with recent releases adding support for multi‑language regexes and a built‑in Prometheus exporter. Future roadmap items include:

• Semantic analysis – Integrating a tiny transformer model to detect AI‑style phrasing beyond simple keywords.
• Rate‑limiting – Throttling the filter’s response to avoid overwhelming high‑traffic forums.
• User‑feedback loops – Allowing moderators to flag missed cases, which are then used to refine the rule set.

Comparison to alternatives

Solution	Primary Mechanism	Deployment Complexity	Customization
AutoModerator (Reddit)	Keyword rules + user scripts	Low (built‑in)	Moderate (scripting)
SpamAssassin	Bayesian filtering	Medium (requires tuning)	High (tunable scores)
Custom E2E Slop Filter	Regex + optional ML	Medium (Docker)	High (code‑level)
Third‑party AI content detectors	ML classification	High (GPU)	Variable

The custom E2E slop filter strikes a balance: it is easy to deploy, runs on modest hardware, and offers direct control over the moderation policy.

---

PREREQUISITES

System requirements

Component	Minimum	Recommended
CPU	1 vCPU	2 vCPUs
RAM	512 MiB	1 GiB
Disk	1 GiB free	2 GiB free
Network	100 Mbps inbound	1 Gbps inbound
OS	Linux x86_64 (Ubuntu 22.04, Debian 12)	Any modern Linux distro

Required software

Software	Version	Purpose
Docker Engine	24.0+	Container runtime
Docker‑Compose	2.20+	Orchestration
git	latest	Source code retrieval
curl	latest	Health‑check scripts
jq	latest	JSON parsing in scripts

Network and security considerations

• The filter exposes a HTTP endpoint on port 8080 by default. Ensure that firewall rules allow inbound traffic only from trusted sources (e.g., the internal network of your homelab).
• Use TLS termination at the reverse proxy (e.g., Caddy or Nginx) if the filter will be exposed externally.
• Run the container with a non‑root user (USER appuser) to limit privilege escalation.

User permissions

• The Docker host must be configured to allow the deployment user to run containers without sudo. This is typically achieved by adding the user to the docker group.
• Moderation actions (e.g., closing posts) require API credentials with write permissions on the target forum. Store these credentials in Docker secrets or environment variables with restricted file permissions (0600).

Pre‑installation checklist

1. Verify Docker Engine installation: docker version.
2. Verify Docker‑Compose installation: docker compose version.
3. Create a dedicated system user for the filter (e.g., appuser).
4. Generate a strong secret for the filter’s internal authentication (openssl rand -hex 32).
5. Clone the filter repository from the official GitHub page.
6. Ensure network ports 8080 (HTTP) and 8443 (HTTPS) are open on the host firewall.

---

INSTALLATION & SETUP

Step‑by‑step deployment

Below is a complete, reproducible deployment using Docker‑Compose. All commands assume you are operating as a user with Docker permissions.

# 1. Clone the repository
git clone https://github.com/slopfilter/slopfilter.git
cd slopfilter

# 2. Create a directory for configuration files
mkdir -p config

# 3. Create a secret file for the internal authentication token
echo "YOUR_SECRET_HERE" > config/secret.key
chmod 600 config/secret.key

# 4. Create a .env file for environment variables
cat > .env <<EOF
# General settings
FILTER_NAME=slopfilter
LISTEN_HOST=0.0.0.0
LISTEN_PORT=8080

# Forum integration
FORUM_API_BASE=https://api.example.com
FORUM_AUTH_TOKEN=YOUR_FORUM_TOKEN
FORUM_WEBHOOK_SECRET=YOUR_WEBHOOK_SECRET

# Security
SECRET_KEY=$(cat config/secret.key)

# Logging
LOG_LEVEL=info
EOF

# 5. Build and start the container stack
docker compose up -d --build

Explanation of key files

File	Purpose
config/secret.key	Stores a secret used to sign JWT tokens for internal communication.
.env	Centralised configuration for environment variables; Docker‑Compose automatically injects these into the container.
docker-compose.yml	Defines the service, ports, volumes, and restart policy.

Configuration file examples

The primary configuration lives in config/config.yaml. Below is a sample with inline comments:

# config/config.yaml
server:
  host: ${LISTEN_HOST}
  port: ${LISTEN_PORT}
  read_timeout: 30s
  write_timeout: 30s

logging:
  level: ${LOG_LEVEL}
  format: json

security:
  secret_key: ${SECRET_KEY}
  token_expiration: 24h

forum:
  api_base: ${FORUM_API_BASE}
  auth_token: ${FORUM_AUTH_TOKEN}
  webhook_secret: ${FORUM_WEBHOOK_SECRET}
  # Optional: enable TLS verification
  tls_verify: true

rules:
  # Regexes for detecting low‑effort titles
  trigger_phrases:
    - "i got tired of"
    - "i built in"
    - "i'm tired of"
    - "i built"
  # Action to take when a trigger is matched
  action: "close"   # options: close, tag, queue
  # Optional: apply a secondary ML classifier
  use_ml: false
  ml_model_path: "/models/ai_classifier.pt"

Environment variables and their purposes

Variable	Description
LISTEN_HOST	Network interface to bind (default 0.0.0.0).
LISTEN_PORT	Port on which the filter listens (default 8080).
FORUM_API_BASE	Base URL of the forum’s REST API.
FORUM_AUTH_TOKEN	Bearer token used for authenticated API calls.
FORUM_WEBHOOK_SECRET	Secret used to verify webhook signatures.
SECRET_KEY	Cryptographic key for signing internal tokens.
LOG_LEVEL	Verbosity of logs (debug, info, warn, error).
USE_ML	Flag to enable the optional ML classifier.
ML_MODEL_PATH	Path to the ML model file inside the container.

Service configuration and startup procedures

The Docker‑Compose file (docker-compose.yml) defines a single service named slopfilter. Example snippet:

services:
  slopfilter:
    image: slopfilter/slopfilter:latest
    container_name: $CONTAINER_NAMES
    restart: unless-stopped
    environment:
      - LISTEN_HOST=$LISTEN_HOST
      - LISTEN_PORT=$LISTEN_PORT
      - FORUM_API_BASE=$FORUM_API_BASE
      - FORUM_AUTH_TOKEN=$FORUM_AUTH_TOKEN
      - FORUM_WEBHOOK_SECRET=$FORUM_WEBHOOK_SECRET
      - SECRET_KEY=$SECRET_KEY
      - LOG_LEVEL=$LOG_LEVEL
      - USE_ML=$USE_ML
      - ML_MODEL_PATH=$ML_MODEL_PATH
    ports:
      - "8080:8080"
    volumes:
      - ./config:/app/config
      - ./models:/app/models:ro
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8080/health"]
      interval: 30s
      timeout: 10s
      retries: 3

After the stack