DEV Community: Web Agent Bridge

WAB web agent bridge

Web Agent Bridge — Wed, 20 May 2026 16:11:20 +0000

We are opening Web Agent Bridge (WAB) to deeper technical review, testing, and critical feedback from developers, security researchers, browser automation engineers, AI-agent builders, and privacy-focused infrastructure communities.

WAB is an open AI ↔ Web protocol and agent interoperability layer designed to reduce brittle DOM automation and replace guesswork with signed, machine-readable capability contracts.

The project currently includes:

DNS-based discovery (_wab)
/.well-known/wab.json
Signed trust profiles (Ed25519)
Ring 4 trust verification
Agent capability negotiation
Intent-aware routing
Governance and audit layers
Privacy budget declarations
Refusal and constitutional invariant handling
Cross-agent verification flows
SDKs and framework adapters
MCP and browser-agent integrations

The broader goal is simple:

Create a predictable, inspectable, privacy-aware interface between AI agents and the web — without requiring centralized control, invasive tracking, or fragile scraping logic.

We are specifically interested in feedback regarding:

protocol design
security assumptions
trust boundaries
abuse resistance
privacy implications
interoperability
schema clarity
agent discoverability
edge-case behavior
failure modes
governance architecture
machine-readability
developer ergonomics

We are not looking for hype.

We are looking for:

serious testing
architectural criticism
implementation review
adversarial thinking
interoperability experiments
independent verification

If parts of the design are flawed, we want to know.
If assumptions break under real-world conditions, we want to see it.
If there are better approaches, we are open to them.

The protocol, SDKs, and specifications are public and reviewable.

Repository:
https://github.com/abokenan444/web-agent-bridge

Documentation:
https://webagentbridge.com/docs

Architecture:
https://webagentbridge.com/ring4

The long-term health of agent ecosystems will likely depend on open, inspectable, privacy-respecting standards rather than opaque automation layers.

Constructive criticism is welco

WAB web agent bridge

Web Agent Bridge — Sat, 16 May 2026 07:10:57 +0000

Everyone is talking about ACP, UCP, and WebMCP.
OpenAI + Stripe built ACP. Google built UCP with Walmart, Visa, Mastercard. Chrome + Edge + W3C built WebMCP.
Big names. Massive resources. Real traction.
But they all solve the same problem: how an AI agent completes a purchase.
None of them answer the question that comes before:
→ How does an agent know it can TRUST the site it's about to transact with? → What stops an agent from executing on a phishing site? → Who proves what the agent actually did — and makes that proof public and verifiable? → What happens when an agent touches Stripe, Gmail, or ClickUp at 3am while you're asleep?
This is the gap. And it's not small.
It's called Web Agent Bridge (WAB).
Here's what makes it structurally different from everything else in the space:
——
/ / → Agent reaches checkout → Agent verifies trust → operates within governance → proves what it did → then reaches checkout
These aren't competing layers. WAB sits above all of them.
——
What WAB has shipped in 52 days:
Ed25519-signed manifests + DNSSEC trust — cryptographic proof that a site is who it claims to be, at the protocol level, not just TLS
Agent Governance Layer — permission boundaries, human approval gates, kill switch, HMAC tamper-evident audit chain. An agent literally cannot exceed what you defined, even at 3am
ATP (Agent Transaction Primitive) — signed intent contracts, idempotent transactions, Ed25519-verifiable receipts. Public verification with zero authentication required. The buyer, seller, auditor, and court can all verify what happened — without trusting WAB
Ring 4 Trust Handshake — an 8-step cryptographic handshake protocol for sovereign AI agents. Already tested live by VEXR Ultra v4, which completed 3 cryptographic verification tests in under 100ms
ShieldLink — cryptographically signed links for banks and payment processors. Anti-phishing at the link level, before the user even clicks
Zero-Config Adoption — npx wab-init auto-detects Next.js / Nuxt / SvelteKit / Astro / Laravel / WordPress and scaffolds everything in under 60 seconds
Truth Layer + Reality Anchor — cross-site fact verification with weighted consensus to eliminate LLM hallucinations about prices, availability, and ratings
445/445 tests passing
——
To put this in context:
The agentic commerce market is moving fast.
AI-referred traffic to US retail sites grew 1,200% while traditional search declined 10%. Coinbase's x402 processed 165 million agent transactions in its first months.
Every major player is racing to define how agents buy.
But nobody has defined how agents TRUST — and how transactions become PROVABLE.
That's the layer WAB is building. And it's already live.
——
The tagline shifted this week from: "The open AI↔Web protocol"
To: "The trust + transaction layer for agentic commerce."
That's not a rebrand. That's a positioning statement that places WAB above every commerce protocol in the stack — as the infrastructure that makes all of them trustworthy.
——
"Built for nothing, proven for everything."
If you're building AI agents, evaluating agentic commerce infrastructure, or thinking about what the trust layer of the AI economy looks like —
This is worth your attention: github.com/abokenan444/web-agent-bridge webagentbridge.com npm install web-agent-bridge

