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.
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.
- 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.
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.
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.
"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?