rlmineing_dead

I think it was worded badly

it was 25k WORTH of API billed tokens, but only actually 1 claude max 5x plan, so it was more like 100 dollars

This is a fun browser demo to show how far we've come in terms of browser technology mostly

So funny story, supporting web codecs may have been a bad idea because it led to people using more traffic per session than we assumed at first. We had to add more servers mid HN post

We had completely saturated NICs on like the two original servers

Performs so well is... Subjective but generally what matters here surprisingly is not CPU speed but GPU driver quality (all on Chromium)

I tested a bunch of stuff before this post went live Apple M1/M2/M3/M4 on macOS Sequoia, good

Apple M5 and prior chips on tahoe, bad due to a known GPU regression (this is actually why my personal machine runs sequoia)

Windows on ARM Qualcomm Adreno X1 driver - bad to usable performance

Ubuntu 26.04 Aarch64 upstream mesa with freedreno - works really well but encounters artifacting

Pixel 10 Pro - doesn't work here at all

Intel HD4600 on Windows 11 i7-4790k- works quite well up to 2 tabs where the renderer starts really suffering

Can concur, we use a proxy based on the wisp protocol to efficiently proxy TCP packets over websocket

You can inspect the wasm binary, we can't take that ability away from you (or you can compile using the sources we provide on GitHub and see it provides the same result, it's actually built from an actions runner anyways)

End to end Encrypted is valid here because both peers of the request (client and server) have their information being exchanged through TLS and they both manage their own keys. We can't look inside the TLS tunnel, we only transport the TCP side. It's end to end encrypted in the same sense that when you go to hackernews your ISP can't see your password because of TLS. The peer you are requesting has ensured only you can see the data, not any intermediary

(Unlike in http where it's completely plain text or a corsproxy where all data is visible to the proxy).

There's several opportunities for a bottleneck but it could be either the TCP implementation just not being good at receiving packets or the TCP proxy side just being congested from HN traffic

This is a cors bypass but part of this demo is that it's full Firefox including TLS support. Using this still means intercepting all requests in an inspectable medium and does defeat part of the point

Starred, very cool!

The latter

Assumes bad actors care about accessibility in the first place

Yeah I seem to see that it does crash on Firefox mobile, (well first frame loads) and on chrome mobile it doesn't seem to load at all (complaining about running out of memory in a small pop-up)

Pixel 10 pro user here

Extensions can't, correct but I wanted to bring up a special case regarding this

Isolated web apps a chrome feature for developing apps that run in chromium based on HTML (but tbh only really used in Chromebooks) do support raw TCP sockets so if this was ported to an IWA you could have Firefox on a Chromebook without an external server needed.

You are definitely right, going to see if I can talk to the relevant person to fix the wording on it