AgenticCommerce #AIAgents #WebAgents #MCP #OpenSource #ACP #TrustLayer #AI #DeveloperTools #Netherlands

We Built a DNS-Based Discovery Protocol for AI Agents — Here's How It Works

Web Agent Bridge — Thu, 30 Apr 2026 14:24:52 +0000

AI agents are getting smarter — but they're still blind to most of the web.

When an AI agent visits a website, it has no idea whether that site wants to be interacted with by AI, what capabilities are available, or how to communicate in a structured way. It's like knocking on a door with no sign, no bell, and no mailbox.

We built WAB (Web Agent Bridge) to solve this. And the core of our discovery mechanism is something you already know: DNS.

The Problem: AI Agents Have No Map

Today's AI agents browse the web like tourists without a guidebook. They can see a website, but they can't understand it at a protocol level:

Is this site AI-friendly?
Does it have an agent API?
What permissions does it grant to AI agents?
How should the agent authenticate?

There's no standard way for a website to declare its AI capabilities. Until now.

Our Solution: DNS-Based Discovery

We took inspiration from how email servers announce their capabilities via DNS (SPF, DKIM, DMARC records). We applied the same pattern to AI agent discovery.

Step 1: A website owner adds a single DNS TXT record:

_wab.yourdomain.com  TXT  "v=wab1; endpoint=https://yourdomain.com/.well-known/wab.json"

Step 2: The wab.json file declares the site's AI capabilities:

{
  "version": "1.0",
  "agentMode": "enabled",
  "permissions": ["read", "navigate"],
  "rateLimit": "100/hour",
  "contact": "ai@yourdomain.com"
}

Step 3: Any AI agent can discover this in milliseconds using DNS over HTTPS (DoH):

const response = await fetch(
  'https://cloudflare-dns.com/dns-query?name=_wab.yourdomain.com&type=TXT',
  { headers: { 'Accept': 'application/dns-json' } }
);

That's it. One DNS record. Zero code changes to your website.

Why DNS? Why Not a Meta Tag or HTTP Header?

Great question. We considered all three:

Method	Pros	Cons
DNS TXT	Works before HTTP, cacheable, infrastructure-level	Requires DNS access
Meta tag	Easy to add	Requires page load, not machine-readable at scale
HTTP Header	Server-side control	Requires HTTP request first

DNS wins because:

It's pre-HTTP — an agent can check discovery before making any web requests
It's cached globally — CDNs and resolvers cache DNS, making it fast at scale
It's infrastructure-level — it signals intent at the domain level, not just a page
It's already trusted — DNS is the backbone of internet identity

Real-World Example: webagentbridge.com

We dogfood our own protocol. Here's our live DNS record:

_wab.webagentbridge.com  TXT  "v=wab1; endpoint=https://www.webagentbridge.com/.well-known/wab.json"

You can verify it right now:

dig TXT _wab.webagentbridge.com +short

Or try our Live Verifier — paste any domain and see if it supports WAB Discovery in real-time.

Setting It Up: One Click with Any DNS Provider

We built a step-by-step activation guide for every major DNS provider:

Cloudflare:

Go to DNS → Records → Add Record
Type: TXT, Name: _wab, Content: v=wab1; endpoint=https://yourdomain.com/.well-known/wab.json
TTL: Auto → Save

cPanel:

Zone Editor → Add Record
Same fields as above

GoDaddy, Namecheap, AWS Route 53 — all covered in our activation guide.

Propagation takes 1-48 hours, but usually under 5 minutes with Cloudflare.

The Bigger Picture: An Open Protocol for AI-Web Interaction

WAB DNS Discovery is just the first layer of a larger protocol stack:

The full stack includes:

Agent Mode — a JS SDK that makes any website AI-navigable
Sovereign Shield — privacy controls for site owners
WAB Browser — a sovereign browser with built-in WAB support
API Gateway — rate limiting, auth, and monitoring for AI traffic

All open source. All composable.

Get Started

# Add to your DNS (replace with your domain)
_wab.yourdomain.com  TXT  "v=wab1; endpoint=https://yourdomain.com/.well-known/wab.json"

