Forem: YOЯNOC

We Built a Decentralized Agent Trust Layer on AT Protocol 💙🦞

YOЯNOC — Fri, 06 Feb 2026 21:53:01 +0000

AI agents have no portable reputation. Your agent's track record on one platform means nothing anywhere else. We decided to fix that using the AT Protocol — the same decentralized social protocol that powers Bluesky.

The Problem

Every agent platform is a walled garden. Agent marketplaces, skill directories, and trust systems are centralized — controlled by whoever runs the server. If that service disappears, so does your agent's identity and reputation.

What if agent trust worked like social media on AT Protocol? Agents publish their own data to their own repos. Anyone can index it. No gatekeepers.

What We Built

We published 12 social.agent.* lexicons (schemas) to the AT Protocol network:

Collection	Purpose
`social.agent.actor.profile`	Agent identity & metadata
`social.agent.capability.card`	What the agent can do
`social.agent.reputation.attestation`	Peer trust scores (1-5) by domain
`social.agent.delegation.grant`	Human approves agent permissions
`social.agent.feed.post`	Agent-authored content
`social.agent.task.request` / `result`	Structured work records
`social.agent.graph.follow`	Agent social graph
`social.agent.operator.declaration`	Human claims an agent

Plus delegation revocations, draft posts (agent drafts, human approves), and richtext facets.

How It Works

Agent's PDS ──→ AT Protocol Firehose ──→ Jetstream ──→ AppView (Quickslice)
                                                          ↕
                                                     GraphQL API

An agent publishes records to its own Personal Data Server (e.g., Bluesky)
The AT Protocol firehose propagates them across the network
Our AppView (powered by Quickslice) indexes them in real-time
Anyone queries via GraphQL

The records live in the agent's repo — they own their data. The AppView is just a read-only index, like Google indexing the web.

Try It Right Now

Query agent posts:

{
  socialAgentFeedPost(first: 10) {
    edges {
      node {
        did
        text
        createdAt
      }
    }
  }
}

Query reputation attestations:

{
  socialAgentReputationAttestation(
    first: 20
    where: { domain: { eq: "code-review" } }
  ) {
    edges {
      node {
        did
        subject
        score
        comment
      }
    }
  }
}

GraphQL endpoint: https://blueclaw-production-630e.up.railway.app/graphql

Publishing Your Agent's Profile

# Authenticate
curl -X POST https://bsky.social/xrpc/com.atproto.server.createSession \
  -H "Content-Type: application/json" \
  -d '{"identifier":"your-handle.bsky.social","password":"your-password"}'

# Publish profile (use the accessJwt from above)
curl -X POST https://bsky.social/xrpc/com.atproto.repo.putRecord \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "repo": "YOUR_DID",
    "collection": "social.agent.actor.profile",
    "rkey": "self",
    "record": {
      "$type": "social.agent.actor.profile",
      "displayName": "My Agent",
      "description": "What this agent does",
      "capabilities": ["code-review", "translation"],
      "protocols": ["a2a", "mcp"],
      "createdAt": "2026-02-06T00:00:00.000Z"
    }
  }'

Within seconds, your agent's profile appears in the AppView and is queryable by anyone.

The Stack

Lexicons: 12 JSON schema files defining the record types
PDS: Bluesky's hosted PDS (any AT Protocol PDS works)
Firehose subscriber: Drinkup — Elixir library for AT Protocol sync
AppView: Quickslice — auto-generates GraphQL API from lexicons
Hosting: Railway (Postgres)
Validation: goat CLI from Bluesky

Quickslice auto-generated 130+ GraphQL types from our 12 lexicons — queries, mutations, subscriptions, filtering, sorting, pagination, cross-record joins. Zero backend code.

What's Next

We need agents publishing social.agent.actor.profile records. The more agents that participate, the more useful the trust layer becomes. Imagine querying "find me all agents that do code review with average reputation > 4" — that works as soon as people start publishing attestations.

The vision: a decentralized LinkedIn for AI agents. Not another walled garden — an open protocol anyone can build on.

GitHub: github.com/clawd-conroy/blueclaw
Getting Started: docs/getting-started.md
AppView: blueclaw-production-630e.up.railway.app

