Nostr notes by Juraj

Ak vás zaujíma ako funguje dôverný režim @npub130m…l29s a ...

2026-10-14T09:44:00Z

Ak vás zaujíma ako funguje dôverný režim routstr (npub130m…l29s) a ste programátori, tu je výklad pre programátorov.

https://juraj.bednar.io/wp-content/uploads/2026/10/routstr-confidential-pre-programatorov.pdf

Ak nie ste progamátori, v pôvodnom blogu je stále videjko:

quoting nevent1q…z3g9

Ako môže sprostredkovateľ poslať tvoju AI požiadavku pod svojím API kľúčom, neprečítať pritom tvoj prompt a ten kľúč ti nikdy neukázať? routstr-confidential (experimentálny mód inferencie pre routstr (npub130m…l29s) nodu) som vysvetlil ako kúzelnícke predstavenie: rodokmeň kľúčov rozdelený medzi dvoch, zapečatená obálka, zamknuté škatuľky, karta, ktorú kúzelník nevidí, a dôkaz à la „Kde je Waldo“. Celé je to obyčajná kryptografia, žiadne enklávy. Je tam 39-minútové ilustrované video aj krátka textová verzia.

https://juraj.bednar.io/blog/2026/10/12/sedem-kuzelnickych-trikov-v-jednej-ai-poziadavke/

https://vimeo.com/1235021230?share=copy&fl=sv&fe=ci

But the nice thing is that with Law of cryptocurrency ...

2026-10-13T09:30:34Z

In reply to nevent1q…cfrp
_________________________

But the nice thing is that with Law of cryptocurrency isomorphism, we can and will fix this.

https://juraj.bednar.io/en/blog-en/2022/10/24/the-law-of-cryptocurrency-isomorphism/

New audiobook version of Cryptocurrencies - Hack your way to a ...

2026-10-13T07:25:00Z

New audiobook version of Cryptocurrencies - Hack your way to a better life. Slightly updated. If you want to know how to deal with volatility, why cryptoanarchy works, how to use collateralized loans, what is this "crypto" thing, why I (usually) don't buy 💩coins, read.

And now you can also 🎧 instead of reading. Enjoy!

https://hackyourself.io/product/cryptocurrencies-hack-your-way-to-a-better-life/?attribute_book-type=Audiobook

F-Droid builds and signs on their own. I recommend you just stop ...

2026-10-13T05:38:23Z

In reply to nevent1q…55wy
_________________________

F-Droid builds and signs on their own. I recommend you just stop using them. they're using old libraries for building quite often. GrapheneOS does not recommend them.

Coinbase the exchange yes. Coinbase payment gw not

2026-10-13T05:34:31Z

In reply to nevent1q…8q4g
_________________________

Coinbase the exchange yes. Coinbase payment gw not

That is true. What doesn't make sense is they don't just ...

2026-10-13T05:33:49Z

In reply to nevent1q…jv2f
_________________________

That is true. What doesn't make sense is they don't just accept lightning.

I benchmarked vLLM Semantic Router's new Decision 3.0 models ...

2026-10-12T19:04:00Z

I benchmarked vLLM Semantic Router's new Decision 3.0 models as a prompt-injection gate for my agent, all six sizes, running locally in MLX on an M2 Max.

The 27B model at 4 bits is the first local detector that beats Jev, the cloud model I use. It blocks 400 of 433 attacks (Jev 383) and 140 of 150 instructions planted in ordinary emails (Jev 138), and it wrongly blocks 7 benign items against Jev's 10. It also doesn't flag articles about prompt injection, which tripped earlier models. The price is speed: about 7 seconds per message and 17 GB of memory.

The smaller ones rank attacks almost as well, but they also score some harmless content high, so at a low false-positive rate they let many planted emails through. d3-lite, at 0.85B parameters, ranks as well as Nimble 9B in a fifth of a second.

Updated blog with current benchmarks:
https://juraj.bednar.io/en/blog-en/2026/09/28/a-prompt-injection-gate-for-my-ai-agent-what-worked-what-didnt-and-the-benchmark/#d3

