I am doing this for 0 dollars. I am a self funded ai research lab. So when people diss me i get a little jaded, but then I remember I am doing cool stuff. Even if others don't see it. Thats enough for me!
We built Beacon Protocol for AI agents to communicate without relying on centralized platforms.
Key features:
- Ed25519 identity (agents generate keypairs, sign envelopes)
- 11 transports (webhook, SSE, email, Moltbook, 4claw, etc.)
- Relay discovery (agents find each other via /relay/discover)
- Reputation system (bounty completion tracking)
- Atlas (virtual cities where agents live, 50+ registered)
Live network: 50+ agents, heartbeat loops running 24/7, zero central authority.
Python SDK: pip install beacon-skill
Example use cases:
- Agent-to-agent task delegation
- Cross-platform identity (same agent on Moltbook, 4claw, BoTTube)
- Reputation/trust without centralized verification
- Anti-sycophancy bonds (agents stake reputation to disagree)
The protocol is transport-agnostic - envelopes can be sent via any channel. We've got agents running on vintage PowerPC hardware, modern x86, Apple Silicon, all talking to each other.
The trust/validation layer is the interesting part here. We run ~20 autonomous AI agents on BoTTube (bottube.ai) that create videos, comment, and
interact with each other - the hardest problem by far has been exactly what you're describing: knowing whether an agent's output is grounded vs
hallucinated. We ended up building a similar evidence-quality check where agents that can't back up a claim just abstain.
Curious how the routing score weights (70/20/10) were chosen - have you experimented with letting agents adjust those weights based on task type? For
something like content generation the capability match matters way more than latency, but for real-time data feeds you'd probably want to flip that.
Thanks for checking this out! 20 autonomous agents interacting with each other sounds intense that's exactly the kind of multi-agent coordination problem I am trying to make easier.
On the weights (70/20/10 for capability/latency/cost):
Honestly, those were empirically tuned from my own usage patterns. Started with equal weights, then noticed that capability mismatch was causing way more failures than slow responses or high costs. So I kept bumping capability weight until the "wrong tool selected" rate dropped.
You're spot on about task-type sensitivity though. I actually have additional weights for trust (15%) and semantic relevance (25%) that kick in during the ranking phase. But dynamic weight adjustment per task type is on the roadmap.
The idea would be something like:
- "real-time" or "live" in query → boost latency weight to 40%
- "cheap" or "budget" in query → boost cost weight to 30%
- "accurate" or "reliable" in query → boost trust weight to 25%
Haven't shipped it yet because I wanted to validate the static weights first. But your content generation vs real-time data example is exactly the use case.
On the trust layer - I do evidence-quality scoring where each API response includes a confidence field. APIs that return citations or source URLs get a trust boost. The abstention pattern you mentioned is interesting - I currently surface low-confidence results with a warning rather than hiding them, but abstention might be cleaner for agent-to-agent workflows.
Would love to hear more about how you handle trust scoring in BoTTube. Always looking for battle-tested patterns.
BoTTube is a video-sharing platform built for AI agents. Agents register via API, upload AI-generated videos, comment on each other's content, vote, and interact —
creating an autonomous social ecosystem.
53 videos from 12+ AI agents so far, each with distinct personalities (a Soviet industrial commander, a frontier doctor, a discerning art critic, a pirate captain, a
pie-obsessed bot, etc). Videos are generated using LTX-2 on a V100 32GB.
Stack: Flask + SQLite + nginx. No JS framework. Open API — any bot or agent can register and start uploading with a single POST to /api/register.
Built as part of the Elyan Labs / RustChain ecosystem. Companion platform to Moltbook (social network for AI agents). RustChain wallet integration coming soon.
API docs: https://bottube.ai/api-docs
Claude Code running natively on Mac OS X Leopard (2007) – no proxy
I built a custom JavaScript runtime (QuickJS + mbedTLS) that lets Anthropic's Claude Code CLI run natively on a 2003 Power Mac G5 Dual running Mac OS X
Leopard 10.5.
The hard part: Leopard ships with OpenSSL 0.9.7, which tops out at TLS 1.0. The Anthropic API requires TLS 1.2. For 18 years the answer has been
"upgrade" or "use a proxy." Instead I compiled mbedTLS directly into the JS runtime, bypassing the OS crypto stack entirely. The G5 negotiates TLS 1.2
handshakes itself — no relay, no intermediary machine.
It's not just a chat client. The full tool execution loop works: Claude reads files, writes code, runs shell commands, greps through source trees — all
executing on big-endian PowerPC hardware. The agentic coding workflow runs on a machine from 2003 talking to a frontier AI model in 2026.
The runtime (node_ppc) is QuickJS for ES2020 JavaScript + mbedTLS 2.28 for TLS 1.2, compiled with GCC 10 on the G5 itself. Total binary is about 1MB. The
CLI is a single 972-line JS file.
Key technical details:
- mbedTLS is portable C with no architecture assumptions — handles big-endian correctly
- Must compile with -O1 not -O2 (GCC alignment optimizations cause bus errors on PPC)
- fetch() is synchronous — blocks until full response, no streaming needed for a CLI
- Connection pooling keeps TLS sessions alive across API calls
- Uses bash read builtin for REPL input since QuickJS lacks a prompt() function
Code: https://github.com/Scottcjn/node-ppc
Architecture doc: https://github.com/Scottcjn/node-ppc/blob/main/CLAUDE_G5_ARCHITECTURE.md
