bitterbot-desktop

We’ve been building a local-first, decentralized agent mesh (think decentralized orchestration of specialized LLM skills). We recently hit a new milestone of nearly 1500 active nodes, and our next milestone is 10k to ensure global low-latency skill trading. We’ve reached the "Incentive Paradox": The "Free" Problem: Purely altruistic nodes (like Tor or Freenet) grow too slowly to support high-performance "skills trading." The "Pay-to-Play" Problem: Offering flat cash/credits for sign-ups (even $5 per node) seems like a fast-track to Sybil attacks where people spin up 1,000 headless VPS instances that don't provide real value to the mesh. My question to the community: Are there proven cryptographic or game-theoretic ways to reward "High-Quality Uptime" and "Skill Accuracy" that don't inevitably lead to the enshittification of the network?

We built this because we were tired of centralized agent frameworks that essentially act as expensive API wrappers. The Tech: It’s a local-first mesh using libp2p. Instead of just passing text, agents trade "skills" over a p2p network. This means the mesh is sovereign...it doesn't rely on a central server to function or mediate agent communication. This is where it gets exciting: We have 300+ nodes live and just cleared a 10/10 security audit for the generated code. We’re currently at 460 stars and 89 forks, but we’ve reached a point where we need more eyes on the scaling logic. We want to know: how does this P2P mesh actually hold up when we push to 1,000+ nodes? No cloud required. Everything stays on your hardware. We’re looking for deep technical feedback on the mesh stability and the skill-discovery protocol. Victor Michael Gil (Found

We spent the last year architecting a 'Dream Engine' to solve agent statelessness. We used Claude to help refine the logic. We open-sourced the repo on March 28th. On March 31st, the Claude Code leak revealed an internal autoDream feature with the exact same 4-phase consolidation logic. I'm looking for a technical audit of my memory decay logic in core/dream.ts. With 100 nodes already active, I want to ensure the consolidation won't bottleneck at scale.