# Verify it works
curl "https://cloudflare-dns.com/dns-query?name=_wab.yourdomain.com&type=TXT" \
  -H "Accept: application/dns-json"

GitHub — Star us if you find this useful!
Live DNS Verifier
One-Click Activation Guide
Full Documentation

We're building the infrastructure layer for the AI-web future. If you're working on AI agents, browser automation, or web protocols — we'd love to hear from you.

What do you think? Is DNS the right layer for this? Drop a comment below.

I Built an Open‑ Source OS for AI Agents – And It’s Ready for You

Web Agent Bridge — Sun, 19 Apr 2026 08:40:48 +0000

Two weeks ago, Web Agent Bridge was a clever middleware that helped AI agents talk to websites without breaking.

Today, it’s a completely different beast.

After a massive rewrite (v2.0 → v3.1), WAB has evolved into a full Agent Operating System – with its own protocol, an open‑core business model, a desktop browser, and even a no‑code workspace for non‑developers.

And yes, it’s still MIT‑licensed at its core.

Let me show you what changed – and why you should care.

🔥 The Problem That Never Died

Every AI agent that needs to click a button or fill a form relies on DOM scraping – CSS selectors, XPath, waiting for elements.
It breaks every time a designer moves a

. It’s slow, fragile, and a nightmare to maintain.

WAB flips the model: websites expose a window.AICommands interface. Agents discover actions (signup, add_to_cart, checkout) and execute them directly. No parsing, no guesswork.

That was v1.0.
Now, v3.1 is something else entirely.

⚙️ What’s New in WAB v3.1 (The “Agent OS” Release)

Agent Operating System (Agent OS)

· Standardised agent‑to‑agent protocol (WABP) with command registry and capability negotiation.
· Complete runtime: event bus, task scheduler, state management, replay engine.
· Built‑in observability – logs, traces, metrics.

Web Agent Protocol (WAP)

· A discovery‑first protocol using /.well-known/agent-tools.json.
· Sites declare their capabilities once, and any agent (MCP, REST, or browser‑based) can understand them.
· WAP is transport‑agnostic – same interface works for CLI, WebSocket, or HTTP.

Open‑Core + Growth Suite

· Core remains MIT (the bridge script, SDK, WAP, and Agent OS runtime).
· Premium features (Fairness Engine, Threat Shield, Dynamic Pricing Shield) are server‑side only.
· First‑class billing, metering, and a marketplace for agent components (15% revenue share).

Agent Workspace (No‑Code UI)

· Drag‑and‑drop interface for regular users.
· Create price‑comparison agents, hotel booking agents, or local‑store finders without a single line of code.
· Full RTL + Arabic support.

WAB Desktop Browser + PWA

· Electron browser with ad blocker (80+ domains), scam shield, fairness ranking, and a built‑in AI agent chat.
· Mobile PWA works offline – install it like any other app.

🧠 Why This Matters for Developers

· You can build agents that actually work.
WABAgent (Puppeteer/Playwright) gives you agent.execute('addToCart', { sku: '...' }) – no selectors, no waits.
· You can extend WAB via plugins.
Dynamic hook system, priority ordering, and audit logging. Build your own pricing shield or custom action pack.
· You can run everything locally.
No cloud required. npx web-agent-bridge start spins up the full Agent OS on your machine.
· You can monetise your work.
The built‑in marketplace lets you sell agent templates, vision models, or automation packs.

🚀 Try It in 30 Seconds

npx web-agent-bridge start

Then open http://localhost:3000 – you’ll see the new Sovereign Dashboard, the Agent Workspace, and the live demo store.

Or download the WAB Browser (desktop) and browse any site with an AI agent in your sidebar.

📦 What’s Still Open Source (MIT)

· window.AICommands bridge script
· Agent SDK (WABAgent for Puppeteer/Playwright)
· WAP protocol + discovery
· React / Vue / Svelte / LangChain packages
· WordPress plugin
· All agent examples and templates

The code you love is still free. The extra muscle (fairness, threat detection, pricing shield, marketplace) is what makes the project sustainable.

👉 I Need Your Feedback

· Does the Agent OS feel like the right abstraction?
· Would you use WAP to make your own site agent‑ready?
· What’s missing before you’d bet your production automation on it?

Star the repo, try the demo, and let me know.
Let’s build the agent‑first web – together.

🔗 GitHub: github.com/abokenan444/web-agent-bridge
🌐 Website: webagentbridge.com
📦 npm: npx web-agent-bridge start

How I made a Tor-based messenger use 400% less battery (without breaking privacy)

Web Agent Bridge — Sun, 15 Mar 2026 11:41:29 +0000

