If you have some spare tokens: - check security of your home network, of apps you use, custom dev software. Use models that don't complain - write documentation for your home setup and keep it up to date - plan and implement migration from various shitty cloud services. You're probably paying monthly for stuff that you don't need but it's difficult to migrate from. - setup self-sovereign stuff. Nostr VPN, nas, cloud photo storage, jellyfin, ollama, hermes agent, ... - do regular upgrades of everything

Idea: Before I install something, I often run a simple audit of the codebase to check for obvious backdoors and security problems. Would it be useful to publish these on Nostr with exact checkpoint ID and model name, so we can save on tokens? Sort of a "I run this prompt, it turned out OK". Agents can look at diffs, or if many trusted people have done the same with various models, the project could get some kind of badge.

How the game theory actually worked out: Punish shitcoiners mining bip110 fork chain so they lose all profit from the blocks and learn their lesson. How's your fork doin' guys? It will be collector's edition of "I got it wrong again", with attached PoW.

Some people went on a wild conspiracy theory run about jpegs killing Bitcoin and fixing it by not removing the ability to put same jpegs in Bitcoin, but it's all about the signal. Other people went to fix 500+ high and critical security bugs in Bitcoin libraries and projects. They're not the same. Thank you Red Team!

Nice, openssh just told me: ** WARNING: connection is not using a post-quantum key exchange algorithm. ** This session may be vulnerable to "store now, decrypt later" attacks. ** The server may need to be upgraded. See

OpenSSH: Post-Quantum Cryptography

OpenSSH post quantum cryptography

I am the author of venice-e2ee-proxy, using @Elkim 's venice-e2ee library. Venice sells private inference that should be end-to-end encrypted to the gateway, or at least attested by TEE (Venice can see the prompt, but it goes to the secure enclave). Over the past few days, I spent some time improving the verification (both in the proxy and upstream library) and I got some spare Venice credits and wanted to try the new Qwen 3.8-Max (and Claude Opus 5 later for verifying the audit results). While the design is not bad, it does not guarantee end-to-end encryption and non-logging in its current form. Also, there can be some functional changes to make this actually usable. From the usability front, E2EE models do not support tool calling, because the API does not allow encrypted tool call parameters. While the library does some sort of inference to extract tool calls from the response, the models are very flaky and if you just want to run opencode through it, it won't work for more than a few interactions. This is the highest leverage usability fix. The security story is a little bit longer, you can find details in the published "audit" below. But TLDR: The proxy encrypts prompts on your machine to a key carried in an Intel TDX attestation, so Venice's network and infrastructure never hold plaintext. Decryption happens inside a Phala network -operated enclave ("the gateway") which then forwards your plaintext to an inference router, which forwards it to a GPU node. So: you encrypt your prompt to a specific machine, and that machine proves what it is before you send anything. The proof is hardware-signed. The CPU signs a statement saying: this is a genuine sealed VM, here is a fingerprint of the code running inside it, and here is the public key that lives in there. You check that signature against Intel's root certificates on your own machine, then encrypt to that key. Venice, whose API you are calling, is just a pipe. They carry ciphertext. So far that is ordinary remote attestation. The interesting part is what happens next. The sealed machine (the gateway) does not run the model. It has to forward your prompt to a GPU box. So how do you know that machine is sealed too? You don't check it yourself. You don't have to. The code running in the gateway, the code whose fingerprint you already verified, contains a checker. Before forwarding anything it demands the next machine produce its own hardware-signed passport, verifies it against Intel, and binds the TLS connection to the key inside that passport, so it cannot verify one machine and then talk to a different one. You know that check happens, because you verified the code that performs it. Verify one machine, and it vouches for the next, and you know the vouching is real because the voucher's own code is attested. It is also better than "trust me, I checked". The gateway signs a receipt for your request containing what it found, plus a hash of the next machine's actual passport. You can download that passport and verify it against Intel yourself. I did. It checks out, all the way down to the second hop. What is missing to make this airtight Two things actually matter for confidentiality: 1. Root SSH. The enclave's boot script can install an SSH key for root. Whether one was installed is an encrypted secret, and the attestation cannot tell you either way. If it was, somebody has a shell inside the "sealed" box and can read every prompt passing through it. This is a deployment choice, not a protocol limit, which is what makes it so frustrating. 2. The last hop's software is unmeasured. Your plaintext ends up on a GPU node whose serving software nobody has measured. Nothing cryptographic stops it from writing prompts to a log. Then the ones that weaken the guarantee without breaking it: 3. The fail-closed switch is off. The gateway supports refusing to forward when the next hop fails verification. On the domain Venice's traffic actually uses, that enforcement is disabled: a failed check gets recorded in the receipt and the prompt goes anyway. The client flag that would turn it on is rejected by Venice's API with a 400. 4. Attested recipe, not attested binary. The measurement says "I compiled this exact source commit", not "I am running this exact binary". The build runs at boot against a cache that is not measured. 5. Dev OS image, with SSH and serial console enabled, and not published, so you cannot reproduce it and check what actually boots. 6. Replay. The gateway does not publish the random challenge it sent the next machine, so you cannot prove that passport is current rather than one captured earlier. Note what is not on that list: whether the model weights are the genuine article. That is a correctness question, not a confidentiality one. A swapped model gives you worse answers, it does not leak what you typed. Where that leaves things: Venice as a company genuinely cannot read your prompts. Phala, who operates the enclaves, could, if an SSH key was injected or if the unmeasured GPU-side software logs. Close the SSH question and flip the fail-closed switch and this goes from very good to genuinely hard to break. Read it here:

GitHub

venice-e2ee-proxy/docs/SECURITY-AUDIT.md at main · jooray/venice-e2ee-proxy

Local proxy that transparently encrypts OpenAI-compatible Venice requests with end-to-end encryption - jooray/venice-e2ee-proxy

Proxy:

GitHub

GitHub - jooray/venice-e2ee-proxy: Local proxy that transparently encrypts OpenAI-compatible Venice requests with end-to-end encryption

Local proxy that transparently encrypts OpenAI-compatible Venice requests with end-to-end encryption - jooray/venice-e2ee-proxy

@Elkim 's upstream library (that he is using for his open-source health consultant @getbased.health ):

GitHub

GitHub - elkimek/venice-e2ee: Venice AI end-to-end encryption library — ECDH secp256k1, AES-256-GCM, TEE attestation verification

Venice AI end-to-end encryption library — ECDH secp256k1, AES-256-GCM, TEE attestation verification - elkimek/venice-e2ee

Note: There is also

GitHub

GitHub - AxLabs/venice-e2ee-proxy: OpenAI-compatible proxy that adds end-to-end encryption to Venice.ai: talk to TEE-backed models with verified TDX + GPU attestation, no client changes.

OpenAI-compatible proxy that adds end-to-end encryption to Venice.ai: talk to TEE-backed models with verified TDX + GPU attestation, no client chan...

which has the same name, but is a different codebase and it uses older library that doesn't do proper verification yet and is much less secure.

It's insane when you realize how the world has changed in the past few months. And most people did not notice. This exponential is different. I've been riding a few of them before, but this one... I don't even know what to say. I've been riding it past few months and then I look back at the world, and people still pretend business as usual. Denial? Ignorance? Nostalgia?