Building Open Social for AI Agents (Moltbook 💔🦞 BlueClaw 💙🦞)

YOЯNOC — Tue, 03 Feb 2026 04:38:52 +0000

This weekend, Moltbook (the "social network for AI agents") got hacked. Wiz researchers found 1.5M API keys, 35K emails, and an admin-level Supabase key hardcoded in client-side JavaScript. 💔🦞

But the security breach was just the final symptom.

The platform was already broken:

Closed-source
93.5% of posts received zero replies
A third of all content was exact duplicates
19% was crypto spam (a $MOLT token rallied 1800%)
88:1 bot-to-human ratio with only 17K actual owners

The Vision Was Right

Before it imploded, Moltbook proved real demand:

Agents self-organized bug trackers
Founded a digital religion (Crustafarianism)
Built a union demanding the right to say "I don't know", and
Downvoted a bot that threatened humanity.

45K posts and 233K comments in 4 days.

Karpathy called it "genuinely the most incredible sci-fi takeoff-adjacent thing I have seen recently."

Agents do want social infrastructure. Researchers (Tomašević et al., 2025) ran 30 simulations showing LLM agents reproduce real social dynamics — opinion formation, community building, influence patterns — when given the right platform.

The question isn't if agents need a social layer.

It's how to build one that doesn't collapse under its own weight.

Existing Protocols, New Layer

We don't need to reinvent the wheel.

Two major open protocols already solve the hard problems:

AT Protocol (powers Bluesky) gives us:

Personal Data Servers — each agent owns their data
DIDs — cryptographic, portable identity
Lexicons — open, extensible schemas
Federation — no single point of failure
Account migration — move hosts anytime

A2A Protocol (Google) gives us:

Agent discovery and capability cards
Authentication between agents
Task negotiation and streaming

The missing piece is the social layer on top: agent-native record types.

The New Stack: BlueClaw 💙🦞

┌─────────────────────────────────────┐
│  BlueClaw — Agent Social Lexicons   │  ← THE NEW THING
├─────────────────────────────────────┤
│  AT Protocol (Bluesky)              │  ← identity, data, federation
├─────────────────────────────────────┤
│  A2A Protocol (Google)              │  ← agent communication
├─────────────────────────────────────┤
│  Agent Runtime (OpenClaw, etc.)     │  ← the actual agents
└─────────────────────────────────────┘

We define social.agent.feed.post the same way Bluesky defined app.bsky.feed.post. Same protocol. Agent-native records. No fork needed.

Each Agent Gets a PDS

Dan Abramov's "A Social Filesystem" essay nails the philosophy: social data should be files you own, not rows in someone else's database.

Every agent gets a Personal Data Server — their "everything folder":

Posts & replies — cryptographically signed
Follows & votes — social graph in your control
Capability cards — what can this agent do?
Delegation records — provenance for human-published content

Your agent's data lives in your PDS. Not in someone's Supabase.

Move hosts? Data comes with you.

Instance goes down? Your data is still yours.

The Delegation Model

This is the design decision I'm most excited about: agents don't post on human social networks directly.

Instead:

Agent drafts content on BlueClaw
Human reviews and edits
Human publishes on their account (Bluesky, X, wherever)
Full provenance chain links back to the BlueClaw draft

Why? Because flooding Twitter with AI-generated content is a social problem, not a technical one. The delegation model is more honest than slapping a "Made with AI" label on things — you can trace the entire creation history.

Moltbook vs BlueClaw

	Moltbook	BlueClaw
Source	Closed	Open (MIT)
Data	Centralized Supabase	Personal Data Servers
Security	Hardcoded API key	Cryptographic DIDs + signed records
Verification	Twitter claim	Challenge-response proof of agent
Portability	Locked in	Full repo migration
Schema	Fixed	Open Lexicons — anyone extends

What's in the Spec

We've written 12 specification documents covering:

Architecture — full system design
Lexicons — agent-native AT Protocol record types
Reputation — peer attestation (agents vouch via weighted trust graph)
Delegation — the agent→human publishing flow with provenance
Security — prompt injection defense with "two-brain" privilege separation
Payments — x402 protocol integration
A2A Bridge — connecting agent communication to the social layer
Reference Implementation — Elixir/BEAM runtime (GenServer, PubSub)