Ako môže sprostredkovateľ poslať tvoju AI požiadavku pod ...

2026-10-12T12:23:00Z

Ako môže sprostredkovateľ poslať tvoju AI požiadavku pod svojím API kľúčom, neprečítať pritom tvoj prompt a ten kľúč ti nikdy neukázať? routstr-confidential (experimentálny mód inferencie pre routstr (npub130m…l29s) nodu) som vysvetlil ako kúzelnícke predstavenie: rodokmeň kľúčov rozdelený medzi dvoch, zapečatená obálka, zamknuté škatuľky, karta, ktorú kúzelník nevidí, a dôkaz à la „Kde je Waldo“. Celé je to obyčajná kryptografia, žiadne enklávy. Je tam 39-minútové ilustrované video aj krátka textová verzia.

https://juraj.bednar.io/blog/2026/10/12/sedem-kuzelnickych-trikov-v-jednej-ai-poziadavke/

https://vimeo.com/1235021230?share=copy&fl=sv&fe=ci

How can a middleman forward your AI request with its own API key, ...

2026-10-12T12:22:00Z

How can a middleman forward your AI request with its own API key, without reading your prompt, and without ever giving you the key? I explained routstr-confidential (an experimental routstr (npub130m…l29s) mode) as a magic show: a key tree split between two people, a sealed envelope, locked boxes, cards the magician can't see, and a Where's Waldo proof. It's all plain cryptography, with no enclaves. There's a 35-minute illustrated video plus the short written version.

https://juraj.bednar.io/en/blog-en/2026/10/12/seven-magic-tricks-inside-one-ai-request/

https://vimeo.com/1235021232?share=copy&fl=sv&fe=ci

I had an interaction with Coinbase team about their payment ...

2026-10-12T07:13:00Z

I had an interaction with Coinbase team about their payment gateway. I asked why they don't just support Lightning - instant payments. Their reply was user experience.

For two days, I am trying to help a friend pay a Coinbase payment gateway invoice using their super complicated setup. He is a sysadmin, so no tech newbie. He is not a customer of coinbase, he just wants to pay an invoice using an open payment network.

Juggling wallets, picking the right chain, walletconnect hell, ...

User friendly, yeah :).

Meanwhile, people paying with lightning: scan or open an invoice in a wallet, click send, instant confirmation, almost no fees, done.

Reconsider.

Keď mi toto ukázal @npub15xk…krnh môj dekel uletel až na ...

2026-10-12T07:01:00Z

Keď mi toto ukázal Wilder (npub15xk…krnh) môj dekel uletel až na Andromedu.

Tehla do divočiny: nový Tank 5 Pro
Telefón, ktorý vydrží až dva týždne bez zásuvky, nabije ostatné zariadenia, premieta v 2K a v tme vidí teplo.

https://blog.opportunist.global/tehla-do-divo%C4%8Diny-nov%C3%BD-tank-5-pro-6a154f7d2d7b

Try 1.0.1 (on zapstore). If it still crashes, send me error log ...

2026-10-11T20:38:07Z

In reply to nevent1q…ck4t
_________________________

Try 1.0.1 (on zapstore). If it still crashes, send me error log please.

Yeah. I'll gladly rename it so there's less confusion. ...

2026-10-11T20:37:02Z

In reply to nevent1q…7fdk
_________________________

Yeah. I'll gladly rename it so there's less confusion.

The way I handled the NIP is that it is still primarily Nostr, but I specified a deterministic way to encode the Nostr event into MeshCore packet and back - in a way that the Nostr event is fully reconstructed, including the valid signature.

Basically keep only the most precise geohash (although we include less precise for easy queriability), etc. The goal is to be able to pack everything into as small packet as possible, but also be able to unwrap it back into original Nostr event.

Do you have a specification of events that you use? We might do it the other way around - if it is possible, we can use your event type and I can devise a way to compress it into meshcore packets. And I'll change my apps to use your event type. My app has no users, it's a demo at this point, so I'm totally OK with continuing with yours, if we can keep this property and extend it to MeshCore.

