During recent discussions about the security of decentralized inference through @routstr people raised a valid concern: how can we be sure a provider doesn't read our prompts, or alter tool calls to backdoor the machine or the code it generates? Or how do we know the provider does not swap the model for a cheaper one and charge you full price? The usual answer is a TEE, a trusted execution environment. TEEs are hard to audit in practice. You trust the hardware vendor and re-verify a whole software stack after every update. We can do better, and now we do. Routstr has a confidential mode. Your client talks TLS 1.3 directly to the upstream provider (Venice, for my node), and the Routstr node in between only relays encrypted records. Client and node compute the TLS keys together, so the node can add its API key without ever seeing your prompt or the answer, and it can't change a single byte of the response, tool calls included. Zero-knowledge proofs pin the model and the token cap, and you pay for the usage the provider itself reported. All of this rests on math and on the certificates you already trust, with no enclave or special hardware anywhere. It works today on routstr.cypherpunk.today, through routstrd (I'm running opencode agents on it) and right in the browser, where the page does every check itself. It's new and experimental, so please try it and tell me what breaks. Blog:

Confidential inference on Routstr without trusted hardware – Juraj Bednar

Try it in the browser:

Confidential Chat

Paper:

GitHub

routstr-confidential/paper/paper.pdf at 904635390155252b3fe4ce1b8832acef55a8e1e6 · jooray/routstr-confidential

Confidential and verifiable upstream inference for Routstr: the node relays TLS and never sees prompts; ZK-proven credential record, model pinning ...

Code:

GitHub

GitHub - jooray/routstr-confidential: Confidential and verifiable upstream inference for Routstr: the node relays TLS and never sees prompts; ZK-proven credential record, model pinning and usage-based billing

Confidential and verifiable upstream inference for Routstr: the node relays TLS and never sees prompts; ZK-proven credential record, model pinning ...

True. And I am not telling you where 2026 happening!

Hackni sa! je teraz aj audiokniha: 14 hodín a 25 minút, 47 kapitol, m4b aj mp3. Podnikanie, sloboda, biohacking, kryptomeny a pár vecí, ktoré som sa za tie roky naučil o tom, ako sa pozerať na svet inak. Text je trochu aktualizovaný oproti tlačenej knihe. Do konca októbra za 19,99 € namiesto 24,99 €:

Kniha Hackni sa! – Juraj Bednar

Re: Ledger supply chain attack. A friend @bitpunk.fm is typing was talking about exactly this supply chain attack 8 years ago at CCC: They downplayed him that he was "too James Bond". Well, the bounty increased and apparently "too James Bond" is an economical thing to do. The seller of the company got lots of shit for selling the company, but I think this is wrong. It is Ledger's job to verify the supply chain (and keep things like notification of ownership change in the contract). It's not the previous owners' job. The contract is with the supplier, not with the owners. Personal storytime: There’s nothing wrong with selling a company - sure, you are selling the users, but nothing in the world forces you to own a company forever. Many entrepreneurs are building a "bankable business" (something you can sell - in contrast with "lifestyle business" - which pays the bills). And what happens to the company afterward really isn’t their problem anymore. When I was selling my company, a friend did this nice little exercise with me. We were really stressing about who would buy it and whether it would be cool. He talked about valuation — there’s some research where you have an IKEA cup worth $2 and you’re asked whether you’d buy it. If they gave that cup to someone for a month and then had them sell it, they valued it higher (something like $4, I don’t remember the exact numbers), because it was no longer just a “random IKEA cup” — they had to part with *their* cup. He explained to us that what we are doing is a rational transaction: we don’t want the company anymore, we want money instead, so we sell it, and then it’s not ours. What the new owner does with it has absolutely nothing to do with us. Whether the employees and customers stay happy is their problem, and we bear zero responsibility for whatever happens to the company afterward. The "due diligence" goes usually one way - the buyer wants to know about the company they are buying. The only thing you want to know about the seller is if they'll pay agreed amount. So that reseller — in my view, basically didn’t do anything wrong. Ledger should have had this covered in the contract and properly vetted those suppliers, continuously. Ledger had a contract with a legal entity and didn’t bother checking at all whether they were up to no good. I don't think it is possible to check the supply chain well though. Anyway, Josh was right again. Listen to bitpunk.fm and you'll realise he's very often right.

Trying to build something cool with zero knowledge proofs. Kimi and DeepSeek are grinding now. (Image by @redshift)

Experimental ArtCraft fork that does not need ArtCraft cloud accounts and uses @AskVenice models. Done entirely by DeepSeek V4.1 Flash, no "frontier" models used in this. Doesn't do the 3D parts, because Venice does not offer 3D models yet. Price estimation, models, etc. should work. Keep the pull requests coming.

GitHub

GitHub - jooray/artcraft: ArtCraft is an intentional crafting engine for artists, designers, and filmmakers

ArtCraft is an intentional crafting engine for artists, designers, and filmmakers - jooray/artcraft

Toto je brutál! ♨️♨️♨️ View quoted note →

Democracy in one picture

Someone asked whether I use Jev. Yes — in five places already. Jev is a decision model, not a chat model. You give it a situation and a set of typed questions (yes/no, multiple choice, ...), and it returns calibrated probabilities instead of generated text. Sub-second responses, input-token-only pricing, and it cannot answer outside the options you define. Where you'd otherwise ask an LLM for one JSON field and throw the rest away, this is the thing to call. Where I use it: 1. Security for my AI agent. Hermes reads untrusted pages and emails, so any of that text could carry planted instructions. The hermes-firewall plugin extracts everything the model would see (invisible Unicode, hidden HTML, OCR of images, base64) and asks Jev two questions: is there a command here unrelated to the content, and is it aimed at an AI? On a 718-item benchmark it caught 89% of attacks at 3.5% false positives, ahead of DeBERTa, a 421M local classifier and a 4B instruction model. About $0.035 per thousand scans.

A prompt-injection gate for my AI agent: what worked, what didn’t, and the benchmark – Juraj Bednar

2. Marketing automation. Lievik watches my content sources and rates every post against each audience (newsletter, Signal group, students) from 0 to 100 for relevance, so I know what to send whom and what they've already seen.

Lievik - The right thing, for the right people

Lievik helps Nostr creators send the right thing to the right audience.

3. Nostr feed ranking. Nalgorithm scores posts from my follows against a profile of what I actually care about, instead of serving reverse-chronological order. A 602-post feed scores in 21 seconds instead of ~5 minutes, with 271 distinct scores instead of 11, and a rerun keeps the same order.

nalgorithm: hear what mattered on Nostr

Your Nostr feed ranked by what you say you care about, and read to you as a spoken digest each morning. Every score shows its reason. Open source.

4. Event networking. Nostrautica connects attendees with people they should meet. On a real 39-person roster the old scorer gave 19 of them a tied first place; Jev gave nobody a tie and reproduced the order across runs.

Nostrautica

Nostrautica: chart a course to the people worth meeting

Nostrautica pairs AI matchmaking with a real, portable Nostr identity, so every attendee knows who to meet, and why. For a normal conference with l...

5. Signal group summaries. signal-summarizer turns a busy Signal group into a themed digest: it reads the text, transcribes voice notes, has a vision model describe the images and summarizes the links, then files all of it into topics. Jev handles the part that's easy to get wrong — deciding whether two themes are actually the same topic, and routing a message into the right one. On a labelled fixture it separated real merges from near-misses with AUC 1.00, ahead of plain embedding similarity, and it matched strong LLM judges on routing.

GitHub

GitHub - jooray/signal-summarizer: AI summaries of Signal group content - text, images, links, voices. Runnable locally through ollama.

AI summaries of Signal group content - text, images, links, voices. Runnable locally through ollama. - jooray/signal-summarizer

In all of these Jev is just one option. Each project can swap in another decision model (there are open ones you can run locally in Ollama, no cloud needed) or a plain LLM, whichever fits the job. We now have a magic wand. I was able to implement Jev in all these projects almost immediately after the model went out, including the benchmarks. This would have taken weeks without AI for coding.

I benchmarked Liquid AI's new open decision models, d1-3B and d1-omni-600M, as local prompt-injection gates for my Hermes agent, along with Decision-2.0-Lux-9B in MLX. d1-3B is quick on my M2 Max (0.3 s a message, against about 2 s for Nimble) and separates attacks from benign text well within each kind of content, with the best image score of anything I've tested. But its scores don't line up across content types: half of the emails with a planted instruction score lower than some ordinary Nostr posts, so with one threshold it blocks only 29 of 150 of those emails. Lux has a different problem: it treats articles about prompt injection as prompt injection. d1-omni-600M is too weak to use. My recommendation hasn't changed: use Jev on Venice if you can (it blocks 88% of attacks and 92% of planted email instructions), and Nimble 9B 4-bit in Ollama if everything has to stay local. I also tried giving d1 the image itself instead of OCR text, and OCR won (40 against 28 of 48 image attacks blocked), so the OCR step stays. Numbers and charts:

A prompt-injection gate for my AI agent: what worked, what didn’t, and the benchmark – Juraj Bednar

Plugin and benchmark:

GitHub

GitHub - jooray/hermes-firewall: Prompt-injection gate for Hermes Agent: scans web, MCP, email and image content before the model sees it. Plugin + benchmark.

Prompt-injection gate for Hermes Agent: scans web, MCP, email and image content before the model sees it. Plugin + benchmark. - jooray/hermes-firewall

I was saying @PayPerQ is more expensive than @routstr in many cases. But what is underappreciated is that PPQ supports much more than text inference, and Routstr is not there yet. Image generation, video, ... There are some sparks on Routstr, but the model catalog of PPQ is impressive. Again - no accounts model, no KYC is the way to go.

If you are not using ZapStore on Android, you are missing out. Many developers including myself just value their time and sanity so much that we can't be bothered by Google and Apple bullshit. That means, you don't get our apps if you don't ZapStore (or Obtainium, but honestly, ZapStore has way better ux). And the apps are usually free. Here are mine, and much more to come:

Zapstore

Juraj🏴💛🌘 — Profile — Zapstore

I don’t seek rigid structure — I seek resonance Vibe coding, reality bending, cypherpunk visions. Author of Tamers of Entropy: https://tamers...

Achievement unlocked: I got scammed in Austria. Used to be high trust society. Now just enjoying the decline... Thankfully only 23€

The cheapest per-token inference... If you've looked at @routstr and want cheap AI inference paid in sats (without e-mail address and without KYC) but don't want to manually pick and babysit nodes, run routstrd locally. First the prices. I am monitoring prices and for most models, you can get somewhere between 53% and 66% of @PayPerQ (also pay per query) price on Routstr. Yep, between half and two-thirds. Some models, such as Kimi K3 are often 36%. And PPQ is around 5% more expensive than OpenRouter. I do not know of a cheaper way to get per-token API inference right now (besides subscriptions, they are a different beast). Back to routstrd. It's a small daemon, not a node itself, that sits on your machine and exposes a normal OpenAI-compatible API on localhost:8008. Point your apps at it and it handles the rest. Under the hood it finds nodes by reading provider announcements off Nostr relays, verifying them and refreshing the list every 21 minutes, and it only trusts nodes that have a positive review from the Routstr team — anything unreviewed is disabled by default. For whatever model you're calling, it compares prices across all known nodes and routes to the cheapest one, and if a request fails it automatically fails over to the next cheapest instead of just erroring out. On payments, it defaults to a mode where it quietly exchanges a Cashu token for each node's own API key, holds onto it, and tops it up as the balance runs low — so it genuinely manages real provider API keys for you behind the scenes. You fund it with Lightning or a Cashu token, and your apps never touch the e-cash directly, they just get a local key from the daemon. Worth trying, just keep the wallet funded with small amounts you're comfortable topping up regularly rather than loading it with a lot of sats at once. Basic commands to get going: bun i -g routstrd routstrd onboard routstrd receive <cashu-token> # fund with a Cashu token routstrd receive 2100 # or top up 2100 sats via Lightning routstrd start # starts the daemon on localhost:8008 routstrd clients add --claude-code # or --pi-agent / --opencode routstrd status routstrd balance P.S.: I run price monitoring of Routstr nodes and I only count nodes that respond to API requests with completion - so these prices are representative of real prices that you can get, not only advertised prices.

AI corporations borrowing like there's no tomorrow and subsidizing tokens (although I'm not really sure if it's a true subsidy or the API is just overpriced). It can pay off for them, but they need to lock you in. And they're trying. Anthropic wants you to use their harness (Claude Code) - and it is really good. OpenAI now launching Dots. The idea is vendor lock in. I don't have a grand scheme for how this is going to end, but my personal strategy - never lock in. Use OpenCode, hermes-agent, be as model promiscuous as you can. Use the best frontier models, use the cheap flash models, milk most value for the buck, but change providers often and never accept lock in. They think they're building network effects, but you make them burn cash and provide insane value to you. Be the winner.

Can a local model replace a cloud Jev as a prompt-injection gate for my AI agent? I benchmarked the new decision models in Ollama 0.35 on 718 test items. Nimble 9B came closest: it caught 81% of attacks (Jev on Venice: 89%) and it's the best local model I've tested. But it blocks only 63% of instructions planted in ordinary emails, against Jev's 92%. I'm keeping Jev for now. If you want nothing to leave your machine, Nimble is now one config line in the hermes-firewall plugin (~11 GB RAM).

A prompt-injection gate for my AI agent: what worked, what didn&#8217;t, and the benchmark &#8211; Juraj Bednar

A prompt-injection gate for my AI agent: what worked, what didn’t, and the benchmark

A prompt-injection gate for my AI agent: what worked, what didn&#8217;t, and the benchmark &#8211; Juraj Bednar

Repo:

GitHub

GitHub - jooray/hermes-firewall: Prompt-injection gate for Hermes Agent: scans web, MCP, email and image content before the model sees it. Plugin + benchmark.

Prompt-injection gate for Hermes Agent: scans web, MCP, email and image content before the model sees it. Plugin + benchmark. - jooray/hermes-firewall

OK, this is beautiful: "I built a patcher (tools/patch_libapp.py) that edits libapp so inside the installed split APK at identical size — no reinstall, no re-signing, no re-login — and rewrites both zip CRCs so the archive still verifies. Deploying is a single adb push. I confirmed each patch is live by reading /proc/<pid>/mem."