Correct, nice found again. To be provably fair it should generate the number sets based on both the server- and clientseed^[1]. Actually it will be easier to just generate 2 numbers 1-6. Ideally it will not be "per roll" anyway, but just the "nonce way". There are several problems with "per roll" even in a perfect technical implementation, for example: the player has to write down each seed between each roll and verify per roll (instead of just copying 1 seed for hundreds of rolls.)

Again, I agree that, in theory, currently it is too easy for Pocket Dice to cheat with the current provably fair implementation. The client's seed is not really used to generate the random result. But I can still imagine it is not wrong on purpose - it should be changed though.

Possible better way: Basically any dice site calculates a number between 0-100. And it is very easy for them to generate 2 numbers between 0-100 from 1 "result hash" (they actually do this already if the result is more than 100.) Then just make 0-16.6666=1,16.6666-33.3333=2, ....., 83.3333-100=6. So the "normal" provably fair method with "nonce method", used on all popular dice sites, can definitely be implemented here and that would be much better.

Or just take set of 12 numbers and do the Fisher-Yates shuffle with the sha2 of server+clientseed+nonce (and delimiters in between) as Mersenne Twister seed, I guess.

1. And ideally the client seed is not made with Math.random() like it is now.