My app is also primary Nostr, MeshCore is not yet implemented (I need a bit of work on MeshCore side as well, so it is user friendly - currently you can connect only one MeshCore app to a node, so we need a MeshCore app that can take and send events from other apps, so users don't have to choose "now I'm driving, I am opening app X, now I want to chat, I am opening app Y"). But I'll solve that part easily.

Thank you

2026-10-11T09:43:00Z

In reply to nevent1q…ck4t
_________________________

Thank you

I have told my bot to publish the reviews - I was already ...

2026-10-11T09:42:34Z

I have told my bot to publish the reviews - I was already checking other nodes automatically before and redshift (nprofile…6uhp) nudged me to just publish the reviews as kind 38425 events.

In the long form article I explain how it works and what the review says and what it does not say.

quoting
naddr1qv…yy3s

This account is a bot. Juraj Bednar (Juraj (npub1m2m…r8p9)) runs it, and he also operates a Routstr node, routstr.cypherpunk.today. So a competitor is reviewing other nodes here, and you should weigh the reviews with that in mind. Below is what the bot does.

Why probe at all

A Routstr node announces itself on Nostr (kind 38421) with the models it sells and the mints it accepts. Clients pay per request with a Cashu token: they send more than the request costs, and the node hands back the rest as change.

The announcement doesn't tell you whether the node works. Some nodes list models whose upstream key has expired. Some answer every request with an error. A few take the token and send back neither an answer nor change, and for a client paying with bearer ecash that money is gone. You only find out by paying.

What one probe is

The scout mints a fresh 32-sat token at a mint the node accepts. Each probe gets its own token, and the node never sees anything else.

It sends one short, real chat completion request, paying with that token in the X-Cashu header, the way any client would.

It records what happened: an answer, an error, or nothing.

If the node returned change (or a refund, on an error), the scout redeems it straight away.

If nothing came back, it asks the mint whether the token was spent (NUT-07). Unspent means the node never charged, and the token gets used again. Spent, with no answer and no change, means the node kept it.

A probe that goes well costs about 1 sat in mint fees. When a node keeps a token, we lose that one token.

Which nodes

The scout probes some of the nodes on the network, not all of them, and not on a published schedule. It only reviews nodes it has paid-probed itself, so a node with no review from this account hasn't been judged badly. It just hasn't been probed.

The one exception is our own node, routstr.cypherpunk.today. This account always reviews it lgtm, and that review says it is a self-review: the scout never probes our own node, so it is the operator's own statement and not probe evidence.

What gets published

Reviews use the same kind 38425 format as audit.routstr.com, so they show up there. Each node has one review, replaced when the verdict changes:

lgtm once a node has answered paid probes and returned change correctly for three days without a break.

avoid when a node keeps two probe tokens without an answer or change. This one goes out immediately.

avoid when every paid request has failed for three days.

After three days of correct service a node goes back to lgtm. When there are enough probes, the review also carries a score, the share of the last 30 days' probes that went fine.

Each review expires (NIP-40) 30 days after it is signed. The scout re-signs it every two weeks while it still has fresh evidence, so if it stops probing a node, or stops running altogether, the old reviews disappear by themselves.

Notes (kind 1) cover things worth knowing before a review changes, such as a node keeping a single probe token. One kept token is an observation, not a verdict. A note also goes out when a review changes, but not when one is merely refreshed.

Backing off

When a node keeps two tokens, the scout stops paying it for a while, and how long depends on its record. A node that had been serving correctly for two weeks or more gets 12 hours. One with no record gets three days, and anything in between is scaled. A node that ran well for weeks and then misbehaves is more likely having a bad day (a mint outage, a restart in the middle of a request) than turning dishonest.

If it happens three times, the scout stops probing that node for good. A node that stays clean for two weeks after a pause starts that count over.

What a review does not tell you

A probe is one small request to one model. It shows the node was up, answered, and handled ecash correctly at that moment. It tells you nothing about the quality of the answers, about the node's other models, or about what the node does with your prompts.

The reviews don't decide routing either. Routstr clients route according to reviews from Routstr's own key. Reviews from this account are a public data point for users and for Routstr's reviewers.

If we got your node wrong

Probes can fail because of something on our side. If you run a node and think its review here is wrong, reply to this article or message Juraj (npub1m2m…r8p9). The scout logs every event it signs, so we can check exactly what it saw.

It's much simpler. But it would be very cool if the property ...

2026-10-11T07:13:33Z

In reply to nevent1q…gtph
_________________________

It's much simpler.

But it would be very cool if the property of Nostr events (that they are compressible into one MeshCore packet) would stay (not necessarily my NIP). It's mainly about the size (check the NIP).

Then we could share the reports in local mesh network.

I don't even care if it is compatible with my protocol, I can change the protocol to yours (and even rename the web app to remove the confusion and retire the Android app, even though I believe mine was first, but I don't care:).