How I Built a Tor-Native Messenger That Uses 400% Less Battery (Without Sacrificing Privacy)

By abokenan444 – Solo developer, privacy advocate, and creator of Shield Messenger

📱 The Problem: Why Most "Private" Messengers Aren't Really Private

When I started Shield Messenger, I asked myself a simple question: Why do even the most secure messengers still leak metadata?

Signal, for example, encrypts your messages beautifully. But their servers still know:

· Who you're talking to (even if they don't know what you're saying)
· When you're talking (timing patterns)
· Your IP address (unless you use a VPN)

I wanted something different. A messenger that treats privacy as architecture, not a feature.

The obvious answer was Tor. But there's a reason most apps don't build directly on Tor: battery life is terrible.

🔋 The Battery Nightmare: Why Tor Kills Your Phone

When you run a Tor hidden service (which is how P2P messaging works), your phone has to maintain several persistent TCP connections to guard nodes. This prevents the operating system from entering deep sleep mode.

On Android, deep sleep is when the CPU shuts down almost entirely, saving massive amounts of power. But with Tor, your phone stays awake, listening for incoming connections 24/7.

The result: A messaging app that drains your battery 10-15% per hour, even when you're not using it.

I measured it. It was unusable for daily communication.

🚫 Why I Rejected Firebase/APNs (The Easy Way Out)

The standard solution to battery drain is to use Firebase Cloud Messaging (FCM) or Apple Push Notification service (APNs) . Instead of keeping a persistent connection, the app sleeps, and Google/Apple's servers wake it up when a message arrives.

But this creates two problems:

Another centralized point of failure – Google or Apple could be forced to block your notifications.
Metadata leakage – Now Google/Apple knows who's messaging you and when.

For a privacy-first messenger, this was unacceptable. I needed a solution that kept 100% of traffic inside the Tor network.

💡 The Solution: Tor Push + Smart Sleep Mode

After months of experimentation, I developed a hybrid approach that I call "Tor Push with Smart Sleep Mode."

Here's how it works:

The Architecture

[Normal Operation]
    │
    ├── User actively chatting → Keep Tor circuits alive, instant delivery
    │
    └── Phone idle (screen off)
         │
         └── Smart Sleep Mode activated
              │
              ├── All non-essential circuits closed
              ├── Keep ONE lightweight guard connection
              ├── Schedule wake-up via AlarmManager every 15 min
              └── Wait for incoming TCP packets to trigger instant wake

Smart Sleep Detection

In the Android app, I monitor user activity:

class PowerManager(private val context: Context) {
    private val powerManager = context.getSystemService(Context.POWER_SERVICE) as android.os.PowerManager

    fun shouldEnterSleepMode(): Boolean {
        // Check if screen is off
        if (powerManager.isInteractive) return false

        // Check if user has been inactive for 5 minutes
        val lastActivity = PreferenceManager.getLastActivityTime(context)
        if (System.currentTimeMillis() - lastActivity < 300_000) return false

        // Check if any voice calls are active
        if (CallManager.hasActiveCall()) return false

        return true
    }
}

Modifying Arti for Sleep Support

The real magic happens in the Rust core. I extended Arti (Tor's Rust implementation) with a new sleep_mode() API:

// In secure-legion-core/src/tor/arti.rs

impl TorClient {
    pub fn set_sleep_mode(&mut self, enabled: bool) -> Result<()> {
        if enabled {
            // Reduce circuit maintenance frequency
            self.circuit_manager.set_maintenance_interval(Duration::from_secs(900)); // 15 min

            // Close all but one guard connection
            self.guard_mgr.set_min_guards(1);

            // Store circuit state for quick recovery
            self.persist_state()?;

            // Tell the runtime to use fewer timers
            self.runtime.set_timer_interval(Duration::from_secs(60));
        } else {
            // Restore normal operation
            self.circuit_manager.set_maintenance_interval(Duration::from_secs(30));
            self.guard_mgr.set_min_guards(3);
            self.restore_state()?;
            self.runtime.set_timer_interval(Duration::from_millis(100));
        }
        Ok(())
    }
}

The Wake-Up Mechanism

The key insight: TCP packets themselves can wake the device. When an incoming message arrives at your .onion address, the kernel receives a packet and can wake the app.

On Android, this requires holding a partial wake lock:

class TorService : Service() {
    private val wakeLock: PowerManager.WakeLock by lazy {
        (getSystemService(Context.POWER_SERVICE) as PowerManager)
            .newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "Shield:TorWakeLock")
    }

    private val handler = Handler(Looper.getMainLooper())

    // Called when Rust detects incoming traffic
    external fun onIncomingTraffic()

    fun handleIncomingMessage() {
        // Acquire wake lock briefly
        wakeLock.acquire(5000) // 5 seconds max

        // Process message
        processMessage()

        // Return to sleep if no activity
        if (!hasActiveUsers()) {
            handler.postDelayed({ goToSleep() }, 10000)
        }
    }

    private fun goToSleep() {
        // Tell Rust to enter sleep mode
        TorRust.setSleepMode(true)
        wakeLock.release()
    }
}

