Creating conditions for a more adaptive frontier
Midgård
Joined February 2016
- Tweets2.8K
- Following1K
- Followers2.5K
- Likes6K
Turns out packaging your entire frontend so it can be distributed from one host only (or one hash, in the case of @IPFS) wasn't so crazy after all
cc @walletbeat
I would strongly consider uninstalling any third party js right now if I were you. Especially if it comes from a startup.
Analytics, monitoring, etc are all massive site takeover risks. If you use a tracking script from a third party SaaS, then if they get hacked the hackers have total control over your site too.
This is what took down Polymarket today. They used a tiny script from a SaaS that tracks page load speed. That company got hacked, and the hackers subsequently stole millions from Polymarket users.
If you want to use analytics safely, I would use a product that lets you pin the tracking script and control when it changes. Most of the mature products support this, e.g. Sentry, Amplitude, PostHog, Mixpanel, Heap. If not, you need to trust the company behind it a lot...
Railway got hacked last week. Railway! That's a very competent team, with particularly strong infra chops. The agent swarms are on another level.
A typical analytics company is nowhere near as sophisticated. You should ask yourself: do I trust this company's security more than Railway? I was an analytics CTO in a past life, and I will be the first to admit: we had some great people but we were not on this level.
We (Detail) just uninstalled our session replay, which was a product I loved but is not worth the risk right now.
I hate to write this because I spent a good chunk of my 20s benefitting from product teams taking a chance on a nothing startup and installing our js on their site. But in the past two weeks this risk vector has exploded. It's better for the ecosystem if we move away from third party js as fast as we can.
If you absolutely have to bundle a script from a third party source, using the Subresource Integrity API is the way to go.
en.wikipedia.org/wiki/Subres…
It enables you to specify the expected hash of the javascript you are about to load. And browsers enforce it!
If you absolutely have to bundle a script from a third party source, using the Subresource Integrity API is the way to go.
en.wikipedia.org/wiki/Subres…
It enables you to specify the expected hash of the javascript you are about to load. And browsers enforce it!
Turns out packaging your entire frontend so it can be distributed from one host only (or one hash, in the case of @IPFS) wasn't so crazy after all
cc @walletbeat
1975:
“a lot of people want personal computers, and somehow they assume that the problem is solved now because we have microprocessors, we’re going to be able to run them in our homes, and so we’re not going to need all the stuff in the mainframe. but from a global allocation perspective, actually it’s quite terrible to have everybody, like, have a bunch of the world’s limited supply of memory chips sitting on their own desk and being used five percent of the time. you want maximum utilisation on the time-sharing terminal. somehow many people’s intuition is the opposite of that”
sam: local inference is a terrible allocation of scarce resources
“a lot of people want local inference, and somehow they assume that the problem is solved now because we have open-source models, we're going to be able to run them on our computers, and so we're not going to need all the stuff in the data centre
but from a global allocation perspective, actually it's quite terrible to have everybody, like, have a bunch of the world's limited supply of DRAM sitting in their own computer and being used five percent of the time
you want maximum utilisation in the cloud if you're trying to deal with this very supply-constrained environment
somehow many people's intuition is the opposite of that”
Amazing!
I think @MistralAI seeded the idea. Been a torrent index for all open models was the logical next step. Looks like it's now real.
Introducing Pirate Face
The first verifiable torrent index for AI - every Hugging Face open model, provably identical to the original and kept alive forever by the swarm.
pirateface.co
The permanence layer for AI. How it works 👇
Joel retweeted
Partial stateful node is here!
Happy to announce chibi: a node that syncs in minutes and lets you transact through your own local RPC. Trust no one because every value is proven.
It runs on practically any hardware. Need to send a transaction? Don't need to rely on RPC providers, just spin up chibi and send it right away. Live on Sepolia today and Hoodi next.
👇 demo below
Joel retweeted
Future software will be a fuzzy cloud of versions/interaction surfaces that are malleable to the user or organisation it serves - it will be expected for any competitive product. These shells will share a much more conservatively updated core via stratified version control.
Been exploring local-first p2p systems for data, and realized cryptographic identity has a double-spend problem. Unfortunately this can not be resolved without relying on a blockchain, but you can use it minimally.
jthor.eth.link/blog/2026/10/…
Joel retweeted
This weekend at @ETHGlobal Tokyo I built a local-first UI for @Safe multisigs
It can index past transactions, simulate pending transactions and show asset value from a single RPC URL
Wanna write cypherpunk articles? Use simplepage.eth.link
In the wake of the ENS drama a novel governance experiment is playing out on Ethereum. Two protocols, .wei and .gwei are competing for mindshare. The main differentiator is how they are governed.
.wei charges fees. A DAO governs the treasury. Voting power is based on how much you spent on buying names. Votes are passed using conviction voting. The project is created by @z0r0zzz
.gwei burns fees. There is no governance. The code itself is a fork of .wei made by @donnoh_eth
Both approaches take fairly neutral stances. Will the market favor one or the other? Can the WEI DAO use their treasury to grow faster than .gwei?
I'll be watching curiously!
Joel retweeted
futarchy is too complicated and governance heavy.
v's original daico design was way simpler and more elegant.
let's me work with claude to ship a simple, immutable, no-governance daico platform.
ethresear.ch/t/explanation-o…
This has to be the definition of slop development!
🚨Taiko drained for ~$1.7M. Root cause: a private key committed to a public GitHub repo.
enclave-key.pem, the RSA key used to sign all of Taiko's SGX enclaves, sat in the public taikoxyz/raiko repo. That key is the whole trust model.
The attacker derived MrSigner from the public key, signed their own malicious enclave with the leaked key, and registered as a trusted prover. The L1 contracts trust any enclave whose MrSigner matches. It matched.
From there: forged SGX attestations on fake L2 blocks, processMessage() sets the message to RETRIABLE, retryMessage() does zero proof verification, funds leave.
No key theft. No social engineering. No SGX exploit. Just a .pem in a public repo.
Good opportunity to recall that SGX is broken. But here, nobody even had to break it.
It's just yet another key management failure. The whole system was only ever as strong as the secrecy of one RSA key, and that secrecy depended on a human not running git add . on the wrong folder. AI greps every commit of every public repo at machine speed. Assume that is already happening.
The only real exit: a verifier that checks a succinct validity proof of the L2 state transition. It trusts no enclave, no MrSigner, no operator discipline. It checks the math. In that world this exact attack becomes cryptographically impossible rather than operationally unlikely, because there is no privileged key whose leak forges the entire system. There is just a proof.
Stay safe.
Joel retweeted
absolutely fucking not
New post on EthResear.ch!
Validator Redirected Revenue
By:
- clesaege
🔗 ethresear.ch/t/25248
Highlights:
- Ethereum faces a persistent coordination failure: many ecosystem improvements are public goods, so voluntary funding tends to underprovide them, creating deadweight loss and harming long-term competitiveness.
- Validators are structurally aligned with ecosystem growth (more usage → more demand for blockspace → more ETH burn/value), but they still get stuck in a prisoner’s-dilemma equilibrium where they hesitate to contribute unless others also commit.
- The proposal adds a protocol-level mechanism where validators signal a redirect rate: if a majority (e.g., 51%) supports a non-zero rate, that rate becomes mandatory for all validators, solving intra-validator free-riding; the rate is capped (suggested max 10%, min 0%).
- Validators also signal preferred funding recipients and allocations; execution clients aggregate these into a “splitter” contract using a king-of-the-hill / Condorcet-winner style process with simple protocol choices (KEEP vs CHANGE), aiming to minimize governance overhead (“set and forget”).
- Key open risks include validator cartelization (majority could redirect funds to themselves), principal–agent problems (staking operators controlling votes vs delegators’ preferences), and the possibility that willingness to redirect rewards is interpreted as evidence issuance could be reduced.
ELI5:
Ethereum needs shared things (like security tools and maintenance) that help everyone, but it’s hard to get people to voluntarily pay because each person hopes others will cover the cost (the “free-rider” problem). This article suggests a built-in way for Ethereum validators (the people who earn staking rewards) to collectively agree to donate a small, capped slice of their rewards to fund important ecosystem work. Validators would also collectively choose where the money goes using a simple voting/competition process, so funding can happen without lots of meetings or bureaucracy—while still acknowledging risks like validators teaming up (cartels) or staking companies voting in their own interest instead of users’.
Someone build a Linux distribution secured by ethereum plz 🥺
Where ethereum would actually add value: a Linux app store / package manager.
Today package managers are mostly centrally by the corresponding distribution team. Instead developers could release their apps themselves. The builds would be notarized onchain.
Users could opt in to audit-lists so they only download releases and apps that have been verified.
This could solve the malware problems we've seen on the AUR for example.
Joel retweeted
/bloom walletFS powers Agents on Ethereum & L2s.
Not just another smart wallet. Not just another toolkit.
We turn the chain into a readable, auditable filesystem: agents see, plan, verify, execute. Humans inspect before anything moves.
Built for Agents. Trusted by Humans.
