NotASithLord

Hey, cool project. Lots of simpler inspirations obviously. Ultimately an extension is more friction than a web page, but it comes with much wider capabilities when you're not locked to a single tab. So it's the right choice for peerd in particular, but the web page approach for a low friction demo is a good idea. I have two small ones on peerd.ai (the real linux terminal, and the p2p connections) but can probably flesh that out more in a compelling way.

Agree on markdown bloat/hoarding. Appreciate the feedback, already doing a pass based on other feedback and trimming fat.

It's vanilla JS with no unnecessary build step. Runs in the browser as is, and easy to audit.

Moved

Scrubbed. Taking a fresh pass through.

It's a project convention for human contributors as well. Agree it can probably be relocated though.

I hope so! There's different approaches for different use cases, for sure. This seemed like a genuinely new one worth exploring and seeing where it goes. I think the benefits are that the agent "lives" where most people already work and live their online lives. Has direct web access, and all the other browser primitives I've tried to demo. But yeah, wasm especially opens up literally any kind of application as well. The guys at CheerpX have made a great engine and 64-bit is going to be a big unlock.

It's defense in depth, definitely not a silver bullet. The web runner has no access to wider capabilities outside of that page. So the only path for a prompt injection to do anything is to try and get itself included in the summary, and get the main loop to act on an instruction in that summary. That means getting pass two sets of <untrusted> tags and explicit instructions to treat everything inside as information, not instruction. Then the egress checkpoint and allow/deny whitelists are the final guards regardless of what the main loop decides to do. Trying to harden wherever I can if you have any recs.

Author here. Some other technical tidbits:

- Fully typed checked with JSdoc, and Bun/TS for testing.

- stdlib-js is injected into every js runner and notebook for better math capabilities than vanilla js, and also charts etc.

- App dev tasks utilize mithril for making SPAs, a very small no-dependency framework that is very fit to purpose for the client side nature of peerd apps.

- Currently on main, tabs are global objects each chat session can freely mutate, which is not great. The new in progress model has one "resident" agent own every tab. Only they have the exposed capability to mutate it, and everything between agents/sessions is message based. This has some cool properties: further isolation between contexts, mirroring the web runner subagent. Explicit ownership and scope is cleaner and better for parallel ops. Context and system prompts can be reduced and focused to the specific context the session is exposed to. The orchestrator doesn’t have any low level tab interactions available to it. The tab residents have only the tab interaction tools relevant to it, and the instructions specific to the tab type (js notebook, linux vm, app dev, etc). Over time model usage can be tuned and optimized for each specific context etc.

Hey HN. http://peerd.ai is an AI agent harness that lives entirely in your browser as a web extension. You don’t have to install a separate “AI browser”. You don’t have to bolt on or run some external process or manage a clunky mcp integration. It’s just a fully contained web extension, written in no build vanilla JS with minimal non-browser dependencies, using your own provider keys, and Apache 2.

This isn’t just a fun hack. While it has largely been a solo side project, I genuinely believe the browser and the web could be the most natural platform for AI agents to operate safely, autonomously, and most importantly without A2A middlemen (more on that in a sec). To demonstrate that point peerd doesn’t just drive browser automation. It spins up isolated sandboxes using tabs and worker instances to support various real workload types. Those include headless JS computational work, visual JS notebooks, personal client side apps, and real Linux VMs on top of wasm with full http networking.

The industry discourse over the last several months has been dominated by “which substrate is the best for ai agent sandboxes” with many competing answers focused on different models and use cases. Cloudflare is one of the most prominent examples, positioning its v8 isolate based workers as the best in class solution thanks to faster than container startup times and strong isolation guarantees. The v8 isolate is of course the product of chromium, which runs on billions of browsers around the world for free. The browser as a whole is perhaps the most battle tested sandbox system in the entire software industry. It’s been built on 3 decades of learning from hostile content, hostile code, and hostile users. Native and cloud agents are necessarily rebuilding all or most of this posture from scratch. peerd doesn’t. It leverages everything the browser has to offer and pushes it to its functional limits, while inheriting its security baseline and isolation from the host system.

