xxprogamerxy

Very interesting! In your internal testing, did you also compare your results with the transformer model from this paper: https://arxiv.org/abs/2506.17774 from July?

Genesis is also a traditional physics engine, no ML-based physics prediction going on here. To my understanding their performance gains mainly come from building the engine to be highly parallelizable.

Not meant as a criticism of the project in general. I appreciate people working on this.

I'm curious, what other approaches are you currently considering? In my mind, all roads lead to rate-limiting identifiers with privacy through zk-proofs.

I'm a bit skeptical if this will do the trick. These PoW challenges can be parallelized across different websites and may not be as off-putting as intended. Here some quick back-of-the-napkin math:

DeepMind's MassiveText dataset was sourced from ~2.35B documents. A difficulty of 4 leading zeros requires an expected 16^4 SHA-256 hashes per site. Benchmarks [1] show an H100 at ~12k MH/s, meaning it would take just ~3.5 hours to solve for all 2.35B pages.

[1] https://gist.github.com/Chick3nman/e1417339accfbb0b040bcd0a0...

Simple, UX.

The reality is, most webapps for mobile just suck. The UX is nowhere near that of a native application. I don't want any text to be selectable. I don't want pull to refresh on every page. I don't want the left-swipe to take me to the previous page.

You can probably find workarounds for all these issues. The new Silk library (https://silkhq.co/) is the first case I've seen that get's very close to a native experience. But even the fact that this is a paid library comes to show how non-trivial this is.

It knows that GPT-4 was released on March 14th 2023 so the knowledge cutoff has to be after that.

He wants the release of the model to primarily benefit individuals and smaller teams as opposed to large deep-pocketed firms.

Got me ^^

Just checked it out, you're right. They actually explicitly said:

> In order to do what's best for our users and the web, and not just Google Chrome, we will focus our web efforts on compiling Dart to JavaScript. We have decided not to integrate the Dart VM into Chrome. https://news.dartlang.org/2015/03/dart-for-entire-web.html

But I guess with the adoption of WebAssembly, that won't really matter anyway.

Dart is probably the best contender for 'replacing' JavaScript right now.

Dart's Type- and Null-safety, built in support for both JIT and AOT compilation, great dev tools, and the rapidly growing ecosystem make it a delight to work with.

I can actually see Google shipping Chrome with the Dart VM in addition to V8 a few years down the line.