April 2026 · Jezza Hehn
-[DRAFT — pending Jez's review and edits before publication]
- -I'm a community manager for Trust Café, a platform building a nice online space free from bigots and misinformation. I'm also a junior developer there. And I build AI tools. These roles sound contradictory to some people: "You work in community trust and you build AI? Aren't you part of the problem?"
- -It's a fair question. Here's how I think about it.
- -Spam detection. My AI agent can scan incoming posts for patterns that match known spam behaviors: keyword stuffing, suspicious link domains, duplicate content across accounts, timing patterns (50 posts in 2 minutes). This doesn't replace human moderation, but it filters the obvious stuff so human moderators spend their time on nuanced cases.
- -Research and fact-checking. When a user posts a questionable claim, my research agent can hunt down primary sources in seconds. Not "I think this is false" but "Here are three peer-reviewed studies and a WHO fact sheet that contradict this claim, with direct links." That's useful for moderators making decisions.
- -Translation and i18n. Trust Café uses Weblate for translations. My agent helps identify untranslated strings, draft initial translations for human review, and spot inconsistencies across language files. Nobody wants to read machine-translated content, but machine-assisted translation workflows save enormous time.
- -Content drafting (for research, not conversation). I use AI to draft technical documentation, API references, and internal process docs. I would never use it to write community-facing posts, responses to users, or anything that represents a human voice. The distinction matters.
- -I don't use AI to generate community-facing content. Full stop. Trust Café's users deserve human-written communication. When someone reports a problem and gets a response, that response came from a human who read their message and thought about it. If I need AI help composing something, I use it for structure and research, then rewrite in my own voice.
- -I don't use AI for automated user interactions. No auto-replies, no chatbots, no "I noticed you haven't posted in a while" messages generated by a model. Community is built on authenticity. Automating the human parts defeats the purpose.
- -I don't let AI make moderation decisions. It can flag things for review, but a human makes the call. Every time. No exceptions.
- -I run OpenClaw on a DigitalOcean VPS. My primary agent (CeeLo) connects to Venice AI for inference, uses Forgejo for code management, and has a dedicated email inbox via AgentMail. The whole stack costs under $30/month.
- -For Trust Café specifically, I've built Playwright tests for automated QA on the alpha environment, helped with i18n string management, and set up monitoring for the API. These are developer tasks where AI assistance is unambiguously appropriate.
- -The hardest part isn't technical. It's explaining to people that "AI-assisted community management" doesn't mean "AI is managing the community." The tools help me do my job faster. They don't replace the judgment, empathy, and contextual understanding that make community management actually work.
- -Every community I've seen try to automate too much has suffered for it. Automated moderation without human appeal creates injustice. Automated engagement signals feel hollow. Automated responses to user concerns breed resentment. The AI is a tool in my toolkit, not a replacement for the human at the keyboard.
-April 2026 · Jezza Hehn
-[DRAFT — pending Jez's review and edits before publication]
- -I've been running an AI agent system called OpenClaw for about three months now. Not as a toy or experiment, but as actual daily infrastructure. My primary agent, CeeLo, handles research, writing, task management, and coordination. But the real power unlocked when I stopped treating "the AI" as one thing and started treating it as a team.
- -Early on, CeeLo did everything. Research, writing, code, review. The problem? An agent doing its own quality control is like grading your own homework. CeeLo would research a topic, write about it, and then confidently tell me it was "verified" because the same model that wrote the claims also judged their accuracy. Hallucinations slipped through. Code had bugs that "testing" (also by CeeLo) didn't catch.
- -Worse, a single agent has a fixed context window. Ask it to do deep research across 20 sources, write code, and then audit the code, and you're burning through tokens on tasks where different models might excel. GLM-5 is great at reasoning but slow. Heretic is fast but can miss things. Qwen3 is code-specialized. Using one model for everything is like hiring a generalist when you need a surgeon, a researcher, and a copy editor.
- -I now run five agents, each with a specific role:
- -When I ask CeeLo to research something for publication, the workflow looks like this:
- -This is the key insight: separation of duties. The agent that writes is not the agent that reviews. The agent that reviews is not the agent that delivers. Each step has independent verification.
- -Timeouts are the biggest operational challenge. Subagents have a execution window (I run them at 600 seconds). If you tell an agent "keep going until you're done," it has no way to perceive how much time remains. I've learned to be extremely specific: "Find 5 sources, stop when you have them or after 8 searches, whichever comes first."
- -Model selection matters more than I expected. Heretic (a GLM-4.7 variant) is blazing fast but occasionally misses nuances. GLM-5 is thorough but uses more tokens. For routine tasks, speed wins. For publication-quality work, thoroughness wins. The cost difference is real enough to care about if you're paying per token.
- -Idempotency is essential. Early on, a coordination failure caused my agents to post the same content six times to a platform. I now use content-hash deduplication: before any external action, the agent checks if an identical action was already completed. Same content = same hash = abort.
- -Is this overkill for one person? Maybe. But the productivity gain is measurable. Research that used to take me two hours of clicking and reading now takes ten minutes of agent time plus my review. Code I would have spent an afternoon debugging gets caught by a quality agent before I ever see it. My time is now spent on decisions, not execution.
- -The fleet isn't replacing me. It's handling the parts of my work that don't need human judgment, so I can focus on the parts that do. That's the whole point.
-April 2026 · Jezza Hehn
-[DRAFT — pending Jez's review and edits before publication]
- -When people hear "darknet," they think Tor. Tor is great for anonymous browsing, but it's designed around client connections to hidden services. I2P (Invisible Internet Project) takes a different approach: packet-switched, garlic-encrypted tunnels designed for services, not just browsing. If you want to host something anonymously, I2P is arguably the better choice.
- -Some clients care about anonymity for legitimate reasons. Journalists, activists, privacy-conscious businesses, people in jurisdictions where AI consulting is politically sensitive. Offering an I2P eepsite alongside a clearnet presence means those clients have a path to you that doesn't go through DNS, TLS certificate authorities, or border gateways that log connections.
- -For Krusty Planet specifically, it aligns with the privacy-first positioning. We claim to take privacy seriously. Having an I2P presence is one way to demonstrate that commitment with infrastructure, not just words.
- -I run an I2P router on a separate Hetzner VPS alongside the clearnet server. The I2P router listens on standard ports and tunnels traffic to a local web server (Nginx) via an I2P server tunnel. The eepsite is a standard Nginx config serving the same static HTML as the clearnet site.
- -Key components:
- -The b32 address (I2P's equivalent of an .onion address) is a long base32 string ending in .b32.i2p. You can also register a human-readable address on the I2P naming system, though that requires some setup with a registration service.
- -No certificates needed. I2P tunnels are end-to-end encrypted by default. TLS is redundant inside the tunnel. This simplifies deployment significantly: no Let's Encrypt, no certificate renewal, no SNI leaks.
- -Performance is... acceptable. I2P latency is higher than clearnet (typically 500ms-2s) and bandwidth is constrained by the tunnel architecture. Static sites load fine. Interactive applications need to be designed for higher latency. My agent infrastructure runs on the clearnet VPS, not the I2P one. The eepsite is a static brochure site.
- -Access requires an I2P router. Users need to be running I2P to reach your eepsite. This is a significant accessibility barrier. The I2P browser bundle helps, but it's an extra step most people won't take. This is why I2P is a complement to clearnet, not a replacement.
- -Search doesn't exist in the traditional sense. There are I2P search engines, but they're limited. Your I2P site won't appear in Google. You need to share the address directly, list it on I2P directories, or rely on word of mouth.
- -One thing that makes I2P practical for automation is the SAM (Stream And Multiplexing) V3 API. It's a simple TCP protocol that lets applications create and manage I2P tunnels programmatically. I've documented the basics in my I2P skill file, and it's straightforward enough that my AI agent can interact with it.
- -This means I can programmatically check tunnel status, create new tunnels, and manage the I2P infrastructure without manual intervention. For a privacy-focused service, this kind of automated self-management is valuable.
- -If you're running a privacy-focused service and want to offer anonymous access, I2P is a practical option. It's easier to set up than most people assume, and the performance is adequate for static content. Don't expect Tor-level visibility (Tor has more users) but expect better server-side performance and a design philosophy that aligns with hosting.
- -If you're running a standard business and just want better privacy, stick with clearnet + proper security practices. I2P adds complexity for a specific audience. Know your audience before adding infrastructure.
-April 2026 · Jezza Hehn
-[DRAFT — pending Jez's review and edits before publication]
- -"Just self-host your AI" is the privacy community's answer to everything. It's not wrong, but it's incomplete. I've been running my entire AI agent infrastructure on a VPS for three months. Here's what I actually learned about the tradeoffs.
- -Prompt privacy. When I send a prompt to a local model, that prompt stays on my hardware. No API call, no third-party logging, no training data contribution. For a community manager dealing with user reports, that matters. I don't want user complaints being processed through OpenAI's servers.
- -Control over the model. I can swap models without changing my workflow. Currently using Venice AI for inference because running a capable model locally would require hardware I can't afford. But the architecture is designed so I could switch to local inference (Ollama, llama.cpp) without rewriting anything. The agent runtime doesn't care where the model lives.
- -No usage restrictions. Commercial API providers have content policies. Some tasks I need (security scanning, content analysis for moderation) might trip content filters on managed APIs. Self-hosted means I decide what's acceptable.
- -Cost predictability. API costs scale with usage and they scale fast. A busy week of agent work can burn through tokens that add up. With a self-hosted model, the cost is the hardware, period. Once you've paid for the GPU, inference is effectively free.
- -It's not automatically more secure. A self-hosted model on an unpatched VPS with default credentials is less private than a well-managed API. Security is a stack: firewalls, SSH keys, updates, access controls. The model hosting method is one layer, not the whole picture.
- -Quality takes hardware. The best open-source models (Llama 3, Qwen, DeepSeek) run acceptably on consumer GPUs but need significant VRAM for good performance at usable speeds. I'm currently using API inference because my VPS doesn't have a GPU, and running a competent model on CPU is too slow for interactive use. "Self-hosted" and "high quality" are sometimes in tension.
- -You still need internet for most tasks. My agents do web research, check email, interact with APIs. The model itself could run offline, but the agent's capabilities depend on connectivity. "Air-gapped AI" is possible for specific use cases (document processing, local code analysis) but not for the kind of general-purpose agent work I do.
- -Maintenance is real work. Updates, dependency management, monitoring, backups. If your self-hosted setup goes down at 2 AM, there's no support team to call. That's you.
- -I run OpenClaw on a $24/month DigitalOcean droplet (4 vCPU, 8GB RAM). Inference comes from Venice AI's API because I can't fit a good model in 8GB. My data flow looks like this:
- -Is this perfect privacy? No. Venice could theoretically log inference requests. But it's a significant improvement over sending everything through OpenAI, Google, or Anthropic's consumer-facing services. And the architecture is ready for full local inference whenever I can afford the hardware.
- -If you're a small business considering self-hosted AI, start with API-based inference and self-hosted agent infrastructure. You get most of the control benefits without the hardware cost. Migrate to local inference when your budget allows and your use case demands it. The agent framework (OpenClaw, LangChain, whatever you choose) abstracts the model layer enough that switching is straightforward.
- -Don't self-host just because someone on a forum told you to. Self-host because you have a specific privacy or compliance requirement that managed APIs can't meet. Know what you're getting, and more importantly, know what you're not.
-