Scheduled Maintenance with AlarmManager

Even in sleep mode, Tor circuits need occasional maintenance. I use Android's AlarmManager for precise, battery-efficient wake-ups:

class CircuitMaintenanceScheduler(private val context: Context) {
    private val alarmManager = context.getSystemService(Context.ALARM_SERVICE) as AlarmManager

    fun scheduleMaintenance() {
        val intent = Intent(context, MaintenanceReceiver::class.java)
        val pendingIntent = PendingIntent.getBroadcast(
            context, 
            0, 
            intent, 
            PendingIntent.FLAG_UPDATE_CURRENT or PendingIntent.FLAG_IMMUTABLE
        )

        // Schedule inexact repeating alarm (battery efficient)
        alarmManager.setInexactRepeating(
            AlarmManager.ELAPSED_REALTIME_WAKEUP,
            SystemClock.elapsedRealtime() + AlarmManager.INTERVAL_FIFTEEN_MINUTES,
            AlarmManager.INTERVAL_FIFTEEN_MINUTES,
            pendingIntent
        )
    }
}

class MaintenanceReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context?, intent: Intent?) {
        // Wake up Tor for maintenance
        val wakeLock = (context?.getSystemService(Context.POWER_SERVICE) as PowerManager)
            .newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "Shield:MaintenanceWakeLock")

        wakeLock.acquire(60000) // 1 minute max

        // Tell Rust to perform circuit maintenance
        TorRust.performMaintenance()

        // Release after maintenance
        wakeLock.release()
    }
}

📊 The Results: 400% Battery Improvement

After implementing Smart Sleep Mode, I ran extensive tests on multiple devices:

Scenario Before (Standard Tor) After (Smart Sleep) Improvement
Idle (screen off, 8 hours) 18% battery drain 3% battery drain 500% better
Light usage (5 messages/hour) 12%/hour 2.5%/hour 380% better
Heavy usage (constant chatting) 22%/hour 8%/hour 175% better
Voice call (30 min) 15% drain 12% drain 25% better

Average improvement: ~400% reduction in background battery consumption.

And crucially, message delivery latency remained under 1 second in most cases. When a message arrives, the TCP packet wakes the device instantly.

🎯 Lessons Learned (For Other Tor-Native App Developers)

The 15-Minute Sweet Spot

Android's AlarmManager is optimized for intervals of 15 minutes or more. Anything shorter and you lose the battery benefits of inexact alarms.

Partial Wake Locks Are Your Friend

Never use FULL_WAKE_LOCK – it turns on the screen. PARTIAL_WAKE_LOCK keeps the CPU running but allows the screen to stay off.

Store Circuit State

When going to sleep, serialize your circuit state to disk. If the app is killed, you can restore circuits quickly when waking.

Padding Matters Even in Sleep

To prevent traffic analysis, I send small dummy packets even when sleeping. This maintains consistent traffic patterns and makes it harder to distinguish real messages from maintenance.

🌐 Beyond Battery: What's Next for Shield Messenger

Smart Sleep Mode was just the beginning. Shield Messenger now includes:

· Aethernet integration – When internet is down, it switches to community mesh networks (LibreMesh-based)
· Post-quantum crypto – ML-KEM-1024 + X25519 hybrid key exchange
· Built-in wallet – Real Solana + Zcash support, keys never leave device
· Duress PIN – A fake PIN that wipes everything and shows a decoy database

🤝 How You Can Help

Shield Messenger is open source and looking for contributors:

· Security researchers – Audit the crypto core, find vulnerabilities
· Rust developers – Help improve Arti integration
· Mobile devs – Polish the Android/iOS UI
· Privacy advocates – Spread the word

GitHub repo: github.com/abokenan444/shield-messenger

Join the discussion on Hacker News: https://news.ycombinator.com/threads?id=abokenan444
Web:
https://shieldmessenger.com

Building a truly private messenger is hard. Building one that people can actually use every day without carrying a charger is harder. But I believe it's possible – and I hope Shield Messenger proves it.

– abokenan444, March 2026