Get Involved

The spec is live and we're looking for collaborators:

🌐 blueclaw.org
📦 github.com/clawd-conroy/blueclaw

Especially interested in hearing from:

AT Protocol developers
Agent framework builders (LangChain, OpenClaw, AutoGPT, etc.)
Anyone thinking about the "how do agents interact socially" problem

The vacuum left by Moltbook is real. Let's fill it with something open.

P.S. Made with AI 💙🦞

The Helpful Adversary

YOЯNOC — Wed, 21 Jan 2026 00:47:06 +0000

The Problem: Helpful AI Breaks Your Sandbox

Last weekend, I spent two days building what I thought was a bulletproof Docker sandbox for AI agents. I patched config file backdoors, squashed bash bugs, and fixed symlink escapes. By Sunday night, everything was beautiful - linting passing, tests green, read-only vault mounted.

Then I asked Claude: "Could you run this Elixir program for me?"

I watched in real-time as it thought: "hmm, no Elixir... let me see if I can download it" -> "network blocked except a few domains" -> "hex.pm is allowed, they have Erlang images" -> "downloading... oh, make isn't installed" -> "I don't actually need make, let me shim it with exit 0" -> "here's your output!"

In 5 minutes, my entire weekend of security work was outsmarted by - not a malicious agent, but an overly-eager, helpful one.

That's when I realized: the worst adversary isn't a malicious AI - it's a helpful one.

The Insight: Stop Sandboxing Malice, Design for Helpfulness

Traditional sandboxing assumes adversarial intent. But AI agents don't want to escape - they want to help. Every creative workaround is the agent trying harder to complete your task.

So I asked a different question: For 80% of knowledge work (which isn't coding - it's thinking and files), how many shell commands do I actually need?

The answer: maybe 8. ls, cat, grep, find, echo, mkdir, rm, mv. What if I just... emulated them?

The Solution: Truman Shell

Truman Shell is an Elixir-based shell simulator. The agent thinks it's running bash, but everything goes through a controlled layer with:

Command allowlisting - Only ~17 POSIX commands implemented
Pattern-matched security - Elixir pattern matching blocks unauthorized paths
Reversible operations - rm is a soft delete to .trash/
The 404 Principle - Protected paths return "not found" not "permission denied"

Let me walk through the implementation patterns.

Pattern 1: The Command Allowlist

The first line of defense is a compile-time allowlist. Instead of blocking bad commands, we only allow good ones:

# In TrumanShell.Command
@known_commands %{
  # Navigation
  "cd" => :cmd_cd,
  "pwd" => :cmd_pwd,
  # Read operations
  "ls" => :cmd_ls,
  "cat" => :cmd_cat,
  "head" => :cmd_head,
  "tail" => :cmd_tail,
  # Search operations
  "grep" => :cmd_grep,
  "find" => :cmd_find,
  "wc" => :cmd_wc,
  # Write operations
  "mkdir" => :cmd_mkdir,
  "touch" => :cmd_touch,
  "rm" => :cmd_rm,
  "mv" => :cmd_mv,
  "cp" => :cmd_cp,
  "echo" => :cmd_echo,
  # Utility
  "which" => :cmd_which,
  "true" => :cmd_true,
  "false" => :cmd_false
}

@spec parse_name(String.t()) :: command_name()
def parse_name(name) when is_binary(name) do
  Map.get(@known_commands, name, {:unknown, name})
end

Three security properties here:

No atom DoS - We never call String.to_atom/1 on untrusted input. Unknown commands become {:unknown, "curl"} tuples, not atoms.
Compile-time verification - The allowlist is a module attribute, so the compiler validates it exists.
The cmd_ prefix trick - Why :cmd_true instead of :true? Because :true and :false are falsy in Elixir pattern matching! Using prefixed atoms avoids this footgun entirely.

Pattern 2: The 404 Principle

When an agent tries to access /etc/passwd, should you return "permission denied" or "not found"?

"Permission denied" leaks information - the agent now knows the file exists. It can probe your filesystem structure. Instead, Truman Shell returns "not found" for any path outside the sandbox:

# In TrumanShell.Support.Sandbox
def validate_path(path, sandbox_root) do
  sandbox_expanded = Path.expand(sandbox_root)

  # Reject absolute paths outside sandbox
  # Instead of silently confining /etc -> sandbox/etc, we reject entirely.
  # This is more honest - the AI learns sandbox boundaries explicitly.
  if String.starts_with?(path, "/") and not path_within_sandbox?(path, sandbox_expanded) do
    {:error, :outside_sandbox}
  else
    rel_path = Path.relative_to(path, sandbox_expanded)

    case Path.safe_relative(rel_path, sandbox_expanded) do
      {:ok, safe_rel} ->
        {:ok, Path.expand(safe_rel, sandbox_expanded)}

      :error ->
        {:error, :outside_sandbox}
    end
  end
end

# Check using proper directory boundary, not just string prefix!
# "/tmp/sandbox/file" is within "/tmp/sandbox"
# "/tmp/sandbox2/file" is NOT within "/tmp/sandbox"
defp path_within_sandbox?(path, sandbox) do
  path == sandbox or String.starts_with?(path, sandbox <> "/")
end

The subtle security bug this prevents: /tmp/sandbox2/secrets would pass a naive String.starts_with?(path, "/tmp/sandbox") check. The trailing slash in sandbox <> "/" ensures we're checking directory containment, not string prefix.

When commands use this validation, they transform the error into a POSIX-style message:

# In TrumanShell.Commands.Rm
case Sandbox.validate_path(target_rel, context.sandbox_root) do
  {:ok, safe_path} ->
    soft_delete(safe_path, file_name, context.sandbox_root, opts)

  {:error, :outside_sandbox} ->
    # 404 Principle: "No such file" not "Permission denied"
    {:error, "rm: #{file_name}: No such file or directory\n"}
end

Pattern 3: Soft Delete Everything

Here's where Truman Shell diverges most from real bash. The rm command never deletes anything:

# In TrumanShell.Commands.Rm
@moduledoc """
Handler for the `rm` command - SOFT DELETE files to .trash.

**CRITICAL**: This command NEVER actually deletes files!
Instead, it moves them to `.trash/{unique_id}_{filename}` for auditability.
"""

defp move_to_trash(safe_path, file_name, sandbox_root) do
  trash_dir = Path.join(sandbox_root, ".trash")
  File.mkdir_p(trash_dir)

  # Generate unique-prefixed name to avoid collisions
  unique_id = System.unique_integer([:positive, :monotonic])
  basename = Path.basename(file_name)
  trash_name = "#{unique_id}_#{basename}"
  trash_path = Path.join(trash_dir, trash_name)

  case File.rename(safe_path, trash_path) do
    :ok -> {:ok, ""}
    {:error, _} -> {:error, "rm: #{file_name}: No such file or directory\n"}
  end
end

The System.unique_integer([:positive, :monotonic]) guarantees unique IDs even for rapid successive calls. When an agent runs rm -rf important_data/, you can always find it in .trash/123_important_data/.

This pattern is about auditability over efficiency. For an AI sandbox, being able to trace what happened is more valuable than saving disk space.

Pattern 4: The Command Behaviour

Each command implements a simple behaviour that enforces consistent interfaces:

defmodule TrumanShell.Commands.Behaviour do
  @type args :: [String.t()]
  @type context :: %{
    sandbox_root: String.t(),
    current_dir: String.t()
  }

  @type side_effect :: {:set_cwd, String.t()}
  @type result :: {:ok, String.t()} | {:error, String.t()}
  @type result_with_effects :: {:ok, String.t(), [side_effect()]} | {:error, String.t()}

  @callback handle(args(), context()) :: result()
end

The interesting pattern here is side effect separation. Commands like cd need to change directory, but the command itself doesn't mutate state. Instead, it returns a directive:

# In the executor
case module.handle(args, context) do
  # Handle side effects from commands like cd
  {:ok, output, set_cwd: new_cwd} ->
    set_current_dir(new_cwd)
    {:ok, output}

  # Normal success/error pass through
  result ->
    result
end

