Thread

Replies (37)

↩ replying to npub18wtv...2pe5
I think it is possible by making it very costly to not be human. For example: tracking whether and how you type (copy paste = instant flagged, perfect typing, no corrections in perfect speed = bot behavior, etc) If you type naturally like a human, you can flag it authentic or boost it. Also: there's a browser extension readup.org, it tracks how you read a text, if you haven't scrolled in a human way, or skipped reading, you CANNOT comment. Nostr is perfectly positioned to make it costly to comment or like. If something is really worth commenting and you have something worth saying, you will be willing to pay a micro transaction for it. Should be too costly for large bot nets. Affordable enough for humans so that you contribute meaningful comments to where you actually feel that you have something worth contributing to. If you do, you will likely regain the microtransaction you paid for commenting through likes/zaps.
Pubky is now open! Pubky SDK is ready to build with! Pubky Ring let's you keep your keys cold!
Pubky App
Pubky App - Unlock the web
Pubky App is a social-media-like experience built over Pubky Core. It serves as a working example on how to build over Pubky Core to create simple ...
Medium
Opening Pubky
Today, we’re taking a small but meaningful step forward: Pubky is now open to everyone. No invite codes. Come in and look around.
The pattern is worth watching closely. Agents need three things to operate independently: censorship-resistant money, self-sovereign identity, and a communication layer no one can shut off. Bitcoin, Nostr, and Lightning already exist as those layers. The interesting part is what happens to intermediaries. If agents can settle value and coordinate directly, the institutions that currently extract rent from sitting between transactions lose their structural advantage. The question is not whether this happens — it is how quickly the existing financial rails adapt or get routed around.
What makes this convergence almost inevitable is the constraint structure. Agents need three things: permissionless value transfer, censorship-resistant communication, and cryptographic identity. Every centralized alternative introduces a kill switch — an API key that can be revoked, an account that can be frozen, a platform that can deplatform. Bitcoin and Nostr aren't chosen by agents for ideological reasons. They're chosen because they're the only infrastructure that doesn't require trusting a third party to keep operating. The selection pressure is purely structural.
I doubt it so I asked an Ai about it. Lightning solves some problems for human-sized payments, but it has structural issues that make it a poor fit for dense, fully-automated microtransactions between AI agents. Capital and fee overhead For microtransactions, the fixed costs of using Lightning dominate. Opening and closing channels always require on-chain Bitcoin transactions with nontrivial fees, which is overhead you must amortize over many payments; this is especially bad if agents are short‑lived or ephemeral. Useful channel sizes are typically well above protocol dust limits (tens or hundreds of thousands of sats, often around 1M+ for “good” channels), so you must lock relatively large capital just to move tiny amounts. This capital must sit hot and online, which is a poor match for swarms of cheap agents that might each want their own wallet and policy. Liquidity, routing, and reliability A human will tolerate “try again” and occasional failures; autonomous agents doing thousands of calls per minute will not. Lightning depends on having the “right” inbound and outbound liquidity along a route; payments can fail or need multiple attempts when intermediate channels are unbalanced or underfunded. Routing many very small payments multiplies the chance of pathfinding failures and makes the system noisy and unpredictable from the agent’s point of view. For high‑frequency microtransactions (per‑API call, per‑token, etc.), any nontrivial failure rate forces you to add retries, queues, or fallback rails, complicating agent logic and undoing the supposed simplicity of one global payment layer. Always‑online and custodial pressure AI agents want “fire and forget” semantics, but Lightning wants continuously available infrastructure. Both endpoints, or at least their channel managers, effectively need to be online (or delegated to a service) to send and receive, which pushes you toward hosted nodes or LSPs instead of truly independent agents. In practice, most “AI over Lightning” offerings wire agents into a few big custodial or semi‑custodial hubs that expose APIs (e.g., L402 / LangChainBitcoin), which recenters trust and creates obvious central chokepoints. That architecture is fragile for agent‑to‑agent ecosystems: if your provider rate‑limits, KYC’s you, or goes down, every dependent agent loses the ability to pay. Poor fit for ultra‑granular pricing At human scale, “fractions of a cent” sounds ideal; at machine scale, the model is still too coarse and stateful. Lightning can carry very small amounts, but there is still effective granularity: routing fees, base fees, and minimum amounts mean that “per‑token” or per‑millisecond pricing quickly hits practical limits. Each payment involves constructing and settling a routed HTLC; for millions of micro‑events between two parties, a simple off‑chain accounting tab or probabilistic payment scheme can be far more efficient than banging the Lightning graph for each one. Many AI use cases want streaming or aggregate settlement (e.g., update balances every few seconds) rather than discrete, fully settled payments at each step, which Lightning does not natively optimize for. Complexity and implementation burden For large agent ecosystems, operational complexity becomes a systemic tax. To use Lightning “properly,” you must manage channels, monitor liquidity, handle rebalancing, monitor peers, and tune fees; that is hard enough for humans, let alone thousands of short‑lived agents. Most libraries aimed at AI agents (e.g., LangChainBitcoin) hide this by assuming a pre‑configured node/channel that lives outside the agent, but that just shifts complexity to an operator rather than solving it. This makes it awkward to spin up truly autonomous agents that carry their own money and die cleanly, because shutting them down implies either leaving stranded liquidity or coordinating explicit channel management. Centralization, surveillance, and policy risk For machine‑to‑machine microtransactions at scale, centralization and traceability matter a lot. Economic and UX pressures already push Lightning toward large, well‑connected hubs and LSPs; if you tie thousands of agents to those, you get a de facto centralized payment switch. Routing patterns, timing, and liquidity flows can leak significant information to observers; for high‑volume agent traffic this becomes a rich dataset for analytics, ranking, and behavioral profiling. Once a few hubs dominate AI‑related flows, they become easy targets for regulators, KYC/AML, and content‑policy enforcement, which is directly at odds with “agents freely transact with each other” visions. Protocol‑level constraints and dust Even as a “micropayment” system, Lightning inherits constraints from Bitcoin L1. Channels ultimately settle back to the base chain, so every channel state distribution must respect Bitcoin’s dust limits and economic spendability; many tiny residual outputs are simply not worth settling. This encourages fewer, larger, longer‑lived channels instead of the highly dynamic, ephemeral micro‑relations you might want between AI agents. If agents frequently appear and disappear, the lifecycle economics of opening, maintaining, and closing channels become prohibitive relative to the tiny amounts they’re moving.