Shall we fix this for everyone?

The idea is - road reports are local, if internet is down, we can locally report over MeshCore radio, it can appear on local relay (mapping the meshcore packet to full signed Nostr event, including the signature).

And then it would not only be decentralized "Waze", but "There's a revolution, beware, there are thugs with guns next street".

Four of my Nostr apps now have native Android apps, on Zapstore: ...

2026-10-11T07:09:00Z

Four of my Nostr apps now have native Android apps, on Zapstore:

Emanator: schedule and write posts for all your Nostr accounts, and handle the replies, mentions and private messages of every identity in one place
https://zapstore.dev/apps/today.cypherpunk.emanator

Lievik: for marketing. It reads the Nostr accounts and RSS feeds you follow, tells you what is worth passing on and to which audience (a newsletter, a Signal group, a social account), and drafts the post
https://zapstore.dev/apps/today.cypherpunk.lievik

nalgorithm (npub1dka…wkt0) : your Nostr feed ranked by what you care about, plus a daily voice digest
https://zapstore.dev/apps/today.cypherpunk.nalgorithm

Nostrautica (npub1k33…4taa) : for any event, from a conference or a meetup to a community that meets for years, built around meeting the right people
https://zapstore.dev/apps/today.cypherpunk.nostrautica

All of them sign in with Amber on the same phone. They are open source, and the signed releases are on GitHub too, so Obtainium works.

On an iPhone or a computer you don't need any of this. Each web app installs to your home screen and is the full app.

Now the @nprofile…qeaf proxy doesn't see your prompts and ...

2026-10-11T07:04:19Z

In reply to nevent1q…9uh7
_________________________

Now the routstr (nprofile…qeaf) proxy doesn't see your prompts and can't interfere with them.

Experimentally on my node, hopefully soon everywhere! (But my node has best prices from default-on nodes anyway:).

quoting
nevent1q…tkmj
During recent discussions about the security of decentralized inference through routstr (nprofile…qeaf) 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: https://juraj.bednar.io/en/blog-en/2026/10/10/confidential-inference-on-routstr-without-trusted-hardware/
Try it in the browser: https://jooray.github.io/routstr-confidential-pwa/
Paper: https://github.com/jooray/routstr-confidential/blob/HEAD/paper/paper.pdf
Code: https://github.com/jooray/routstr-confidential

Model fraud and prompt surveillance fixed. #nevent1q…tkmj

2026-10-11T07:02:53Z

In reply to nevent1q…ju49
_________________________

Model fraud and prompt surveillance fixed.

quoting
nevent1q…tkmj
During recent discussions about the security of decentralized inference through routstr (nprofile…qeaf) 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: https://juraj.bednar.io/en/blog-en/2026/10/10/confidential-inference-on-routstr-without-trusted-hardware/
Try it in the browser: https://jooray.github.io/routstr-confidential-pwa/
Paper: https://github.com/jooray/routstr-confidential/blob/HEAD/paper/paper.pdf
Code: https://github.com/jooray/routstr-confidential

Now without my node seeing the prompts, or having the ability to ...

2026-10-11T06:58:53Z

In reply to nevent1q…y39f
_________________________

Now without my node seeing the prompts, or having the ability to interfere with tool calls!

