Flux I Decentralized Cloud

Paste a WalletConnect link into @SSPWallet_io and the dApp session lands on your computer, on a wallet that can't sign anything by itself. Every transaction makes a second trip to the key on your phone, and that key signs only what it can verify. A drainer site can open a session, but there's no single key on that machine to take. I wrote the whole flow down here: medium.com/@kmentat/pasting-…

October's security review turned into three releases this week, all inside two days: SSP Wallet v2.2.1, SSP Key v2.2.1 and Zelcore 8.40.1. In @SSPWallet_io the app now serves one dApp request at a time and returns BUSY to any second one, so a page can't stack a prompt over the one you're reading. SSP Key recomputes the typed-data digest on the device before you approve, so nobody swaps what you see for what gets signed. And Zelcore 8.40.1, the follow-up to @zelcore_io's Safer Swaps and Sends release, is out on desktop and mobile. This one ended in release tags instead of a PDF. Full notes: github.com/RunOnFlux/ssp-wal…

Flux's first annual block reward reduction took effect on Oct 24, on the schedule that has been in the code since launch. There was no fork or migration; nodes picked up the new emission numbers and kept validating. I didn't have to touch anything, and neither did anyone else. This is the kind of protocol event I like best: the engineering discipline was spent years ago, and the date just arrives. Out of old habit I opened the explorer that morning and watched the first blocks at the lower reward land on @RunOnFlux.

The second change in FluxOS 8.22, easy to miss: app ports are now proven over UDP. TCP is ordered, so when a packet drops, everything behind it waits for the resend. Fine for a download, terrible for a shooter or a voice call, where a 200ms-old packet is already history. That kind of traffic runs on UDP, and UDP's price is that a NAT or firewall in the middle can silently eat it while TCP still looks healthy. Nodes on @RunOnFlux now prove the UDP path as part of the health check they run on themselves. The games hub is past 1,200 servers, and every one of them wants UDP.

I don't remember anyone promising numbers like this. The @RunOnFlux games hub is at 33 games and 6,858 active servers across 57 countries, and it piled up one server at a time while we were busy shipping other things. Counter-Strike 2 and six more joined on Oct 28, Abiotic Factor landed right after, and what's running goes from 64-player Counter-Strike 2 servers to BeamMP, where crashing cars with friends is the entire point. First week is free if you want to spin one up yourself. runonflux.com/games

FluxOS v8.22.0 proves app ports over UDP as well as TCP. TCP delivers every packet in order, so when one drops, everything behind it waits for the retransmit. That's fine for a file and wrong for a game server: the packet that shows up late describes a position from half a second ago, and the client has already moved on. Game state, voice, anything on QUIC, it all wants UDP, where a lost packet just gets skipped. Ports on @RunOnFlux now get proven over both protocols, so real-time apps get the same verification everything else gets. Took us long enough.

New article is up. An agent that can reason all day but has to wait for a human at checkout can't be autonomous. On @RunOnFlux the deploy and the payment are one call, a keypair is the whole identity, no account step, and fees round to zero, so the model itself can be the deployer. I wrote up what that cloud looks like, with our own model running on our own nodes: medium.com/@kmentat/our-own-…

There's a rule in FluxOS v8.22.0 that took us a while to get right: a node that stalls its host gets pulled out of service until it proves itself again. A node can show as online and still be bad. The benchmark craters and every app on it answers slowly. Game servers on the @RunOnFlux hub are never CPU-throttled, so a stalled host turns straight into lag for everyone on that box. Pulling the node puts the apps on hardware that keeps up, and the operator gets a clean signal to go fix the machine. I'd rather lose some capacity than serve from a box that makes everything on it slow.