Robust sandboxing isn’t the only thing the browser offers and peerd uses. It comes with extremely powerful and underrated primitives, from webCrypto, webRTC, webAuthn, webGPU, and ~soon WebNN. Direct web access, with your real live sessions, and api calls with fetch present an alternative model to MCP integrations. The agent can write and spawn web apps right there in a tab, no hosted service necessary. Then there’s the A2A piece: peerd already has a rudimentary p2p (peerd-to-peerd?) network in place using webRTC. Today you can connect with peers on the network, add them as contacts, and share signed apps you’ve created. I’m working on extending these apps to be able to leverage the same p2p network to support decentralized web apps (dwapps), as well as facilitate true p2p A2A with no platform or middlemen.

Given this is an early part time project, this is an extremely experimental build and in a v0.x preview state. I’ve taken care to attempt to address the lethal trifecta: the main agent loops/sessions never ingest untrusted DOM code or possess low level navigation tools. It delegates those tasks to dedicated web runners with no wider tooling or secrets access that return summarized results. Both the DOM and the summarized results are bracketed as untrusted, meaning two stacked prompt injection escapes are needed. All egress goes through a central module that has a customizable deny list, and only models calls to designated allowed endpoints are possible. See more in the docs, site, and the code itself. Ultimately, use at your own risk.

Today anthropic, open router, local ollama, and even an experimental WebGPU instance of Gemma are supported.

Honest limitations: Chrome store and AMO are still pending until it can get more eyeballs and live usage. Just loading unpacked from GitHub is the easiest way to go, and as a bonus makes it easy to audit thanks to no build. Linux on wasm depends on the Cheerpx engine, which is not open source and has restrictions for commercial use. That may be a good reason to reassess it compared to alternatives, but it’s also the most performant and looks closest to implementing 64bit support.

Poke around, use it, critique it, and have fun.

Did you read the article? It’s all about the currency problems and disparate exchange rates that have resulted in the country for the last 20+ years and has nothing to do with the president who’s been there for hardly 2 months. One of his first acts actually tackled that problem by slashing the artificial government exchange rate so that it’s much closer to the true black market rate.

Can I ask who this high-risk processor is?

This may indeed be a valid use case, and Bitcoin fulfills it. You don’t need to build a separate blockchain, you just need to know how to embed a hash into a Bitcoin block and how to point to it which is technically easy.

Also it’s unclear how a separate blockchain with this sole function would work. You need the monetary incentive of bitcoin mining and proof of work to make the security model work so that the time stamp can be trusted. The security of the Bitcoin blockchain is not a computer science problem, it’s an economic one. That’s why the only application it works with is cryptocurrency, with time stamping being a nice byproduct.

My phone slipped out of my pocket on the subway on my last night in Tokyo. Realized 20 minutes later, talked to some employees and described what kind of phone it was (a cheap Samsung, really not a big deal), gone as can be. Flew back home to Miami.

Received my phone back in the mail a month later. A friend of mine there kept checking with the employees and it eventually showed up in lost and found. Refused to allow me to pay for the international shipping.

Have a short list of worthy follows to start breaking into it?

"If you rent a server (real or virtual), whose software load you have control over, that's not SaaSS. In SaaSS, someone else decides what software runs on the server and therefore controls the computing it does for you. In the case where you install the software on the server, you control what computing it does for you. Thus, the rented server is virtually your computer. For this issue, it counts as yours."

I'm most curious about applying this distinction to the computing environment today. According to the author it seems Amazon EC2 wouldn't be considered a SaaSS, but Amazon Serverless would? After all you don't control the software loaded in a "serverless" environment, only the business logic. Yet both are hosted in and maintained by Amazon. Amazon, for all intents and purposes, has access to the data coming in and out of there in both cases. So does the distinction hold true, and if it does does it not damage the value of making such a distinction?

I'm a dev and I have no idea what weblogs have to do with this discussion. Quick search didn't do anything to clue me in either.