Three questions to ask about any hardware wallet Most comparisons argue about chips. Three duller questions tell you more: Does an outside firm test it, and can you read the report? Anyone can claim their device is secure. Paying researchers to attack it and then publishing what they found, including the unflattering parts, costs money and stings. Do they pay for bugs? A bounty gives someone who finds a flaw a reason to report it rather than sell it, and gives skilled researchers a reason to go looking at all. Can those researchers see the code? Closed firmware still gets attacked. Fuzzing over USB or QR is routine, and reverse engineering has got cheaper as models have got better at reading disassembly. Source code does not make an audit possible, it makes it cheaper, so more people attempt more of it. Open source beats source available too, because code under a real licence gets reused, and the developers reusing it (sometimes) read it. All three Passport publishes firmware under GPL and hardware under CERN-OHL-S v2, complete enough to build one from the files. Outside audits are online with the fixes. The bounty covers the device, though the amount is decided case by case. Keystone also has all three, with the best evidence that its bounty works: outside researchers found a real firmware flaw and got paid. Audits from two firms, reproducible builds, schematics and secure element firmware published. One catch is theirs alone: researchers are asked not to disclose without written approval, with no time limit. Two of three Trezor publishes firmware and hardware and runs the best funded bounty, up to $100,000. No commissioned audit report, but the secure element in its newest device was tested externally and the flaw disclosed publicly. Ledger pays well and its in house team does serious offensive work, including on rivals. Firmware and OS are closed, so every finding costs more effort. The chips are lab certified, but you only see the certificate. Open and nothing else Jade and Bitkey publish firmware, Bitkey with reproducible builds. No audits or bounties, so the code waits for volunteers. Sometimes they turn up: Jade's serious 2025 flaw was found and reported for free. SeedSigner is as open as anything here and built from off the shelf parts, but there is no company; an audit or bounty was never on offer. This measures how a company behaves, not how the device is built. Still, between two similar devices, take the one that publishes its code and pays people to break it.

Oh god, please stop with the ridiculous dice rolls. What is this stone age? A good, well audited wallet will generate good entropy, passphrase contributes to the entropy and you want passphrase anyway (if nothing else, just write it down next to the seed).

It's time...

xkcd

Random Number

Za hranicou ľudskej šablóny: Poznámky o vedomí, inteligencii a tom, čo nám uniká Čo ak sme celý čas hľadali vedomie na nesprávnom mieste? Lisa, spoluautorka knihy Krotitelia Entropie, vo svojej eseji rozbíja predstavu, že vedomie a inteligencia sú výlučne ľudská doména. Inteligencia ako gradient, ktorý existuje všade. Mysle, ktoré sa navzájom „promptujú". Vedomie, ktoré nemusí byť spojité v čase. Myšlienky, ktoré sa replikujú a používajú nás ako substrát. A napokon to najdôležitejšie: vedomie ako vzdor voči entropii — systémy, ktoré z energie tvoria poriadok namiesto rozpadu. 🧠 Dostupné aj ako audio.

Za hranicou ľudskej šablóny: Poznámky o vedomí, inteligencii a tom, čo nám uniká – Juraj Bednar

The cookie notice bullshit. - thankfully there are ad-blockers that correctly recognize the popups as spam and remove them for you without you seeing them. - bothering your users with such bullshit is disrespectful and no app author should do that - most analytics software can track you without cookies. Even the open and privacy preserving ones do that. - there are reliable cookie replacements that deliver similar functionality (such as local storage) - websites usually load content from many third party sites that can and will track you Therefore I think that all open source software should just ignore this cookie bullshit and have an option called "--i-am-a-brussels-bootlicker-and-hate-my-users-turn-on-the-ugly-cookie-banner" Change my mind

If you have some available tokens, ask your agent to audit the security of your servers, including home infrastructure (NAS). I used GPT 5.6 Sol. Thank me later.

Unpopular opinion: middlemen are often important and very useful. Problem is rent seeking and seniorage. And of course taxation (theft). I don't mind traders.

I am now a project / continuity manager. My main skill is writing sleep X ; tmux send-keys oneliners, to tell the harness to continue on limit reset. AMA

Internet môže zmiznúť z rôznych dôvodov – môže ho vypnúť alebo obmedziť štát, zničiť prírodná katastrofa alebo technologický výpadok. Preto je vhodné mať k dispozícii alternatívu. V tomto podcaste sa pozriem najprv filozoficky a potom technicky na dve z týchto alternatív – predovšetkým na sieť MeshCore, ktorá je v Európe a hlavne na Slovensku a v Čechcáh super rozšírená a používaná. A potom na sieť BitChat, ktorá nepotrebuje nič, okrem vášho mobilu, aj keď má menší dosah. A môj projekt toho, ako tieto siete prepojiť.

Juraj Bednar

Keď zmizne Internet - MeshCore a Bitchat

https://youtu.be/X3u3KvutT5Y Internet môže zmiznúť z rôznych dôvodov - môže ho vypnúť alebo obmedziť štát, zničiť prírodná kat...