- The server sends all puzzle information, including the solution, to the client
- The client is responsible for validating your moves
- The client is also responsible for telling the server whether you have solved the puzzle or not.
However, the client does the 3rd step by just sending a request with some formdata, which has a key called "win". Basically, the client does not send your sequence of moves to the server to have the server verify them but directly sends whether you solved the puzzle or not.
Many, including me, have discovered this bug independently and tried to report it to Lichess. I've tried contacting Lichess 2-3 years back when I originally discovered this, but Lichess has always responded with "puzzles aren't competitive; exploiting them doesn't matter." (https://github.com/lichess-org/lila/issues/16393#issuecommen...)
Admittedly, they are correct: puzzle rating doesn't really matter. So, here's a little web app I made to exploit this. You just need to copy and paste your LILA2 cookie from Lichess. Requests are made through a proxy to set the Origin header.
Yeah, sure! So there's a few ways you can think about it.
In a more general case where you can make no assumptions about what you're rendering, you first render whatever is on-screen (so that you can also calculate their heights and position other elements properly). Then you render everything else off-screen, measure the total height and set that as the height for your container (for your virtual list).
Then you could implement some sort of caching for the heights to reduce recalculation for future loads.
If you can make some assumptions, there are a lot of clever ways you could even skip the rendering-then-checking-height method completely. One example I can think of is for is images; the height of an image is already present in the metadata. You just have to multiply it with some scaling factor to make it fit in your UI. That's much faster compared to checking the height after rendering.
What Seen currently does is the first. But the next version is going to do the second: finding a way to set a note's aspect ratio constant across all configurations of screen sizes, so that you no longer have to wait for all that calculation to finish.
Yup, that is true. And yes, it could really be much faster. This is an early preview though, and I'm working on it!
Also, Seen does have search. The problem with making it work with Ctrl+F would be to render all 1M notes (or at least some "shadow" version of them), which would really slow everything down. But again, maybe there is some other way - speed is one of the major concerns, and I'm working on it!
You're right, those are some trade-offs I've had to make. Not using Tanstack Virtual Table though, wrote a custom implementation with some help from our friend ChatGPT. I'll look into making it render faster!