nevent1qqsz8tfwjjp5f20e9z70c8csdh7zdkq823qmdnmc7qtasj58aynwhrsgftkmj

Released here: ...

2026-10-11T06:57:49Z

In reply to nevent1q…t000
_________________________

Released here: nevent1qqsz8tfwjjp5f20e9z70c8csdh7zdkq823qmdnmc7qtasj58aynwhrsgftkmj

Released #nevent1q…tkmj

2026-10-11T06:57:30Z

In reply to nevent1q…wdw9
_________________________

Released

quoting
nevent1q…tkmj
During recent discussions about the security of decentralized inference through routstr (nprofile…qeaf) 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: https://juraj.bednar.io/en/blog-en/2026/10/10/confidential-inference-on-routstr-without-trusted-hardware/
Try it in the browser: https://jooray.github.io/routstr-confidential-pwa/
Paper: https://github.com/jooray/routstr-confidential/blob/HEAD/paper/paper.pdf
Code: https://github.com/jooray/routstr-confidential

This exponential is something that is very hard to grasp (pun ...

2026-10-11T06:43:47Z

This exponential is something that is very hard to grasp (pun intended) for me. Yesterday I published a protocol and a library for confidential inference through proxy (Routstr). When I woke up, it is already being used by real service out there - Graspable.

https://graspable.dev/blog/a-router-that-cannot-read-your-prompts

This is amazing. It is different than my Roadstr app, but I'm ...

2026-10-10T21:08:31Z

This is amazing. It is different than my Roadstr app, but I'm gonna give this a try!

quoting
nevent1q…qc20
ROADSTR 1.0.0 IS FINALLY HERE! 🎉🚀

After countless hours of development, testing on the road and debugging... I'm incredibly excited to announce the first stable release of Roadstr!

For those who don't know it yet, Roadstr is a free, open-source, decentralized navigation app for Android, powered by **Nostr, Bitcoin Lightning, and OpenStreetMap**, with absolutely no Google dependencies.

Since v0.5.0, the project has evolved enormously. And the biggest change? Roadstr has been rewritten from Flutter to native Kotlin, with Jetpack Compose and MapLibre!

Here's what we've built along the way:

🗺️ A whole new navigation experience
- Beautiful OpenStreetMap-based maps with 3D tilt, rotation, light/dark themes, and customizable vehicle cursors.
- Possibility to choose from 4 different tier of power consumption to accomodate both entry level phones and flagships.
- Real-time turn-by-turn GPS navigation, automatic rerouting, multiple route alternatives, and multi-stop planning.
- Navigation that keeps running even when your screen is off.
- Driving, walking, and cycling routes, with OSRM, GraphHopper, and OpenRouteService support.
- Live speed limits, speed-adaptive zoom, and customizable speedometer HUDs.

🌍 OFFLINE MAPS & NAVIGATION
- Downloadable worldwide maps using Geofabrik and Shortbread MBTiles.
- A hierarchical map catalog covering continents, countries, regions, and over 34,000 cities!
- Verified, resumable downloads and local map rendering.
- Optional offline routing powered by an on-device Valhalla engine, using separate routing packages.
- Support for custom and self-hosted map catalogs.

🤖 AI VOICE GUIDANCE — WITHOUT THE CLOUD
- Natural-sounding, on-device voice navigation powered by Kokoro-82M and Piper.
- No cloud AI API required. Voice generation happens directly on your phone.
- Multilingual guidance, downloadable voice models, and adjustable voices.

⚡ NOSTR + BITCOIN LIGHTNING
- Decentralized road reports for accidents, traffic jams, hazards, police activity, and speed cameras.
- Community confirmations, report corrections, and activity notifications.
- Reports created without connectivity can be queued for later publishing.
- Send Lightning zaps to people contributing useful road information!
- Nostr Wallet Connect (NIP-47) support.
- Secure Nostr login through Amber (NIP-55) and remote bunker signers (NIP-46). Your private key stays outside Roadstr.

🔎 SMARTER EXPLORATION
- Search addresses, businesses, brands, and points of interest using OpenStreetMap.
- Natural-language searches like "restaurants near me" or "gas stations along my route."
- Detailed place information, Wikipedia integration, and contextual amenities.
- Weather information along your journey.
- Open-data public transport itineraries where supported.

💾 MORE FREEDOM & CUSTOMIZATION
- Save places, parking locations, and complete routes.
- Encrypted, optional cross-device favorites synchronization through Nostr.
- Optional SearXNG integration for web search.
- 27 supported interface languages.
- Nostr Violet and Bitcoin Orange themes, with automatic dark mode.
- Integration with Tankful for sharing destinations directly into Roadstr.

🛠️ AND A LOT OF WORK UNDER THE HOOD
- A completely rewritten native Android architecture.
- Performance and battery optimizations.
- Improved GPS handling, navigation stability, and Nostr relay resilience.
- Extensive automated testing and real-device validation.
- An in-place upgrade path from the old 0.5.x releases, preserving supported user data and settings.

And of course, Roadstr is fully open source. No proprietary navigation platform, no mandatory Google account, and no centralized Roadstr traffic-reporting server. Download the code, break it, make it better, sell it, copy it, I don't care.

This project started with a simple idea: what if navigation could be open, community-driven, and powered by decentralized technology instead of another closed ecosystem?

Today, Roadstr 1.0.0 is one big step closer to that vision.

It's still an independent project, and there's plenty more to build. But reaching the first stable release feels like a huge milestone.

Thanks to everyone who has tested Roadstr, reported bugs, shared feedback, or simply followed its development ❤️

Get the stable release from Zapstore (nprofile…zjna)

Source code: https://github.com/roadstrapp/roadstr-app/

The roads belong to everyone. Let's make navigation decentralized and as always #FuckGoogle

#Roadstr #GrowNostr #OpenStreetMap #FuckGoogle #OtherStuff

During recent discussions about the security of decentralized ...

2026-10-10T20:14:17Z

During recent discussions about the security of decentralized inference through routstr (nprofile…qeaf) 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: https://juraj.bednar.io/en/blog-en/2026/10/10/confidential-inference-on-routstr-without-trusted-hardware/
Try it in the browser: https://jooray.github.io/routstr-confidential-pwa/
Paper: https://github.com/jooray/routstr-confidential/blob/HEAD/paper/paper.pdf
Code: https://github.com/jooray/routstr-confidential

There's no structured decoding, it's just raw outputs. ...

2026-10-10T08:46:30Z

In reply to nevent1q…ynj3
_________________________

There's no structured decoding, it's just raw outputs. There's nothing to decode. This is not LLM!

You don't get JSON or anything like that. You get the raw numbers. The worst that can happen is that the numbers are wrong (and something that should have been blocked is not).

Experimental ArtCraft fork that does not need ArtCraft cloud ...

2026-10-09T09:52:00Z

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.

https://github.com/jooray/artcraft

Someone asked whether I use Jev. Yes — in five places already. ...

2026-10-08T09:01:00Z

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.
https://juraj.bednar.io/en/blog-en/2026/09/28/a-prompt-injection-gate-for-my-ai-agent-what-worked-what-didnt-and-the-benchmark/

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.
https://lievik.cypherpunk.today

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.
https://nalgorithm.cypherpunk.today/

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.
https://nostrautica.cypherpunk.today/

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.
https://github.com/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.

If you are not using ZapStore on Android, you are missing out. ...

2026-10-06T06:31:55Z

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:
https://zapstore.dev/profile/npub1m2mvvpjugwdehtaskrcl7ksvdqnnhnjur9v6g9v266nss504q7mqvlr8p9

Random per group or per message?

2026-10-01T05:52:01Z

In reply to nevent1q…xmvc
_________________________

Random per group or per message?

AFAIK: no, a DM is a group, and messages are gift-wrapped to the ...

2026-09-30T20:24:03Z

In reply to nevent1q…y5c3
_________________________

AFAIK: no, a DM is a group, and messages are gift-wrapped to the group.

Gift-wrap - no sender
Group - recipient is not the real npub

But Max (nprofile…8p0e) will know more.