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

This is already possible (actually because of a related project, https://github.com/ading2210/libcurl.js/ ) which compiles... I think WolfSSL or mbedTLS and libcurl to the wasm and then uses the same TCP proxy protocol we're using here (wisp) to tunnel HTTPS over a websocket connection securely and opaquely.

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

What's your GPU driver? There's a good chance this is a bug with the GPU passthrough. You can fall back to software rendering in the advanced options while it's starting if you want to try

safari? I think its going to be added in 27

This is true but also this is probably also only half true. Sandboxing is not a fully solved issue since this 100% degrades firefox sandboxing since fission cant run and its running in singleprocess mode. Just wanted to be honest about this

Running firefox on aarch64 here right now (Ubuntu 26.04 ARM on snapdragon X1E)

did you enable the about:config option? it may be required

apologies yes there is a wording error here, the correct wording is no CORS proxy, the reason why this is important is because cors proxies are inherently insecure (this is different because the TLS is done in your browser with a webassembly library).

no servers is referring to you not needing to host servers in the same as the term "serverless". Such is the ways of modern tech terms I fear

The TCP proxy exit node we're using is running on Cloudflare, you can check that your traffic is still TLS encrypted by OpenSSL (also compiled to webassembly). The browser does not have a native API to send raw TCP so the proxying is done by the http://github.com/MercuryWorkshop/wisp-protocol protocol. You can check your packets in dev tools, look for a socket connection with "puter.cafe" as the host for our TCP proxy. This application is meant to be a demo for it actually (why it says at the bottom that its powered by puter networking). That is the only server side component of this.

hi reporting back, yes stock firefox mobile wont work but the BETA version will because it just added the WASM feature needed (firefox 153 adds it but regular mobile firefox lacks about:config support it seems)

and by "will work" I mean will render the first frame and then freeze

YMMV

Does firefox mobile (Android, since firefox mobile iOS is a WebKit wrapper) support about:config settings? if so you can enable wasm_js_promise_integration in about:config and have it working likely. I will test this on my Pixel 10 pro

I had this in mind when I first saw this project too LOL

Every year I need to rewatch this talk

What happened to the "always" in "always free"

we provided the token cost result at the bottom. While an expensive model, 550 for a port of ladybird isn't bad I think

Not exposed but hackclub's security practices always seems to make it easy to access if you want to.

I am not the OP but I think I know the back story behind this name and if I'm not wrong, it is related to events that went down in hackclub revolving a suicide attempt in HC being taken unseriously.

As someone who is/was also a part of the hack club community, this article is mostly correct. I've seen most of these events occur second hand as well in real time and can mostly corroborate with the accuracy of the article, except the minors in legal roles part. The community is severely mismanaged, data leaks happen often in very predicable ways and it does seem as if much of it is symptoms of vibe coding.

Yeah I dont know any SDR above 6GHZ but also other than mmwave 5G I also dont know much radio that is above 6Ghz in general