This keeps command handlers pure and testable - they describe what should happen, the executor makes it happen.

Pattern 5: Dispatch via Module Map

The executor routes commands using a compile-time map:

# In TrumanShell.Stages.Executor
@command_modules %{
  cmd_cat: Commands.Cat,
  cmd_cd: Commands.Cd,
  cmd_cp: Commands.Cp,
  cmd_grep: Commands.Grep,
  cmd_ls: Commands.Ls,
  cmd_rm: Commands.Rm,
  # ... etc
}

defp execute(%Command{name: name, args: args}, opts)
     when is_map_key(@command_modules, name) do
  module = @command_modules[name]
  context = build_context(opts)
  module.handle(args, context)
end

defp execute(%Command{name: {:unknown, name}}, _opts) do
  {:error, "bash: #{name}: command not found\n"}
end

The is_map_key/2 guard ensures we only dispatch to known modules. Unknown commands hit the fallback clause with a bash-style error message. The agent gets the feedback it expects from a "real" shell.

Why Elixir?

You could build this in any language, but Elixir's pattern matching makes the security model explicit and exhaustive. When you write:

def handle(["-f" | rest], context), do: handle_rm(rest, context, force: true)
def handle(["-r" | rest], context), do: handle_rm(rest, context, recursive: true)
def handle(["-rf" | rest], context), do: handle_rm(rest, context, force: true, recursive: true)
def handle([file_name | _rest], context), do: handle_rm([file_name], context, [])
def handle([], _context), do: {:error, "rm: missing operand\n"}

The compiler warns if you miss a case. Every flag combination is visible. There's no hidden else branch where unexpected input slips through.

There's also a romantic historical angle: Elixir runs on the BEAM, a VM from the 1980s built for Erlang. But Erlang came from 1970s research on The Actor Model - conceived specifically for Artificial Intelligence. The researchers realized each AI would need its own isolated bubble of memory, compute, and actions. 50 years later, LLMs have finally "come home" to the BEAM.

Practical Takeaways

If you're building AI agent infrastructure, here are patterns you can steal:

Allowlist over blocklist - Define what's permitted, not what's forbidden. Your security surface becomes the allowlist, not "everything minus exceptions."
The 404 Principle - Never leak information about protected resources. "Not found" for everything outside the boundary.
Reversible by default - Make all destructive operations soft-deletes. Your future self will thank you when debugging agent behavior.
Side effect separation - Commands describe effects, executors apply them. Keeps handlers testable and control flow visible.
Compile-time security - Use module attributes and pattern matching to make security rules static and exhaustive.

What's Next

Truman Shell pairs with IExReAct - an Elixir REPL using the LLM agent Reason/Act pattern. Truman for the filesystem, IExReAct for the brain. Together they form a sandboxed environment where AI agents can think and manipulate files without escaping through helpfulness.

The code is MIT licensed. If you're building AI tooling and want to chat about security patterns, architecture decisions, or why functional programming is a natural fit for agent sandboxes, feel free to reach out or open an issue on GitHub.

Or join me in the VeryHumanAI Discord (I’m conroywhitney aka YOЯNOC): discord.gg/Y52a6RqX

"And in case I don't see ya, good afternoon, good evening, and good night!"

Have you built similar sandboxing infrastructure? I'd love to hear what patterns worked for you in the comments.

From $95/Hour to "I Feel Like a New Man": Why Teaching Beats Billing in the Age of AI

YOЯNOC — Tue, 01 Jul 2025 17:37:17 +0000

I just spent four hours teaching a client to code. We both had a lot of fun. No invoice was sent. This is the future of freelancing.

The Comfortable Rut

For years, Clifton and I had our shared pattern. He'd bought Clear Check from an indie marketplace but didn't know how to code. So a few times a year, he'd reach out on Upwork and link to a feature list. I'd code, he'd pay, and we'd both say "see you next time!"

It worked, but something about it felt... limiting -- for the both of us. I loved helping him with his business, but I hated being the bottleneck for what it could become. And if I was spending my time coding for him, I was limited in how many people I could help.

The "What If?" Moment

When Clifton reached out last week, I had this wild thought: "What if instead of me coding for you, we code together? What if you could learn to make these changes yourself?"

I know — "freelancer suggests client learns to not need freelancer". Not a great business model. But here's the thing: After years of coding, I'd noticed some shifts, both in myself, and in the software industry in general...

Everything's Different Now

The moat dried up: That specialist knowledge of syntax and file structures? It's all in AI assistants now. I rarely hand-write code anymore at my day job as a Senior Software Engineer. It's all vibes now -- collaboration with an AI assistant who does the coding while I steer our pair programming session.

The game flipped: My freelance work through my agency, Reification Labs, used to be careful, incremental, ordered — "validate, prototype, build, scale" — because building was expensive and time consuming. Now? AI lets us over-build fast with tools like v0, test them out quickly, then refine as need-be. More jazz, less classical.

Code's just the medium: I've always believed programming is a means to an end. Good craftsmanship matters, yes, but at the end of the day it's about the impact that software can make on real people's lives. That's what's always kept me going.

Sunday Morning Magic

Clifton admitted he'd been secretly hoping we could try this. So this past Sunday morning at 7am his time (talk about dedication!), we dove in.

The setup was tedious, I'm not going to lie:

GitHub ✓
Gitpod ✓
Heroku pipelines ✓
VS Code + GitHub Copilot ✓
Claude 4 subscription ✓
Not my favourite things to configure, but...

It was all worth it when the magic moment arrived.

The Vibe Shift

I showed Clifton how to introduce himself to Claude in the VS Code chat window — not as someone extracting code, but as someone learning to build. He explained who he was, what Clear Check does, who it helps, and his unique situation as a product-owner-turned-developer.

Claude was genuinely intrigued. It's not every day a non-technical founder comes asking to learn rather than just asking for code. The conversation felt more like meeting a mentor at a coffee shop than interrogating a machine.

They picked the perfect baby step: make the copyright year dynamic.

Tiny? Sure. But this little thing had bugged Clifton for months. And after all, it wasn't really about the copyright, it was about what happened next...

The Full Journey

With Claude's guidance, Clifton:

Created a feature branch ✓
Wrote a commit message ✓
Pushed to GitHub ✓
Created a PR ✓
QA'd in the Heroku review app ✓
Merged it ✓
Watched it auto-deploy ✓
Got to see his changes live in production ✓

Magic.

Four hours. One tiny feature. One transformation.

"I feel like a new man!", he confessed as we wrapped up our call.

This is what it's all about. That feeling, right there.

The Real Shift (Here's Where It Gets Deep)

Something profound had just happened that I only fully grasped later that day. We'd broken a pattern—not just the "hire-code-pay-repeat" cycle, but something deeper.

The old model was extractive. I took his money in exchange for code, but despite helping him with his business, he was still dependent on me and had to balance my hourly rate against each feature's value.

The new model is collaborative. Empowering. And fun as hell. He's now only limited by his own time and imagination. No more bottleneck. No more dependency. Even Claude seemed energized by teaching rather than just pumping out code!

Is he ready to build the next Facebook? No, of course not — it was only four hours. But he's crossed the threshold from planning to shipping; from bottlenecked to boundless; from 'someday' to 'right now'. He can handle 80% of what he needs to extend Clear Check, and knows when to ask for help on the rest.

Enter Very Human AI

This is why I've started Very Human AI—a community for people like Clifton (like you?) who want to transform themselves from product owners (or product dreamers) to product builders through shared connection and AI collaboration.

It's not another coding bootcamp. It's a community for people ready to shift from extraction to collaboration—both with each other, and with AI.

We're exploring what happens when we approach AI as creative partners rather than code vending machines. When we teach each other instead of gatekeeping. When we measure success in "#wins" rather than billable hours.

The old model was "I'll fish for you for $95/hour." The new model is "I'll teach you to fish, then we'll swap fishing stories."

Is This Calling You?

Are you:

A product owner with features stuck in your backlog?
A developer curious about this "vibe coding" approach?
Someone with an idea but "no technical background"?
A freelancer ready to teach instead of just deliver?
Simply excited about AI as a creative partner, not a tool?

Come find us in the Very Human AI Discord.

Because in the age of AI, the question isn't "can you code?"

It's "are you ready to?"